InfoGrab Docs

고가용성 Teleport 클러스터 배포

요약

프로덕션 환경에서 Teleport를 배포할 때, Teleport 클러스터에서 인시던트가 발생하는 동안 사용자가 인프라에 계속 접근할 수 있도록 배포를 설계해야 합니다. 이 가이드에서는 고가용성 Teleport 배포의 구성 요소를 설명합니다.

프로덕션 환경에서 Teleport를 배포할 때, Teleport 클러스터에서 인시던트가 발생하는 동안 사용자가 인프라에 계속 접근할 수 있도록 배포를 설계해야 합니다. 또한 Teleport에 더 많은 사용자와 리소스를 등록함에 따라 Auth Service 및 Proxy Service를 확장할 수 있어야 합니다.

이 가이드에서는 고가용성 Teleport 배포의 구성 요소를 설명합니다.

개요#

고가용성 Teleport 클러스터는 두 개의 중복 teleport 프로세스 풀을 중심으로 구성됩니다. 하나는 Auth Service를 실행하고 다른 하나는 Proxy Service를 실행하며, 각 풀을 지원하는 데 필요한 인프라가 있습니다.

인프라 구성 요소는 다음과 같습니다:

  • 사용자 및 서비스의 트래픽을 사용 가능한 Proxy Service 인스턴스로 전달하는 공개 레이어 4 로드 밸런서.
  • Proxy Service에서 Auth Service의 gRPC API로 트래픽을 전달하는 프라이빗 레이어 4 로드 밸런서. 이는 Teleport가 Auth Service의 백엔드 상태를 관리하고 클러스터의 사용자 및 서비스에 자격 증명을 제공하는 방법입니다.
  • 클러스터 상태 백엔드. 이는 모든 Auth Service 인스턴스가 접근할 수 있는 클러스터 상태 및 감사 이벤트를 위한 키-값 저장소입니다. Auth Service 인스턴스가 키-값 저장소 내의 레코드를 관리할 권한이 필요합니다.
  • 세션 녹화 백엔드. Auth Service가 세션 녹화를 업로드하는 객체 저장 서비스입니다. 세션 녹화 백엔드는 teleport 인스턴스가 저장 서비스 내의 객체를 관리할 권한이 필요합니다.
  • TLS 자격 증명 프로비저닝 시스템. Let's Encrypt(또는 내부 공개 키 인프라)와 같은 인증 기관에서 TLS 자격 증명을 얻고, teleport 인스턴스에 제공하고, 주기적으로 갱신하는 방법이 필요합니다.
  • DNS 서비스. Teleport Proxy Service에 대한 레코드를 생성하는 데 사용할 수 있습니다. TLS 자격 증명에 Let's Encrypt를 사용하는 경우, TLS 자격 증명 프로비저너는 도메인 이름에 대한 제어를 증명하기 위해 DNS 레코드를 관리해야 합니다.

고가용성 Teleport 배포의 아키텍처

레이어 4 로드 밸런서#

고가용성 Teleport 클러스터에는 두 개의 로드 밸런서가 필요합니다:

  • Proxy Service 로드 밸런서: Teleport 클러스터가 실행 중인 네트워크 외부에서 트래픽을 받아 사용 가능한 Proxy Service 인스턴스로 전달하는 로드 밸런서. 이 로드 밸런서는 다양한 애플리케이션 레이어 프로토콜에서 사용자 및 서비스의 TCP 트래픽을 처리합니다.
  • Auth Service 로드 밸런서: Proxy Service 인스턴스에서 사용 가능한 Auth Service 인스턴스로 트래픽을 전달하는 로드 밸런서. Auth Service의 gRPC 엔드포인트에 대한 TLS 트래픽을 처리합니다.

두 로드 밸런서 모두 TLS를 종료하지 않고 수신하는 TCP 트래픽을 투명하게 전달해야 합니다. 즉, 이는 레이어 4 로드 밸런서여야 하며, 레이어 7(예: HTTP)이 아닙니다.

가용성을 보장하기 위해 여러 영역(클라우드 공급자 사용 시) 또는 데이터 센터(온프레미스 솔루션 사용 시)에서 트래픽을 라우팅하도록 로드 밸런서를 구성하는 것이 좋습니다.

Proxy Service 로드 밸런서 구성#

TLS 라우팅#

Proxy Service 로드 밸런서를 구성하는 방법은 Teleport 클러스터에서 TLS 라우팅을 활성화할지 여부에 따라 다릅니다.

TLS 라우팅을 사용하면 Teleport Proxy Service는 ALPN(Application-Layer Protocol Negotiation)을 사용하여 프로토콜에 관계없이 HTTPS 포트를 통해 사용자 및 서비스와의 모든 통신을 처리합니다. TLS 라우팅이 없으면 Proxy Service는 각 프로토콜에 대해 별도의 포트를 수신합니다.

TLS 라우팅의 장점은 단순성입니다: 공개 인터넷에 단일 포트만 노출하면 됩니다.

TLS 라우팅의 단점은 HTTPS 포트에 도달하는 트래픽이 지원되는 모든 프로토콜을 사용할 수 있으므로 HTTPS 트래픽에 레이어 7 로드 밸런싱을 구현하는 것이 불가능하다는 것입니다.

이 가이드에서 설명하는 접근 방식은 배포할 인프라를 최소화하기 위해 레이어 4 로드 밸런서만 사용하지만, HTTPS 트래픽에 별도의 로드 밸런서가 필요한 사용자는 TLS 라우팅을 비활성화해야 합니다.

열린 포트#

TLS 라우팅 활성화 여부에 따라 Proxy Service 로드 밸런서에서 사용 가능한 Proxy Service 인스턴스의 해당 포트로 트래픽을 전달하도록 구성합니다:

TLS 라우팅:

로드 밸런서 포트 Proxy Service 포트 설명
443 3080 TLS 라우팅을 위한 ALPN 포트.

별도 포트 (TLS 라우팅 비활성화):

필수 포트:

로드 밸런서 포트 Proxy Service 포트 설명
3023 3023 클라이언트가 연결하는 SSH 포트.
3024 3024 방화벽 뒤 환경에서 역방향 SSH 터널을 생성하는 데 사용되는 SSH 포트.
443 3080 tsh 사용자를 클러스터에 인증하는 HTTPS 연결. 동일한 연결이 Web UI를 제공하는 데 사용됩니다.

해당 서비스를 사용하지 않는 경우 다음 포트를 닫아 둘 수 있습니다:

포트 설명
3026 HTTPS Kubernetes 프록시
3036 MySQL 포트
5432 Postgres 포트
27017 Mongo 포트

Auth Service 로드 밸런서 구성#

Auth Service 로드 밸런서는 Auth Service의 gRPC 포트로 트래픽을 전달해야 합니다. 이 가이드에서는 포트 3025에서 사용 가능한 Auth Service 인스턴스의 포트 3025로 트래픽을 전달하도록 Auth Service 로드 밸런서를 구성했다고 가정합니다.

클러스터 상태 백엔드#

Teleport Auth Service는 클러스터 상태(예: 동적 구성 리소스) 및 감사 이벤트를 키/값 쌍으로 저장합니다. 고가용성 배포에서는 Teleport 인스턴스 클러스터 외부에서 실행되는 키-값 저장소에서 이 데이터를 관리하도록 Auth Service를 구성해야 합니다.

Auth Service는 클러스터 상태 및 감사 이벤트에 대해 다음 백엔드를 지원합니다:

  • Amazon DynamoDB
  • Google Cloud Firestore
  • PostgreSQL(Azure 및 자체 호스팅)
  • etcd(클러스터 상태만)

Amazon DynamoDB, Google Cloud Firestore 및 PostgreSQL의 경우, Teleport 구성(구성 섹션에서 자세히 설명)에서 Teleport가 클러스터 상태 및 감사 이벤트를 저장하는 두 테이블 또는 컬렉션의 이름을 지정합니다.

Auth Service는 자체 호스팅 etcd 배포에도 클러스터 상태를 저장할 수 있습니다. 이 경우 Teleport는 항목 키 내의 네임스페이스를 사용하여 클러스터 상태 데이터를 식별합니다.

테이블 또는 컬렉션에 접근하도록 Teleport Auth Service를 구성하면 Auth Service는 시작 시 테이블 또는 컬렉션이 존재하는지 확인합니다. 존재하지 않으면 Auth Service가 이를 생성하려고 시도합니다.

필요한 권한

Auth Service 인스턴스가 선택한 키/값 저장소에서 읽고 쓸 수 있도록 클라우드 공급자의 RBAC 솔루션(예: AWS 또는 Google Cloud IAM)을 구성해야 합니다.

사용할 기존 테이블이나 컬렉션이 없는 한, Auth Service에도 테이블 및 컬렉션을 생성할 수 있는 권한이 있어야 합니다(키/값 저장소가 지원하는 경우).

세션 녹화 백엔드#

고가용성 Teleport 배포는 세션 녹화를 유지하기 위해 객체 저장 서비스를 사용합니다. Teleport Auth Service는 두 가지 객체 저장 서비스를 지원합니다:

  • Amazon S3(또는 S3 호환 객체 저장소)
  • Google Cloud Storage
  • Azure Blob Storage

Teleport 구성(구성 섹션에서 설명)에서 세션 녹화를 관리하는 데 사용할 Azure Blob Storage, Google Cloud Storage 또는 Amazon S3 호환 서비스 내의 버킷 이름을 지정해야 합니다.

Auth Service는 시작 시 버킷이 존재하는지 확인합니다. 존재하지 않으면 Auth Service가 이를 생성하려고 시도합니다.

필요한 권한

클라우드 공급자의 RBAC 솔루션에서 Auth Service 인스턴스는 버킷을 가져오고 저장소 내 객체를 생성, 가져오기, 나열 및 업데이트할 수 있는 권한이 필요합니다.

Google Cloud Storage에서 Auth Service 인스턴스는 객체를 삭제할 수 있는 권한도 필요합니다.

Auth Service가 기존 버킷에 접근하도록 구성할 계획이 없는 한, Auth Service 인스턴스에 버킷을 생성할 권한도 부여해야 합니다.

TLS 자격 증명 프로비저닝#

고가용성 Teleport 배포에는 Let's Encrypt, AWS Certificate Manager, Digicert 또는 신뢰할 수 있는 내부 기관과 같은 인증 기관에서 TLS 자격 증명을 가져오는 시스템이 필요합니다. 그런 다음 이 시스템은 Teleport Proxy Service 인스턴스에 이러한 자격 증명을 프로비저닝하고 주기적으로 갱신해야 합니다.

단일 Teleport Auth Service 및 Proxy Service 인스턴스를 실행하는 경우, Let's Encrypt의 ACME ALPN-01 챌린지를 사용하여 자체적으로 자격 증명을 가져오도록 이 인스턴스를 구성할 수 있습니다. Teleport는 Teleport Proxy Service의 HTTPS 주소에서 ALPN 서버를 제어한다는 것을 증명합니다. Teleport는 Teleport에 등록한 각 애플리케이션(예: grafana.teleport.example.com)에 대한 별도의 인증서도 가져옵니다.

로드 밸런서 뒤에서 실행되는 Teleport 인스턴스에 TLS 자격 증명을 제공하기 위해 Let's Encrypt를 사용하는 고가용성 배포의 경우, Let's Encrypt에 도메인 이름 소유권을 증명하기 위해 ACME DNS-01 챌린지를 사용해야 합니다. 이 챌린지에서 TLS 자격 증명 프로비저닝 시스템은 Let's Encrypt가 예상하는 값으로 DNS TXT 레코드를 생성합니다.

이 가이드에서 설명하는 구성에서 각 Teleport Proxy Service 인스턴스는 /etc/teleport-tls/tls.key(개인 키) 및 /etc/teleport-tls/tls.crt(인증서) 파일 경로에서 HTTPS용 TLS 자격 증명을 사용할 수 있어야 합니다.

DNS 서비스#

Teleport를 위한 레코드를 생성할 수 있는 DNS 영역을 설정합니다. 예를 들어 Amazon Route 53 호스팅 영역 또는 Google Cloud DNS 영역입니다.

Teleport Proxy Service 레코드#

사용자와 서비스는 Teleport 클러스터에 연결하기 위해 Teleport Proxy Service에 접근할 수 있어야 합니다. 고가용성 설정은 로드 밸런서 뒤에서 Teleport 인스턴스를 실행하므로 로드 밸런서를 가리키는 DNS 레코드를 생성해야 합니다.

인프라의 DNS 구성 방법에 따라 도메인이 example.com이라고 가정할 때 다음 중 하나가 됩니다:

레코드 유형 도메인 이름 값
A teleport.example.com 로드 밸런서의 IP 주소
CNAME teleport.example.com 로드 밸런서의 도메인 이름

Teleport로 애플리케이션 등록#

Teleport는 Teleport에 연결된 각 애플리케이션에 서브도메인을 할당하므로(예: grafana.teleport.example.com), 클라이언트가 Teleport를 통해 애플리케이션에 접근할 수 있도록 각 애플리케이션별 서브도메인에 대한 DNS 레코드가 존재하는지 확인해야 합니다.

각 서브도메인에 대한 별도의 DNS 레코드를 생성하거나 *.teleport.example.com과 같은 와일드카드 서브도메인으로 단일 레코드를 생성해야 합니다.

Teleport에 모든 애플리케이션을 등록할 수 있도록 다음 와일드카드 DNS 레코드 중 하나를 생성합니다:

레코드 유형 도메인 이름 값
A *.teleport.example.com 로드 밸런서의 IP 주소
CNAME *.teleport.example.com 로드 밸런서의 도메인 이름

필요한 권한

Teleport 인스턴스에 TLS 자격 증명을 제공하기 위해 Let's Encrypt를 사용하는 경우, 앞서 언급한 TLS 자격 증명 시스템은 Let's Encrypt의 DNS-01 챌린지를 충족하기 위해 DNS 레코드를 관리할 권한이 필요합니다.

클라우드 관리 솔루션을 사용하는 경우, 클라우드 공급자의 RBAC 시스템(예: AWS IAM)을 사용하여 Proxy Service에 DNS 레코드를 관리할 역할을 부여해야 합니다.

Teleport 인스턴스#

두 개의 확장 가능한 컴퓨팅 리소스 그룹으로 Teleport Auth Service 및 Proxy Service를 실행합니다. 예를 들어 Kubernetes 디플로이먼트 또는 AWS Auto Scaling 그룹을 사용합니다. 이를 위해 그룹의 각 Kubernetes 파드 또는 가상 머신에서 teleport 바이너리를 실행해야 합니다.

팁

Kubernetes에서 Teleport를 실행할 계획이라면 teleport-cluster Helm 차트가 Auth Service 및 Proxy Service 풀을 배포합니다. 이 Helm 차트 사용 방법은 Helm 배포 문서를 참조하세요.

가용성을 보장하기 위해 여러 영역(클라우드 공급자 사용 시) 또는 데이터 센터(온프레미스 솔루션 사용 시)에 Teleport 인스턴스를 배포해야 합니다.

Proxy Service 풀#

열린 포트#

각 Proxy Service 인스턴스에서 다음 포트가 Proxy Service 로드 밸런서의 트래픽을 허용하는지 확인합니다. Proxy Service는 이 포트를 사용하여 Teleport 사용자 및 서비스와 통신합니다.

로드 밸런서 구성과 마찬가지로 TLS 라우팅 활성화 여부에 따라 Teleport 인스턴스에서 열어야 할 포트가 달라집니다:

TLS 라우팅:

포트 설명
3080 TLS 라우팅을 위한 ALPN 포트.

별도 포트:

필수 포트:

포트 설명
3023 클라이언트가 연결하는 SSH 포트.
3024 방화벽 뒤 환경에서 역방향 SSH 터널을 생성하는 데 사용되는 SSH 포트.
3080 tsh 사용자를 클러스터에 인증하는 HTTPS 연결. 동일한 연결이 Web UI를 제공하는 데 사용됩니다.

해당 서비스를 사용하지 않는 경우 다음 포트를 닫아 둘 수 있습니다:

포트 설명
3026 HTTPS Kubernetes 프록시
3036 MySQL 포트
5432 Postgres 포트

이것은 로드 밸런서를 구성하는 데 사용한 것과 동일한 포트 테이블입니다.

구성#

각 Proxy Service 인스턴스에 /etc/teleport.yaml에 구성 파일을 작성합니다. 아래에서 고가용성 Teleport 배포에 필요한 구성 필드를 설명합니다. 이것은 최소 요구사항이며, 고가용성 배포를 계획할 때 환경에 맞는 더 구체적인 배포 가이드를 따르는 것이 좋습니다.

proxy_service 및 auth_service#

proxy_service 섹션은 Proxy Service를 구성합니다. 클러스터에서 TLS 라우팅을 활성화할지 여부에 따라 구성이 달라집니다:

TLS 라우팅:

TLS 라우팅을 활성화하려면 Teleport 구성에 다음을 추가합니다:

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 라우팅을 비활성화하려면 Teleport 구성에 다음을 추가합니다:

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 섹션에서 Teleport Proxy Service(enabled)를 활성화하고 /etc/teleport-tls 디렉터리에서 TLS 자격 증명을 찾도록 지시했습니다(https_keypairs).

기본적으로 활성화된 Auth Service를 각 Proxy Service 인스턴스에서 비활성화하기 위해 auth_service.enabled를 false로 설정했습니다.

ssh_service#

SSH 서비스는 기본적으로 활성화되어 있습니다. 각 Teleport 인스턴스의 구성 파일에 다음을 추가하여 SSH 서비스를 비활성화할 수 있습니다:

version: v3
teleport:
  storage:
  # ...
auth_service:
# ...
proxy_service:
# ...
ssh_service:
  enabled: false

이것은 teleport 파드가 기본 노드에 직접 접근해서는 안 되는 Kubernetes에서 Teleport를 배포하는 데 적합합니다.

가상 머신 클러스터에 Teleport를 배포하는 경우, 이 줄을 제거하여 SSH 서비스를 실행하고 호스트에 대한 보안 접근을 활성화합니다.

Auth Service 풀#

열린 포트#

각 Auth Service 인스턴스에서 다음 포트가 열려 있는지 확인합니다:

포트 설명
3025 Proxy Service 인스턴스에 열어야 하는 gRPC 포트.

라이선스 파일#

Teleport Enterprise를 배포하는 경우 라이선스 파일을 다운로드하여 Teleport Auth Service 인스턴스에서 사용 가능하도록 해야 합니다.

라이선스 파일은 각 Teleport Auth Service 인스턴스의 /var/lib/teleport/license.pem에서 사용 가능해야 합니다.

구성#

각 Auth Service 인스턴스에 /etc/teleport.yaml에 구성 파일을 작성합니다. 아래에서 고가용성 Teleport 배포에 필요한 구성 필드를 설명합니다. 이것은 최소 요구사항이며, 고가용성 배포를 계획할 때 환경에 맞는 더 구체적인 배포 가이드를 따르는 것이 좋습니다.

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 섹션에서 Teleport Auth Service(enabled)를 활성화하고 /var/lib/teleport/license.pem에서 Enterprise 라이선스 파일을 찾도록 지시했습니다(license_file). 오픈 소스 버전의 Teleport를 배포하는 경우 license_file 필드를 제거합니다.

전용 풀에서 Proxy Service 인스턴스를 실행하고 있으므로 proxy_service.enabled를 false로 설정하여 Auth Service 인스턴스에서 Proxy Service를 비활성화했습니다.

ssh_service#

Proxy Service 풀과 마찬가지로 각 인스턴스의 구성 파일에 다음을 추가하여 각 Teleport 인스턴스에서 SSH 서비스를 비활성화할 수 있습니다:

version: v3
teleport:
  storage:
  # ...
auth_service:
# ...
proxy_service:
# ...
ssh_service:
  enabled: false

다음 단계#

계획 구체화#

고가용성 Teleport 배포의 일반 원칙을 알았으므로 이제 선택한 클라우드의 Kubernetes 또는 가상 머신 클러스터에서 자체 배포를 설계하는 방법에 대해 읽어보세요:

고성능 보장#

Teleport 배포가 예상대로 수행되는지 확인하는 방법에 대해서도 익숙해져야 합니다:

Teleport 서비스 배포#

고가용성 Teleport 배포가 실행되면 Teleport 서비스를 시작하여 리소스를 추가할 수 있습니다. Teleport 클러스터와 별도의 네트워크에서 이러한 서비스를 실행할 수 있습니다.

시작하려면 다음을 등록하는 방법에 대해 읽어보세요:

고가용성 Teleport 클러스터 배포

원문 보기
요약

프로덕션 환경에서 Teleport를 배포할 때, Teleport 클러스터에서 인시던트가 발생하는 동안 사용자가 인프라에 계속 접근할 수 있도록 배포를 설계해야 합니다. 이 가이드에서는 고가용성 Teleport 배포의 구성 요소를 설명합니다.

프로덕션 환경에서 Teleport를 배포할 때, Teleport 클러스터에서 인시던트가 발생하는 동안 사용자가 인프라에 계속 접근할 수 있도록 배포를 설계해야 합니다. 또한 Teleport에 더 많은 사용자와 리소스를 등록함에 따라 Auth Service 및 Proxy Service를 확장할 수 있어야 합니다.

이 가이드에서는 고가용성 Teleport 배포의 구성 요소를 설명합니다.

개요#

고가용성 Teleport 클러스터는 두 개의 중복 teleport 프로세스 풀을 중심으로 구성됩니다. 하나는 Auth Service를 실행하고 다른 하나는 Proxy Service를 실행하며, 각 풀을 지원하는 데 필요한 인프라가 있습니다.

인프라 구성 요소는 다음과 같습니다:

  • 사용자 및 서비스의 트래픽을 사용 가능한 Proxy Service 인스턴스로 전달하는 공개 레이어 4 로드 밸런서.
  • Proxy Service에서 Auth Service의 gRPC API로 트래픽을 전달하는 프라이빗 레이어 4 로드 밸런서. 이는 Teleport가 Auth Service의 백엔드 상태를 관리하고 클러스터의 사용자 및 서비스에 자격 증명을 제공하는 방법입니다.
  • 클러스터 상태 백엔드. 이는 모든 Auth Service 인스턴스가 접근할 수 있는 클러스터 상태 및 감사 이벤트를 위한 키-값 저장소입니다. Auth Service 인스턴스가 키-값 저장소 내의 레코드를 관리할 권한이 필요합니다.
  • 세션 녹화 백엔드. Auth Service가 세션 녹화를 업로드하는 객체 저장 서비스입니다. 세션 녹화 백엔드는 teleport 인스턴스가 저장 서비스 내의 객체를 관리할 권한이 필요합니다.
  • TLS 자격 증명 프로비저닝 시스템. Let's Encrypt(또는 내부 공개 키 인프라)와 같은 인증 기관에서 TLS 자격 증명을 얻고, teleport 인스턴스에 제공하고, 주기적으로 갱신하는 방법이 필요합니다.
  • DNS 서비스. Teleport Proxy Service에 대한 레코드를 생성하는 데 사용할 수 있습니다. TLS 자격 증명에 Let's Encrypt를 사용하는 경우, TLS 자격 증명 프로비저너는 도메인 이름에 대한 제어를 증명하기 위해 DNS 레코드를 관리해야 합니다.

고가용성 Teleport 배포의 아키텍처

레이어 4 로드 밸런서#

고가용성 Teleport 클러스터에는 두 개의 로드 밸런서가 필요합니다:

  • Proxy Service 로드 밸런서: Teleport 클러스터가 실행 중인 네트워크 외부에서 트래픽을 받아 사용 가능한 Proxy Service 인스턴스로 전달하는 로드 밸런서. 이 로드 밸런서는 다양한 애플리케이션 레이어 프로토콜에서 사용자 및 서비스의 TCP 트래픽을 처리합니다.
  • Auth Service 로드 밸런서: Proxy Service 인스턴스에서 사용 가능한 Auth Service 인스턴스로 트래픽을 전달하는 로드 밸런서. Auth Service의 gRPC 엔드포인트에 대한 TLS 트래픽을 처리합니다.

두 로드 밸런서 모두 TLS를 종료하지 않고 수신하는 TCP 트래픽을 투명하게 전달해야 합니다. 즉, 이는 레이어 4 로드 밸런서여야 하며, 레이어 7(예: HTTP)이 아닙니다.

가용성을 보장하기 위해 여러 영역(클라우드 공급자 사용 시) 또는 데이터 센터(온프레미스 솔루션 사용 시)에서 트래픽을 라우팅하도록 로드 밸런서를 구성하는 것이 좋습니다.

Proxy Service 로드 밸런서 구성#

TLS 라우팅#

Proxy Service 로드 밸런서를 구성하는 방법은 Teleport 클러스터에서 TLS 라우팅을 활성화할지 여부에 따라 다릅니다.

TLS 라우팅을 사용하면 Teleport Proxy Service는 ALPN(Application-Layer Protocol Negotiation)을 사용하여 프로토콜에 관계없이 HTTPS 포트를 통해 사용자 및 서비스와의 모든 통신을 처리합니다. TLS 라우팅이 없으면 Proxy Service는 각 프로토콜에 대해 별도의 포트를 수신합니다.

TLS 라우팅의 장점은 단순성입니다: 공개 인터넷에 단일 포트만 노출하면 됩니다.

TLS 라우팅의 단점은 HTTPS 포트에 도달하는 트래픽이 지원되는 모든 프로토콜을 사용할 수 있으므로 HTTPS 트래픽에 레이어 7 로드 밸런싱을 구현하는 것이 불가능하다는 것입니다.

이 가이드에서 설명하는 접근 방식은 배포할 인프라를 최소화하기 위해 레이어 4 로드 밸런서만 사용하지만, HTTPS 트래픽에 별도의 로드 밸런서가 필요한 사용자는 TLS 라우팅을 비활성화해야 합니다.

열린 포트#

TLS 라우팅 활성화 여부에 따라 Proxy Service 로드 밸런서에서 사용 가능한 Proxy Service 인스턴스의 해당 포트로 트래픽을 전달하도록 구성합니다:

TLS 라우팅:

로드 밸런서 포트 Proxy Service 포트 설명
443 3080 TLS 라우팅을 위한 ALPN 포트.

별도 포트 (TLS 라우팅 비활성화):

필수 포트:

로드 밸런서 포트 Proxy Service 포트 설명
3023 3023 클라이언트가 연결하는 SSH 포트.
3024 3024 방화벽 뒤 환경에서 역방향 SSH 터널을 생성하는 데 사용되는 SSH 포트.
443 3080 tsh 사용자를 클러스터에 인증하는 HTTPS 연결. 동일한 연결이 Web UI를 제공하는 데 사용됩니다.

해당 서비스를 사용하지 않는 경우 다음 포트를 닫아 둘 수 있습니다:

포트 설명
3026 HTTPS Kubernetes 프록시
3036 MySQL 포트
5432 Postgres 포트
27017 Mongo 포트

Auth Service 로드 밸런서 구성#

Auth Service 로드 밸런서는 Auth Service의 gRPC 포트로 트래픽을 전달해야 합니다. 이 가이드에서는 포트 3025에서 사용 가능한 Auth Service 인스턴스의 포트 3025로 트래픽을 전달하도록 Auth Service 로드 밸런서를 구성했다고 가정합니다.

클러스터 상태 백엔드#

Teleport Auth Service는 클러스터 상태(예: 동적 구성 리소스) 및 감사 이벤트를 키/값 쌍으로 저장합니다. 고가용성 배포에서는 Teleport 인스턴스 클러스터 외부에서 실행되는 키-값 저장소에서 이 데이터를 관리하도록 Auth Service를 구성해야 합니다.

Auth Service는 클러스터 상태 및 감사 이벤트에 대해 다음 백엔드를 지원합니다:

  • Amazon DynamoDB
  • Google Cloud Firestore
  • PostgreSQL(Azure 및 자체 호스팅)
  • etcd(클러스터 상태만)

Amazon DynamoDB, Google Cloud Firestore 및 PostgreSQL의 경우, Teleport 구성(구성 섹션에서 자세히 설명)에서 Teleport가 클러스터 상태 및 감사 이벤트를 저장하는 두 테이블 또는 컬렉션의 이름을 지정합니다.

Auth Service는 자체 호스팅 etcd 배포에도 클러스터 상태를 저장할 수 있습니다. 이 경우 Teleport는 항목 키 내의 네임스페이스를 사용하여 클러스터 상태 데이터를 식별합니다.

테이블 또는 컬렉션에 접근하도록 Teleport Auth Service를 구성하면 Auth Service는 시작 시 테이블 또는 컬렉션이 존재하는지 확인합니다. 존재하지 않으면 Auth Service가 이를 생성하려고 시도합니다.

필요한 권한

Auth Service 인스턴스가 선택한 키/값 저장소에서 읽고 쓸 수 있도록 클라우드 공급자의 RBAC 솔루션(예: AWS 또는 Google Cloud IAM)을 구성해야 합니다.

사용할 기존 테이블이나 컬렉션이 없는 한, Auth Service에도 테이블 및 컬렉션을 생성할 수 있는 권한이 있어야 합니다(키/값 저장소가 지원하는 경우).

세션 녹화 백엔드#

고가용성 Teleport 배포는 세션 녹화를 유지하기 위해 객체 저장 서비스를 사용합니다. Teleport Auth Service는 두 가지 객체 저장 서비스를 지원합니다:

  • Amazon S3(또는 S3 호환 객체 저장소)
  • Google Cloud Storage
  • Azure Blob Storage

Teleport 구성(구성 섹션에서 설명)에서 세션 녹화를 관리하는 데 사용할 Azure Blob Storage, Google Cloud Storage 또는 Amazon S3 호환 서비스 내의 버킷 이름을 지정해야 합니다.

Auth Service는 시작 시 버킷이 존재하는지 확인합니다. 존재하지 않으면 Auth Service가 이를 생성하려고 시도합니다.

필요한 권한

클라우드 공급자의 RBAC 솔루션에서 Auth Service 인스턴스는 버킷을 가져오고 저장소 내 객체를 생성, 가져오기, 나열 및 업데이트할 수 있는 권한이 필요합니다.

Google Cloud Storage에서 Auth Service 인스턴스는 객체를 삭제할 수 있는 권한도 필요합니다.

Auth Service가 기존 버킷에 접근하도록 구성할 계획이 없는 한, Auth Service 인스턴스에 버킷을 생성할 권한도 부여해야 합니다.

TLS 자격 증명 프로비저닝#

고가용성 Teleport 배포에는 Let's Encrypt, AWS Certificate Manager, Digicert 또는 신뢰할 수 있는 내부 기관과 같은 인증 기관에서 TLS 자격 증명을 가져오는 시스템이 필요합니다. 그런 다음 이 시스템은 Teleport Proxy Service 인스턴스에 이러한 자격 증명을 프로비저닝하고 주기적으로 갱신해야 합니다.

단일 Teleport Auth Service 및 Proxy Service 인스턴스를 실행하는 경우, Let's Encrypt의 ACME ALPN-01 챌린지를 사용하여 자체적으로 자격 증명을 가져오도록 이 인스턴스를 구성할 수 있습니다. Teleport는 Teleport Proxy Service의 HTTPS 주소에서 ALPN 서버를 제어한다는 것을 증명합니다. Teleport는 Teleport에 등록한 각 애플리케이션(예: grafana.teleport.example.com)에 대한 별도의 인증서도 가져옵니다.

로드 밸런서 뒤에서 실행되는 Teleport 인스턴스에 TLS 자격 증명을 제공하기 위해 Let's Encrypt를 사용하는 고가용성 배포의 경우, Let's Encrypt에 도메인 이름 소유권을 증명하기 위해 ACME DNS-01 챌린지를 사용해야 합니다. 이 챌린지에서 TLS 자격 증명 프로비저닝 시스템은 Let's Encrypt가 예상하는 값으로 DNS TXT 레코드를 생성합니다.

이 가이드에서 설명하는 구성에서 각 Teleport Proxy Service 인스턴스는 /etc/teleport-tls/tls.key(개인 키) 및 /etc/teleport-tls/tls.crt(인증서) 파일 경로에서 HTTPS용 TLS 자격 증명을 사용할 수 있어야 합니다.

DNS 서비스#

Teleport를 위한 레코드를 생성할 수 있는 DNS 영역을 설정합니다. 예를 들어 Amazon Route 53 호스팅 영역 또는 Google Cloud DNS 영역입니다.

Teleport Proxy Service 레코드#

사용자와 서비스는 Teleport 클러스터에 연결하기 위해 Teleport Proxy Service에 접근할 수 있어야 합니다. 고가용성 설정은 로드 밸런서 뒤에서 Teleport 인스턴스를 실행하므로 로드 밸런서를 가리키는 DNS 레코드를 생성해야 합니다.

인프라의 DNS 구성 방법에 따라 도메인이 example.com이라고 가정할 때 다음 중 하나가 됩니다:

레코드 유형 도메인 이름 값
A teleport.example.com 로드 밸런서의 IP 주소
CNAME teleport.example.com 로드 밸런서의 도메인 이름

Teleport로 애플리케이션 등록#

Teleport는 Teleport에 연결된 각 애플리케이션에 서브도메인을 할당하므로(예: grafana.teleport.example.com), 클라이언트가 Teleport를 통해 애플리케이션에 접근할 수 있도록 각 애플리케이션별 서브도메인에 대한 DNS 레코드가 존재하는지 확인해야 합니다.

각 서브도메인에 대한 별도의 DNS 레코드를 생성하거나 *.teleport.example.com과 같은 와일드카드 서브도메인으로 단일 레코드를 생성해야 합니다.

Teleport에 모든 애플리케이션을 등록할 수 있도록 다음 와일드카드 DNS 레코드 중 하나를 생성합니다:

레코드 유형 도메인 이름 값
A *.teleport.example.com 로드 밸런서의 IP 주소
CNAME *.teleport.example.com 로드 밸런서의 도메인 이름

필요한 권한

Teleport 인스턴스에 TLS 자격 증명을 제공하기 위해 Let's Encrypt를 사용하는 경우, 앞서 언급한 TLS 자격 증명 시스템은 Let's Encrypt의 DNS-01 챌린지를 충족하기 위해 DNS 레코드를 관리할 권한이 필요합니다.

클라우드 관리 솔루션을 사용하는 경우, 클라우드 공급자의 RBAC 시스템(예: AWS IAM)을 사용하여 Proxy Service에 DNS 레코드를 관리할 역할을 부여해야 합니다.

Teleport 인스턴스#

두 개의 확장 가능한 컴퓨팅 리소스 그룹으로 Teleport Auth Service 및 Proxy Service를 실행합니다. 예를 들어 Kubernetes 디플로이먼트 또는 AWS Auto Scaling 그룹을 사용합니다. 이를 위해 그룹의 각 Kubernetes 파드 또는 가상 머신에서 teleport 바이너리를 실행해야 합니다.

팁

Kubernetes에서 Teleport를 실행할 계획이라면 teleport-cluster Helm 차트가 Auth Service 및 Proxy Service 풀을 배포합니다. 이 Helm 차트 사용 방법은 Helm 배포 문서를 참조하세요.

가용성을 보장하기 위해 여러 영역(클라우드 공급자 사용 시) 또는 데이터 센터(온프레미스 솔루션 사용 시)에 Teleport 인스턴스를 배포해야 합니다.

Proxy Service 풀#

열린 포트#

각 Proxy Service 인스턴스에서 다음 포트가 Proxy Service 로드 밸런서의 트래픽을 허용하는지 확인합니다. Proxy Service는 이 포트를 사용하여 Teleport 사용자 및 서비스와 통신합니다.

로드 밸런서 구성과 마찬가지로 TLS 라우팅 활성화 여부에 따라 Teleport 인스턴스에서 열어야 할 포트가 달라집니다:

TLS 라우팅:

포트 설명
3080 TLS 라우팅을 위한 ALPN 포트.

별도 포트:

필수 포트:

포트 설명
3023 클라이언트가 연결하는 SSH 포트.
3024 방화벽 뒤 환경에서 역방향 SSH 터널을 생성하는 데 사용되는 SSH 포트.
3080 tsh 사용자를 클러스터에 인증하는 HTTPS 연결. 동일한 연결이 Web UI를 제공하는 데 사용됩니다.

해당 서비스를 사용하지 않는 경우 다음 포트를 닫아 둘 수 있습니다:

포트 설명
3026 HTTPS Kubernetes 프록시
3036 MySQL 포트
5432 Postgres 포트

이것은 로드 밸런서를 구성하는 데 사용한 것과 동일한 포트 테이블입니다.

구성#

각 Proxy Service 인스턴스에 /etc/teleport.yaml에 구성 파일을 작성합니다. 아래에서 고가용성 Teleport 배포에 필요한 구성 필드를 설명합니다. 이것은 최소 요구사항이며, 고가용성 배포를 계획할 때 환경에 맞는 더 구체적인 배포 가이드를 따르는 것이 좋습니다.

proxy_service 및 auth_service#

proxy_service 섹션은 Proxy Service를 구성합니다. 클러스터에서 TLS 라우팅을 활성화할지 여부에 따라 구성이 달라집니다:

TLS 라우팅:

TLS 라우팅을 활성화하려면 Teleport 구성에 다음을 추가합니다:

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 라우팅을 비활성화하려면 Teleport 구성에 다음을 추가합니다:

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 섹션에서 Teleport Proxy Service(enabled)를 활성화하고 /etc/teleport-tls 디렉터리에서 TLS 자격 증명을 찾도록 지시했습니다(https_keypairs).

기본적으로 활성화된 Auth Service를 각 Proxy Service 인스턴스에서 비활성화하기 위해 auth_service.enabled를 false로 설정했습니다.

ssh_service#

SSH 서비스는 기본적으로 활성화되어 있습니다. 각 Teleport 인스턴스의 구성 파일에 다음을 추가하여 SSH 서비스를 비활성화할 수 있습니다:

version: v3
teleport:
  storage:
  # ...
auth_service:
# ...
proxy_service:
# ...
ssh_service:
  enabled: false

이것은 teleport 파드가 기본 노드에 직접 접근해서는 안 되는 Kubernetes에서 Teleport를 배포하는 데 적합합니다.

가상 머신 클러스터에 Teleport를 배포하는 경우, 이 줄을 제거하여 SSH 서비스를 실행하고 호스트에 대한 보안 접근을 활성화합니다.

Auth Service 풀#

열린 포트#

각 Auth Service 인스턴스에서 다음 포트가 열려 있는지 확인합니다:

포트 설명
3025 Proxy Service 인스턴스에 열어야 하는 gRPC 포트.

라이선스 파일#

Teleport Enterprise를 배포하는 경우 라이선스 파일을 다운로드하여 Teleport Auth Service 인스턴스에서 사용 가능하도록 해야 합니다.

라이선스 파일은 각 Teleport Auth Service 인스턴스의 /var/lib/teleport/license.pem에서 사용 가능해야 합니다.

구성#

각 Auth Service 인스턴스에 /etc/teleport.yaml에 구성 파일을 작성합니다. 아래에서 고가용성 Teleport 배포에 필요한 구성 필드를 설명합니다. 이것은 최소 요구사항이며, 고가용성 배포를 계획할 때 환경에 맞는 더 구체적인 배포 가이드를 따르는 것이 좋습니다.

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 섹션에서 Teleport Auth Service(enabled)를 활성화하고 /var/lib/teleport/license.pem에서 Enterprise 라이선스 파일을 찾도록 지시했습니다(license_file). 오픈 소스 버전의 Teleport를 배포하는 경우 license_file 필드를 제거합니다.

전용 풀에서 Proxy Service 인스턴스를 실행하고 있으므로 proxy_service.enabled를 false로 설정하여 Auth Service 인스턴스에서 Proxy Service를 비활성화했습니다.

ssh_service#

Proxy Service 풀과 마찬가지로 각 인스턴스의 구성 파일에 다음을 추가하여 각 Teleport 인스턴스에서 SSH 서비스를 비활성화할 수 있습니다:

version: v3
teleport:
  storage:
  # ...
auth_service:
# ...
proxy_service:
# ...
ssh_service:
  enabled: false

다음 단계#

계획 구체화#

고가용성 Teleport 배포의 일반 원칙을 알았으므로 이제 선택한 클라우드의 Kubernetes 또는 가상 머신 클러스터에서 자체 배포를 설계하는 방법에 대해 읽어보세요:

고성능 보장#

Teleport 배포가 예상대로 수행되는지 확인하는 방법에 대해서도 익숙해져야 합니다:

Teleport 서비스 배포#

고가용성 Teleport 배포가 실행되면 Teleport 서비스를 시작하여 리소스를 추가할 수 있습니다. Teleport 클러스터와 별도의 네트워크에서 이러한 서비스를 실행할 수 있습니다.

시작하려면 다음을 등록하는 방법에 대해 읽어보세요: