📣 Teleport의 공식 파트너 인포그랩에서 OpenAI 기술 기반으로 자체 개발한 자동화 번역 프로그램을 통해 Teleport 공식 문서(v17.0.0)의 한글판을 국내 최초로 제공합니다.
Infograb logo
TLS 라우팅

TLS 라우팅 모드에서 Teleport 프록시는 모든 클라이언트 연결을 단일 TLS 포트에서 다중화합니다.

TLS 라우팅을 통해 클러스터 관리자는 프록시가 하나의 포트에서만 수신 대기하므로 네트워크 구성을 간소화할 수 있습니다. 모든 연결은 상호 TLS로 인증되며 사용자는 네트워크에서 차단될 수 있는 SSH와 같은 프로토콜을 터널링할 수 있습니다.

TLS 라우팅을 구현하기 위해 Teleport는 SNI (서버 이름 표시) 및 ALPN (응용 프로그램 수준 프로토콜 협상) TLS 확장을 사용합니다.

레이어 7 (HTTP/HTTPS) 로드 밸런서 및 리버스 프록시 뒤에서 TLS 라우팅 지원은 Teleport 13.0 부터 가능합니다.

작동 방식

Teleport 프록시 서비스는 기본적으로 모든 클라이언트 연결을 web_listen_addr 에서 수신 대기합니다:

proxy_service:
  web_listen_addr: "0.0.0.0:443"

SSH, 웹 브라우저, kubectl, 데이터베이스 및 리버스 터널 클라이언트를 포함한 모든 Teleport 클라이언트는 프록시의 웹 포트에 TLS 터널을 설정하고, SNI 및 ALPN TLS 확장을 사용하여 요청하는 프로토콜을 나타냅니다.

새 연결을 수락하면 프록시는 TLS 핸드쉐이크에서 SNI/ALPN 값을 검사하고 적절한 백엔드 서비스로 연결을 전달합니다.

로컬 프록시

psql 또는 mysql 과 같은 클라이언트는 프로토콜 전용 연결 협상 단계(일명 STARTTLS)의 일환으로 TLS 핸드쉐이크를 구현합니다.

이러한 클라이언트를 지원하기 위해 TLS를 지원하지만 사용자 지정 ALPN 값을 설정할 수 없는 클라이언트를 위해 Teleport의 tsh 클라이언트는 로컬 TLS 라우팅 인식 프록시를 시작할 수 있는 기능을 포함합니다.

이러한 클라이언트는 Teleport 프록시에 직접 연결하는 대신 로컬 프록시에 연결합니다. 로컬 프록시는 적절한 SNI/ALPN 값이 설정된 상태로 Teleport 프록시에 TLS 연결을 설정하고 클라이언트의 연결을 통해 터널링합니다.

대부분의 경우 클라이언트는 연결을 설정할 때 TLS 라우팅을 투명하게 처리합니다. 예를 들어, tsh 클라이언트는 로컬 프록시를 시작하고 자동으로 적절한 SNI/ALPN 값을 설정합니다. 그러나 tsh db connect 대신 GUI 데이터베이스 클라이언트와 같은 일부 클라이언트의 경우 사용자가 로컬 프록시를 시작해야 이러한 클라이언트가 연결할 수 있습니다.

다이어그램

TLS 라우팅

Teleport가 지원하는 각 프로토콜이 TLS 라우팅을 구현하는 방식을 살펴보겠습니다.

SSH

SSH 노드에 연결할 때 Teleport 클라이언트 tsh 는 먼저 TLS를 통해 Teleport 프록시에 연결하고 teleport-proxy-ssh ALPN 프로토콜을 요청합니다.

이 경우 tsh 는 SSH 연결을 설정하는 데 이 TLS 연결을 전송로 사용하므로 로컬 프록시가 시작되지 않습니다.

OpenSSH

표준 OpenSSH 클라이언트를 지원하기 위해 Teleport는 ProxyCommand 로 사용할 수 있는 tsh proxy ssh 명령을 제공합니다.

tsh ssh 와 유사하게, tsh proxy ssh 는 teleport-proxy-ssh ALPN 프로토콜로 Teleport 프록시와의 TLS 터널을 설정하고, ssh 는 이를 통해 연결합니다.

구성 방법에 대한 자세한 내용은 OpenSSH 클라이언트 가이드를 참조하십시오.

리버스 터널

Teleport SSH, 애플리케이션 및 데이터베이스 서비스 내의 리버스 터널 작업자는 신뢰할 수 있는 클러스터를 위해 TLS 터널을 클러스터의 프록시 서비스에서 teleport-reversetunnel ALPN 프로토콜로 엽니다. 그런 다음, 작업자는 터널을 통해 SSH를 다이얼링하여 안전한 연결을 설정합니다.

쿠버네티스

쿠버네티스 클라이언트 kubectl 은 API 서버와 통신하기 위해 HTTPS API 및 TLS 핸드셰이크를 사용합니다.

따라서 kubectl 을 사용하여 사용자 정의 ALPN 프로토콜을 요청하는 것은 불가능합니다. 대신, Teleport는 SNI를 활용하고 tsh kube login 중에 kubeconfig 파일을 생성할 때 kube-teleport-proxy-alpn.으로 시작하는 ServerName 을 설정합니다:

apiVersion: v1
kind: Config
clusters:
  - cluster:
      certificate-authority-data: ...
      server: https://proxy.example.com:443
      tls-server-name: kube-teleport-proxy-alpn.proxy.example.com
    name: example

데이터베이스

tsh db connect 명령은 연결하는 데이터베이스에 적합한 데이터베이스 클라이언트를 실행합니다.

TLS 라우팅 모드에서 tsh 는 데이터베이스 클라이언트 연결이 터널링되는 로컬 프록시를 시작합니다. 로컬 프록시는 데이터베이스에 따라 teleport-mysql 과 같은 ALPN 값을 사용합니다. 데이터베이스 세션이 종료되면 프록시는 종료됩니다.

네이티브 및 GUI 클라이언트

네이티브 또는 그래픽 데이터베이스 클라이언트가 TLS 라우팅으로 작동하려면, Teleport 프록시가 아닌 로컬 프록시에 연결해야 합니다.

Teleport는 로컬 데이터베이스 프록시를 시작하기 위한 tsh proxy db 명령을 제공합니다:

tsh proxy db example-db

사용 예제는 GUI 클라이언트 가이드를 참조하십시오.

웹 UI, 앱 및 데스크톱

애플리케이션 접근, 데스크톱 접근 및 Teleport 웹 UI는 Teleport 프록시의 웹 리스너에 의해 제공되며, 로컬 프록시 또는 특별한 ALPN/SNI 협상이 필요하지 않습니다. 이러한 웹 연결은 ALPN을 위해 표준 http1.1 및 h2 프로토콜을 사용합니다.

레이어 7 로드 밸런서 또는 리버스 프록시와 함께 작업하기

버전 13.0 부터 TLS 라우팅을 활성화하여 Teleport 프록시 서비스가 레이어 7 로드 밸런서 또는 리버스 프록시 뒤에서 단일 포트를 제공할 수 있습니다.

레이어 7 로드 밸런서 또는 리버스 프록시가 공용 인증서를 사용하여 TLS를 종료할 것으로 예상됩니다. 예를 들어 AWS ALB의 ACM을 사용하는 경우입니다. 이는 프록시 서비스가 http_keypair 또는 acme 를 사용하여 웹 TLS 인증서를 요구하지 않음을 의미합니다.

Teleport 클라이언트는 Teleport 프록시 서비스가 레이어 7 로드 밸런서 또는 리버스 프록시 뒤에 있는지 자동으로 감지합니다. 이러한 경우 클라이언트는 연결 업그레이드를 시작한 다음 업그레이드된 연결을 통해 TLS 라우팅 요청을 보냅니다.

초기 클라이언트 구현은 Teleport 맞춤 업그레이드 'alpn'을 보내며, 이는 WebSockets와 동일한 연결 업그레이드 원리를 사용합니다. 버전 15.1부터 Teleport 클라이언트는 더 많은 로드 밸런서 및 리버스 프록시와의 호환성을 확대하기 위해 네이티브 WebSocket 업그레이드를 보낼 것입니다.

비텔레포트 클라이언트는 특별한 연결 업그레이드를 수행할 수 있는 로컬 프록시를 요구해야 합니다.

이 구성에서 각 프로토콜이 어떻게 작동하는지 자세히 살펴보겠습니다.

SSH

TLS 라우팅을 통해 SSH 프로토콜을 전송할 때, tsh 는 연결 업그레이드를 원활하게 수행합니다. 이는 tsh ssh/scp 명령 및 OpenSSH 클라이언트를 사용하여 ProxyCommand 로 연결될 때의 tsh proxy ssh 에 적용됩니다.

Kubernetes

tsh proxy kube 명령은 로컬 프록시와 Kubernetes 클라이언트인 kubectl 을 위한 임시 kubeconfig를 생성합니다. 로컬 프록시는 Kubernetes 클라이언트와의 로컬 통신을 안전하게 하기 위해 자체 서명된 인증서를 생성합니다.

프록시 서비스에 요청을 전달할 때, 로컬 프록시는 필요한 연결 업그레이드를 수행하고 TLS 핸드셰이크를 위한 필수 SNI를 설정합니다.

tsh kubectl 및 tsh kube exec 명령은 연결 업그레이드가 필요할 때 자동으로 로컬 프록시를 시작합니다.

Databases

TLS 라우팅 모드에서, tsh db connect 는 데이터베이스 클라이언트 연결이 터널링되는 로컬 프록시를 시작합니다. 로컬 프록시는 연결 업그레이드를 통해 프록시 서비스에 연결을 시작한 다음 TLS 핸드셰이크를 위해 데이터베이스 특정 ALPN 값을 사용합니다.

유사하게, 기본 및 GUI 클라이언트는 tsh proxy db 를 통해 연결할 수 있으며, 이는 연결 업그레이드를 처리하는 로컬 프록시를 시작합니다.

Web UI and Desktops

Teleport 웹 UI는 표준 브라우저에서 완전히 작동하며, 특별한 ALPN/SNI 값이나 연결 업그레이드가 필요하지 않습니다.

Apps

HTTP 및 TCP 앱 모두에 대해, tsh proxy app 는 연결 업그레이드를 처리하고 TLS 라우팅을 위한 적절한 ALPN 값을 설정하는 로컬 프록시를 시작할 수 있습니다.

Cloud API에 접근하기 위한 tsh CLI 명령어(예: tsh aws )는 연결 업그레이드를 수행하는 로컬 프록시를 투명하게 시작합니다. 네이티브 애플리케이션을 위한 로컬 프록시를 시작하려면 tsh proxy aws 를 사용할 수 있습니다.

Client source IPs

proxy_service.trust_x_forwarded_for 가 true 로 설정될 때, 프록시 서비스는 로드 밸런서 또는 리버스 프록시가 설정한 "X-Forwarded-For" 헤더에서 클라이언트 소스 IP를 가져옵니다. 이는 연결 업그레이드를 사용하는 TLS 라우팅 요청에도 적용되며, 본질적으로 HTTP 요청입니다.

IP 스푸핑을 방지하기 위해, 각 요청의 "X-Forwarded-For" 헤더에는 단일 IP 주소만 예상됩니다. 여러 IP 주소가 포함된 요청은 거부됩니다.

FAQ

TLS 라우팅이 TLS를 종료하는 레이어 4 로드 밸런서 뒤에서 작동합니까?

예. Teleport 프록시 서비스가 TLS를 종료하는 레이어 4 로드 밸런서 뒤에 있을 때, Teleport 클라이언트는 레이어 7 로드 밸런서가 있을 때와 유사하게 연결 업그레이드를 수행합니다.

로드 밸런서는 TLS 레이어를 Teleport 프록시 서비스에 전달해야 합니다. 예를 들어, AWS 네트워크 로드 밸런서(NLB)는 대상 그룹에 대해 "TLS" 프로토콜을 사용해야 합니다.

내 리버스 프록시 뒤에서 TLS 라우팅이 작동합니까?

15.1 버전부터 TLS 라우팅은 WebSocket을 지원하는 모든 리버스 프록시와 호환됩니다.

15.1 이전의 Teleport 버전에서는 리버스 프록시가 사용자 정의 연결 업그레이드 및 장기 연결을 지원해야 합니다.

리버스 프록시 뒤에 Teleport 프록시 서비스를 설정하고 다음 명령을 실행하여 연결을 테스트할 수 있습니다:

curl -v https://teleport.example.com/webapi/connectionupgrade -H "Connection: Upgrade" -H "Upgrade: alpn-ping" --no-alpn

성공적인 업그레이드를 위해, 서버는 요청된 업그레이드 유형으로 "101 Switching Protocols"를 반환해야 하며, curl 명령을 실행할 때 약 30초 후에 일부 이진 출력도 받아야 합니다:

< HTTP/1.1 101 Switching Protocols
< Connection: Upgrade
< Upgrade: alpn-ping
< X-Teleport-Upgrade: alpn-ping
<
경고: 이진 출력은 터미널을 망가뜨릴 수 있습니다.

Kubernetes 클러스터에 tsh proxy kube 없이 어떻게 접근할 수 있나요?

로컬 프록시는 Teleport Proxy 서비스가 레이어 7 로드 밸런서 또는 리버스 프록시 뒤에 있을 때 필요합니다.

tsh proxy kube 의 대안 중 하나는 tsh kubectl 을 사용하는 것입니다. 이는 연결 업그레이드가 필요할 때 자동으로 로컬 프록시를 시작합니다.

로컬 프록시를 완전히 피하려면, 레이어 7 로드 밸런서 대신 TCP 모드의 레이어 4 로드 밸런서를 사용하거나, Teleport Proxy 서비스를 separate 포트 모드로 구성하고 레이어 7 로드 밸런서 뒤에 있지 않은 별도의 Kubernetes 포트를 사용하세요.

다음 단계

  • 마이그레이션 가이드를 확인하여 기존 클러스터를 TLS 라우팅을 사용하도록 업그레이드하는 방법을 알아보세요.
  • TLS 라우팅 설계 문서 RFD를 읽어보세요.
Teleport 원문 보기
인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!