텔레포트를 프로덕션 환경에 배포할 때, 텔레포트 클러스터에서 사건 발생 시 사용자들이 인프라에 계속 접근할 수 있도록 배포를 설계해야 합니다. 또한, 더 많은 사용자와 리소스를 텔레포트에 등록하면서 Auth Service와 Proxy Service를 확장할 수 있도록 해야 합니다.
이 가이드에서는 고가용성 텔레포트 배포의 구성 요소에 대해 설명합니다.
Teleport Enterprise Cloud가 이 설정을 자동으로 처리하므로, 귀하는 즉시 안전한 인프라 접근을 제공할 수 있습니다.
무료 체험으로 Teleport Enterprise Cloud를 시작하세요.
개요
고가용성 텔레포트 클러스터는 두 개의 중복 teleport 프로세스 풀, 하나는 Auth Service를 실행하고 다른 하나는 Proxy Service를 실행하며, 각 풀을 지원하는 인프라로 구성됩니다.
인프라 구성 요소에는 다음이 포함됩니다:
- 사용자가 이용 가능한 Proxy Service 인스턴스에 트래픽을 전달하는 공용 레이어 4 로드 밸런서.
- Proxy Service에서 Auth Service의 gRPC API로 트래픽을 전달하는 사설 레이어 4 로드 밸런서. 이는 텔레포트가 Auth Service의 백엔드 상태를 관리하고 클러스터 내에서 사용자 및 서비스에 자격 증명을 제공하는 방식입니다.
- 클러스터 상태 백엔드. 이는 모든 Auth Service 인스턴스가 접근할 수 있는 클러스터 상태 및 감사 이벤트에 대한 키-값 저장소입니다. 이를 위해서는 Auth Service 인스턴스가 키-값 저장소 내의 레코드를 관리할 수 있는 권한이 필요합니다.
- 세션 녹화 백엔드. 이는 Auth Service가 세션 녹화를 업로드하는 객체 저장 서비스입니다. 세션 녹화 백엔드는
teleport인스턴스가 저장 서비스 내에서 객체를 관리할 권한이 필요합니다. - TLS 자격 증명 프로비저닝 시스템. Let's Encrypt(또는 내부 공용 키 인프라)와 같은 인증 기관에서 TLS 자격 증명을 얻고
teleport인스턴스에 공급하며 주기적으로 갱신할 수 있는 방법이 필요합니다. - DNS 서비스. 텔레포트 Proxy Service의 레코드를 생성할 수 있는 DNS 서비스입니다. TLS 자격 증명을 위해 Let's Encrypt를 사용하는 경우, TLS 자격 증명 프로비저너는 도메인 이름에 대한 제어를 입증하기 위해 DNS 레코드를 관리해야 합니다.
레이어 4 로드 밸런서
고가용성 텔레포트 클러스터에는 두 개의 로드 밸런서가 필요합니다:
- Proxy Service 로드 밸런서: 네트워크 외부에서 텔레포트 클러스터가 실행되는 매개체로 트래픽을 수신하고 사용 가능한 Proxy Service 인스턴스로 전달하는 로드 밸런서입니다. 이 로드 밸런서는 다양한 애플리케이션 레이어 프로토콜에서 사용자 및 서비스의 TCP 트래픽을 처리합니다.
- Auth Service 로드 밸런서: Proxy Service 인스턴스에서 사용 가능한 Auth Service 인스턴스로 트래픽을 전달하는 로드 밸런서입니다. 이는 Auth Service의 gRPC 엔드포인트로 TLS 트래픽을 처리합니다.
두 로드 밸런서는 수신하는 TCP 트래픽을 투명하게 전달해야 하며, TLS를 종료해서는 안 됩니다. 즉, 이들은 레이어 4 로드 밸런서여야 하며, 레이어 7이 아니어야 합니다(예: HTTP).
로드 밸런서를 구성하여 트래픽을 여러 존(클라우드 공급자 사용 시) 또는 데이터 센터(온프레미스 솔루션 사용 시)에 라우팅하여 가용성을 보장하는 것을 권장합니다.
Proxy Service 로드 밸런서 구성
TLS 라우팅
Proxy Service 로드 밸런서를 구성하는 방식은 텔레포트 클러스터에서 TLS 라우팅을 활성화할 것인지 여부에 따라 달라집니다.
TLS 라우팅이 활성화되면 텔레포트 Proxy Service는 애플리케이션 레이어 프로토콜 협상(ALPN)을 사용하여 HTTPS 포트를 통해 사용자 및 서비스와 모든 통신을 처리합니다. TLS 라우팅 없이는 Proxy Service가 각 프로토콜에 대해 별도의 포트에서 리스닝합니다.
TLS 라우팅의 장점은 간단함입니다: 로드 밸런서에서 공용 인터넷에 단일 포트만 노출할 수 있습니다.
TLS 라우팅의 단점은 HTTPS 트래픽에 대한 레이어 7 로드 밸런싱을 구현할 수 없다는 점입니다. HTTPS 포트에 도달한 트래픽은 지원되는 모든 프로토콜을 사용할 수 있기 때문입니다.
이 가이드에서 설명하는 접근 방식은 최소한의 인프라를 배포하기 위해 레이어 4 로드 밸런서만 사용하지만, HTTPS 트래픽에 대해 별도의 로드 밸런서가 필요한 사용자는 TLS 라우팅을 비활성화해야 합니다.
열린 포트
Proxy Service 로드 밸런서를 구성하여 로드 밸런서의 다음 포트에서 사용 가능한 Proxy Service 인스턴스의 해당 포트로 트래픽을 전달하도록 설정합니다. 구성은 TLS 라우팅을 활성화할 것인지 여부에 따라 다릅니다:
| Load Balancer Port | Proxy Service Port | 설명 |
|---|---|---|
443 | 3080 | TLS 라우팅을 위한 ALPN 포트. |
다음 포트가 필요합니다:
| Load Balancer Port | Proxy Service Port | 설명 |
|---|---|---|
3023 | 3023 | 클라이언트가 연결하는 SSH 포트. |
3024 | 3024 | 방화벽 환경에서 역 SSH 터널을 생성하는 데 사용되는 SSH 포트. |
443 | 3080 | tsh 사용자를 클러스터에 인증하는 HTTPS 연결. 이 연결은 웹 UI 제공에도 사용됩니다. |
해당하는 서비스 사용하지 않으면 다음 포트를 닫아둘 수 있습니다:
| Port | 설명 |
|---|---|
3026 | HTTPS Kubernetes proxy |
3036 | MySQL 포트 |
5432 | Postgres 포트 |
27017 | Mongo 포트 |
Auth Service 로드 밸런서 구성
Auth Service 로드 밸런서는 Auth Service의 gRPC 포트로 트래픽을 전달해야 합니다. 이 가이드에서는 Auth Service 로드 밸런서가 포트 3025에서 사용 가능한 Auth Service 인스턴스의 포트 3025로 트래픽을 전달하도록 구성되었다고 가정합니다.
클러스터 상태 백엔드
텔레포트 Auth Service는 클러스터 상태(예: 동적 구성 리소스) 및 감사 이벤트를 키/값 쌍으로 저장합니다. 고가용성 배포에서는 Auth Service가 텔레포트 인스턴스 클러스터 외부에서 실행되는 키 값 저장소에서 이 데이터를 관리하도록 구성해야 합니다.
Auth Service는 클러스터 상태 및 감사 이벤트를 위한 다음 백엔드를 지원합니다:
- Amazon DynamoDB
- Google Cloud Firestore
- PostgreSQL (Azure 및 자체 호스팅)
- etcd (클러스터 상태 전용)
Amazon DynamoDB, Google Cloud Firestore 및 PostgreSQL에 대해 텔레포트 구성이 클러스터 상태 및 감사 이벤트를 저장하는 두 개의 테이블 또는 컬렉션의 이름을 지정합니다.
Auth Service는 자체 호스팅된 etcd 배포에서도 클러스터 상태를 저장할 수 있습니다. 이 경우 텔레포트는 항목 키 내에서 네임스페이스를 사용하여 클러스터 상태 데이터를 식별합니다.
텔레포트 Auth Service가 테이블 또는 컬렉션에 접근하도록 구성할 때, Auth Service는 시작 시 해당 테이블 또는 컬렉션이 존재하는지 확인합니다. 존재하지 않으면 Auth Service는 이를 생성하려고 시도합니다.
클라우드 공급자의 RBAC 솔루션(예: AWS 또는 Google Cloud IAM)을 구성하여 Auth Service 인스턴스가 선택한 키/값 저장소에서 읽고 쓸 수 있는 권한을 가질 수 있도록 해야 합니다.
기존 테이블 또는 컬렉션을 사용할 경우를 제외하고는 Auth Service는 테이블 및 컬렉션을 생성할 수 있는 권한도 필요합니다(키/값 저장소가 이를 지원하는 경우).
세션 녹화 백엔드
고가용성 텔레포트 배포는 세션 녹화를 지속하기 위해 객체 저장 서비스를 사용합니다. 텔레포트 Auth Service는 두 가지 객체 저장 서비스를 지원합니다:
- Amazon S3 (또는 S3 호환 객체 저장소)
- Google Cloud Storage
- Azure Blob Storage
텔레포트 구성( 구성 섹션에서 설명됨)에서는 Azure Blob Storage, Google Cloud Storage 또는 Amazon S3 호환 서비스를 관리하는 데 사용할 버킷의 이름을 지정해야 합니다.
Auth Service는 시작 시 버킷이 존재하는지 확인합니다. 존재하지 않으면 Auth Service는 이를 생성하려고 시도합니다.
클라우드 공급자의 RBAC 솔루션에서 Auth Service 인스턴스는 버킷을 가져오고 객체를 생성, 가져오기, 목록 및 업데이트할 수 있는 권한이 필요합니다.
Google Cloud Storage에서는 Auth Service 인스턴스가 객체를 삭제할 수 있는 권한도 필요합니다.
기존 버킷에 접근할 계획이 없다면 Auth Service 인스턴스에 버킷을 생성할 수 있는 권한도 부여해야 합니다.
TLS 자격 증명 프로비저닝
고가용성 텔레포트 배포에서는 Let's Encrypt, AWS Certificate Manager, Digicert 또는 신뢰할 수 있는 내부 기관과 같은 인증 기관에서 TLS 자격 증명을 가져오는 시스템이 필요합니다. 이 시스템은 텔레포트 Proxy Service 인스턴스에 이러한 자격 증명을 제공하고 주기적으로 갱신해야 합니다.
단일 인스턴스의 텔레포트 Auth Service 및 Proxy Service를 실행하는 경우, 이 인스턴스를 구성하여 Let's Encrypt에서 자격 증명을 가져올 수 있습니다. 이때 ACME ALPN-01
challenge 를 사용하여 텔레포트가 HTTPS 주소의 ALPN 서버를 제어함을 입증합니다. 텔레포트는 또한 텔레포트에 등록된 각 애플리케이션에 대해 별도의 인증서를 가져옵니다. 예를 들어 grafana.teleport.example.com.
로드 밸런서 뒤에 실행되는 텔레포트 인스턴스에 TLS 자격 증명을 공급하기 위해 Let's Encrypt를 사용하는 고가용성 배포의 경우, ACME DNS-01 challenge를 사용하여 Let's Encrypt에 도메인 이름 소유권을 입증해야 합니다. 이 챌린지에서는 TLS 자격 증명 프로비저닝 시스템이 Let's Encrypt에 의해 예상된 값을 가진 DNS TXT 레코드를 생성합니다.
이 가이드에서 설명하는 구성에서는 각 텔레포트 Proxy Service 인스턴스가 HTTPS에 대한 TLS 자격 증명이 /etc/teleport-tls/tls.key (개인 키) 및 /etc/teleport-tls/tls.crt
(인증서) 파일 경로에서 사용 가능할 것으로 기대합니다.
DNS 서비스
DNS 구역을 설정하여 텔레포트용 레코드를 생성할 수 있습니다. 예: Amazon Route 53 호스팅 구역 또는 Google Cloud DNS 구역.
텔레포트 Proxy Service 레코드
사용자와 서비스는 텔레포트 클러스터에 연결하기 위해 텔레포트 Proxy Service에 도달할 수 있어야 합니다. 고가용성 설정에서는 텔레포트 인스턴스를 로드 밸런서 뒤에 두므로 로드 밸런서를 가리키는 DNS 레코드를 생성해야 합니다.
인프라의 DNS 구성 방식에 따라, 도메인이 example.com이라고 가정했을 때, 이는 다음 중 하나가 되어야 합니다.
| 레코드 유형 | 도메인 이름 | 값 |
|---|---|---|
| A | teleport.example.com | 로드 밸런서의 IP 주소 |
| CNAME | teleport.example.com | 로드 밸런서의 도메인 이름 |
텔레포트에 애플리케이션 등록
텔레포트는 연결된 각 애플리케이션에 서브도메인을 할당합니다(e.g., grafana.teleport.example.com), 따라서 클라이언트가 텔레포트를 통해 애플리케이션에 접근할 수 있도록 서브도메인에 대한 DNS 레코드가 존재해야 합니다.
각 서브도메인에 대해 별도의 DNS 레코드를 생성하거나 *.teleport.example.com과 같은 와일드카드 서브도메인으로 단일 레코드를 생성해야 합니다.
텔레포트에 어떤 애플리케이션이든 등록할 수 있도록 다음 와일드카드 DNS 레코드 중 하나를 생성합니다:
| 레코드 유형 | 도메인 이름 | 값 |
|---|---|---|
| A | *.teleport.example.com | 로드 밸런서의 IP 주소 |
| CNAME | *.teleport.example.com | 로드 밸런서의 도메인 이름 |
Let's Encrypt를 사용하여 텔레포트 인스턴스에 TLS 자격 증명을 제공하는 경우, 앞서 언급한 TLS 자격 증명 시스템은 Let's Encrypt의 DNS-01 챌린지를 충족하기 위해 DNS 레코드를 관리할 수 있는 권한이 필요합니다.
클라우드 관리 솔루션을 사용하는 경우, 클라우드 공급자의 RBAC 시스템(예: AWS IAM)을 사용하여 Proxy Service가 DNS 레코드를 관리할 수 있도록 역할을 부여해야 합니다.
텔레포트 인스턴스
텔레포트 Auth Service와 Proxy Service를 확장 가능한 컴퓨팅 리소스의 두 개 그룹으로 실행하십시오. 예를 들어, Kubernetes 배포 또는 AWS 자동 확장 그룹을 사용할 수 있습니다. 이를 위해 각 Kubernetes pod 또는 가상 머신에서 teleport 바이너리를 실행해야 합니다.
텔레포트를 Kubernetes에서 실행할 계획이라면, teleport-cluster Helm 차트가 Auth Service 및 Proxy Service 풀을 배포합니다. 이 Helm 차트를 사용하는 방법을 보려면 Helm 배포 문서를 읽어보십시오.
고가용성을 보장하기 위해 텔레포트 인스턴스를 여러 존(클라우드 공급자 사용 시) 또는 데이터 센터(온프레미스 솔루션 사용 시)에 걸쳐 배포해야 합니다.
Proxy Service 풀
열린 포트
각 Proxy Service 인스턴스에서 다음 포트가 Proxy Service 로드 밸런서의 트래픽을 허용하는지 확인하십시오. Proxy Service는 이러한 포트를 사용하여 텔레포트 사용자 및 서비스와 통신합니다.
로드 밸런서 구성과 마찬가지로, 텔레포트 인스턴스에서 열어야 할 포트는 TLS 라우팅을 활성화할 것인지 여부에 따라 다릅니다:
| 포트 | 설명 |
|---|---|
3080 | TLS 라우팅을 위한 ALPN 포트. |
다음 포트가 필요합니다:
| 포트 | 설명 |
|---|---|
3023 | 클라이언트가 연결하는 SSH 포트. |
3024 | 방화벽 환경에서 역 SSH 터널을 생성하는 데 사용되는 SSH 포트. |
3080 | 클러스터에 tsh 사용자를 인증하기 위한 HTTPS 연결. 이 연결은 웹 UI 제공에도 사용됩니다. |
해당하는 서비스 사용하지 않으면 다음 포트를 닫아둘 수 있습니다:
| 포트 | 설명 |
|---|---|
3026 | HTTPS Kubernetes proxy |
3036 | MySQL 포트 |
5432 | Postgres 포트 |
이는 로드 밸런서를 구성하는 데 사용한 동일한 포트 테이블입니다.
구성
구성 파일을 생성하고 이를 각 Proxy Service 인스턴스에 /etc/teleport.yaml 경로로 제공합니다. 아래에 고가용성 텔레포트 배포에 필요한 구성 필드를 설명합니다. 이러한 필드는 최소 요건이며, 고가용성 배포를 계획할 때는 환경에 맞춰 더 구체적인 배포 가이드를 따르는 것이 좋습니다.
proxy_service 및 auth_service
proxy_service 섹션은 Proxy Service를 구성합니다. 구성은 클러스터에서 TLS 라우팅을 활성화할 것인지에 따라 달라집니다:
텔레포트 클러스터에서 TLS 라우팅을 활성화하려면, 텔레포트 구성에 다음을 추가하십시오:
version: v3
auth_service:
enabled: false
proxy_service:
enabled: true
public_addr: "mycluster.example.com:443"
https_keypairs:
- key_file: /etc/teleport-tls/tls.key
cert_file: /etc/teleport-tls/tls.crt
이 구성은 TLS 라우팅에 대한 특정 필드가 없습니다. 여기서 사용하는 구성 버전인 v2에서는 기본적으로 TLS 라우팅이 활성화됩니다.
텔레포트 클러스터에서 TLS 라우팅을 비활성화하려면, 텔레포트 구성에 다음을 추가하십시오:
version: v3
auth_service:
proxy_listener_mode: separate
enabled: false
proxy_service:
enabled: true
listen_addr: 0.0.0.0:3023
tunnel_listen_addr: 0.0.0.0:3024
public_addr: "mycluster.example.com:443"
https_keypairs:
- key_file: /etc/teleport-tls/tls.key
cert_file: /etc/teleport-tls/tls.crt
이 구성은 TLS 라우팅을 비활성화하기 위해 auth_service.proxy_listener_mode를 separate로 할당합니다. 또한 Proxy Service에 대한 SSH 포트(listen_addr) 및 역 터널 포트(tunnel_listen_addr)를 명시적으로 할당합니다.
proxy_service 섹션에서는 텔레포트 Proxy Service를 활성화(enabled)하고 TLS 자격 증명을 /etc/teleport-tls 디렉터리에서 찾도록 지시합니다(https_keypairs).
각 Proxy Service 인스턴스에서 Auth Service를 비활성화하도록 auth_service.enabled를 false로 설정하였습니다. Auth Service는 기본적으로 활성화됩니다.
ssh_service
SSH 서비스는 기본적으로 활성화됩니다. 각 텔레포트 인스턴스에서 SSH 서비스를 비활성화하려면 각 인스턴스의 구성 파일에 다음을 추가하십시오:
version: v3
teleport:
storage:
# ...
auth_service:
# ...
proxy_service:
# ...
ssh_service:
enabled: false
이것은 teleport pod가 기본 노드에 직접 접근할 수 없어야 하는 Kubernetes 환경에서 텔레포트를 배포하는 데 적합합니다.
가상 머신 클러스터에 텔레포트를 배포하는 경우, 이 행을 제거하여 SSH 서비스를 실행하고 호스트에 대한 보안 액세스를 활성화해야 합니다.
Auth Service 풀
열린 포트
각 Auth Service 인스턴스에서 다음 포트가 열려 있는지 확인하십시오:
| 포트 | 설명 |
|---|---|
3025 | Proxy Service 인스턴스에 개방할 gRPC 포트. |
라이센스 파일
텔레포트 엔터프라이즈를 배포하는 경우, 라이센스 파일을 다운로드하고 텔레포트 Auth Service 인스턴스에서 사용할 수 있도록 해야 합니다.
Teleport 인증 서비스는 Teleport Enterprise 계정을 인증하기 위해 라이선스 파일을 읽습니다.
라이선스 파일을 얻으려면 Teleport 계정 대시보드로 이동하여 로그인하십시오.
teleport.sh에서 시작하고 Teleport 계정 이름(예: my-company)을 입력하세요.
로그인 후 "GENERATE LICENSE KEY" 버튼이 표시되며, 이 버튼을 클릭하면 새로운 라이선스 파일이 생성되고 이를 다운로드할 수 있습니다.
라이센스 파일은 각 텔레포트 Auth Service 인스턴스에서 /var/lib/teleport/license.pem 경로에서 사용 가능해야 합니다.
구성
구성 파일을 생성하고 이를 각 Auth Service 인스턴스에 /etc/teleport.yaml 경로로 제공합니다. 아래에 고가용성 텔레포트 배포에 필요한 구성 필드를 설명합니다. 이러한 필드는 최소 요건이며, 고가용성 배포를 계획할 때는 환경에 맞춰 더 구체적인 배포 가이드를 따르는 것이 좋습니다.
storage
가장 먼저 작성할 구성 섹션은 storage 섹션으로, Auth Service의 클러스터 상태 백엔드 및 세션 녹화 백엔드를 구성합니다:
version: v3
teleport:
storage:
# ...
storage 섹션에서 설정해야 할 구성 필드는 백엔드 참조를 참조하십시오.
auth_service 및 proxy_service
auth_service 섹션은 Auth Service를 구성합니다:
version: v3
teleport:
storage:
# ...
auth_service:
enabled: true
cluster_name: "mycluster.example.com"
# Teleport Enterprise를 사용하지 않는 경우 제거
license_file: "/var/lib/teleport/license.pem"
proxy_service:
enabled: false
auth_service 섹션에서 텔레포트 Auth Service를 활성화(enabled)하고 엔터프라이즈 라이센스 파일을 /var/lib/teleport/license.pem에서 찾도록 지시합니다(license_file). 텔레포트 오픈 소스 버전을 배포하는 경우는 license_file 필드를 제거해야 합니다.
Auth Service 인스턴스에서 Proxy Service 인스턴스를 사용하기 위해 Proxy Service를 비활성화하도록 proxy_service.enabled를 false로 설정했습니다.
ssh_service
Proxy Service 풀과 마찬가지로 각 텔레포트 인스턴스에서 SSH 서비스를 비활성화하려면 다음을 각 인스턴스의 구성 파일에 추가하십시오:
version: v3
teleport:
storage:
# ...
auth_service:
# ...
proxy_service:
# ...
ssh_service:
enabled: false
다음 단계
계획 다듬기
고가용성 텔레포트 배포에 대한 일반 원칙을 알았으므로, Kubernetes 또는 원하는 클라우드의 가상 머신 클러스터에서 직접 배포를 설계하는 방법을 읽어보십시오:
높은 성능 보장
텔레포트 배포가 예상대로 성능을 발휘하는지 확인하는 방법에 익숙해져야 합니다:
텔레포트 서비스 배포
고가용성 텔레포트 배포가 설정되고 실행되면, 텔레포트 서비스를 추가하여 리소스를 확장할 수 있습니다. 텔레포트 클러스터와 별도의 네트워크에서 이러한 서비스를 실행할 수 있습니다.
등록하는 방법에 대한 정보는 다음을 참조하십시오: