Infograb logo
고가용성 Teleport 클러스터 배포

Teleport를 프로덕션 환경에 배포할 때, 사용자가 Teleport 클러스터의 사고 중에도 인프라에 계속 접근할 수 있도록 배포를 설계해야 합니다. 또한, 더 많은 사용자와 리소스를 Teleport에 등록하면서 Auth Service와 Proxy Service를 확장할 수 있도록 해야 합니다.

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

Tip

Teleport Enterprise Cloud는 이 설정을 자동으로 처리하므로 즉시 인프라에 대한 안전한 액세스를 제공할 수 있습니다.

Teleport Enterprise Cloud의 무료 평가판으로 시작하세요.

개요

고가용성 Teleport 클러스터는 redundant teleport 프로세스의 두 풀로 구성되며, 하나는 Auth Service를 실행하고 다른 하나는 Proxy Service를 실행합니다. 각 풀을 지원하는 데 필요한 인프라가 포함됩니다.

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

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

Layer 4 로드 밸런서

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

  • Proxy Service 로드 밸런서: Teleport 클러스터가 실행되고 있는 네트워크 외부에서 트래픽을 수신하고 사용 가능한 Proxy Service 인스턴스로 전달하는 로드 밸런서입니다. 이 로드 밸런서는 다양한 애플리케이션 레이어 프로토콜의 사용자 및 서비스로부터 오는 TCP 트래픽을 처리합니다.
  • Auth Service 로드 밸런서: Proxy Service 인스턴스로부터 사용 가능한 Auth Service 인스턴스로 트래픽을 전달하는 로드 밸런서입니다. 이는 Auth Service의 gRPC 끝점으로의 TLS 트래픽을 처리합니다.

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

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

Proxy Service 로드 밸런서 구성

TLS 라우팅

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

TLS 라우팅을 사용하면 Teleport Proxy Service는 애플리케이션 레이어 프로토콜 협상을 통해 모든 사용자와 서비스와의 통신을 HTTPS 포트를 통해 처리합니다. TLS 라우팅 없이 Proxy Service는 각 프로토콜에 대해 별도의 포트를 수신합니다.

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

TLS 라우팅의 단점은 HTTPS 트래픽에 대해 Layer 7 로드 밸런싱을 구현할 수 없다는 것입니다. HTTPS 포트에 도달한 트래픽은 지원되는 모든 프로토콜을 사용할 수 있기 때문입니다.

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

열린 포트

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

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

다음 포트가 필요합니다:

로드 밸런서 포트Proxy Service 포트설명
30233023클라이언트가 연결하는 SSH 포트.
30243024방화벽 뒤의 환경에서 역 SSH 터널을 생성하는데 사용되는 SSH 포트.
4433080클러스터에 tsh 사용자를 인증하는 HTTPS 연결. 같은 연결이 웹 UI를 제공하는 데 사용됩니다.

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

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

Auth Service 로드 밸런서 구성

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

클러스터 상태 백엔드

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

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

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

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

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

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

필요한 권한

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

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

세션 녹화 백엔드

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

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

Teleport 구성(자세한 내용은 Configuration 섹션 참조)에서는 Azure Blob Storage, Google Cloud Storage 또는 Amazon S3 호환 서비스 내에서 세션 녹화를 관리하기 위해 사용할 버킷 이름을 지정해야 합니다.

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

필요한 권한

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

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

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

TLS 자격 증명 프로비저닝

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

일반 Teleport Auth Service와 Proxy Service의 단일 인스턴스를 실행하는 경우, 이 인스턴스를 구성하여 Let's Encrypt에서 자격 증명을 가져오도록 할 수 있습니다. ACME ALPN-01 challenge 를 사용하여 Teleport가 Teleport Proxy Service의 HTTPS 주소에서 ALPN 서버를 제어하고 있음을 입증합니다. Teleport는 또한 Teleport에 등록된 각 애플리케이션에 대해 별도의 인증서를 가져옵니다. 예: grafana.teleport.example.com .

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

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

DNS 서비스

Teleport에 대한 레코드를 생성할 수 있는 DNS 존을 설정합니다. 예: Amazon Route 53 호스팅 존 또는 Google Cloud DNS 존.

Teleport Proxy Service 레코드

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

인프라의 DNS 구성이 어떻게 구성되어 있는지에 따라, 도메인이 example.com 이라고 가정할 때, 다음 중 하나가 될 것입니다:

레코드 유형도메인 이름
Ateleport.example.com로드 밸런서의 IP 주소
CNAMEteleport.example.com로드 밸런서의 도메인 이름

Teleport에 애플리케이션 등록

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

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

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

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

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

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

Teleport 인스턴스

Teleport Auth 서비스와 Proxy 서비스를 두 개의 확장 가능한 컴퓨팅 리소스 그룹으로 실행하십시오. 예를 들어 Kubernetes 배포 또는 AWS Auto Scaling 그룹을 사용할 수 있습니다. 이는 각 Kubernetes pod 또는 가상 머신에서 teleport 바이너리를 실행하는 것을 요구합니다.

Kubernetes에서 Teleport를 실행할 계획이라면 teleport-cluster Helm 차트가 Auth 서비스와 Proxy 서비스 풀을 배포해 줍니다. 이 Helm 차트를 사용하는 방법은 Helm Deployments 문서를 참조하십시오.

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

Proxy 서비스 풀

개방 포트

각 Proxy 서비스 인스턴스에서 Proxy 서비스 로드 밸런서로부터 트래픽이 허용되는 다음 포트를 확인하십시오. Proxy 서비스는 Teleport 사용자 및 서비스와 통신하기 위해 이러한 포트를 사용합니다.

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

포트설명
3080TLS 라우팅용 ALPN 포트.

이 포트는 필수입니다:

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

해당 서비스가 사용되지 않는 경우 이러한 포트는 닫아도 됩니다:

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

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

구성

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

proxy_serviceauth_service

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

Teleport 클러스터에서 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 라우팅이 기본적으로 활성화되어 있습니다.

Teleport 클러스터에서 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

이 구성은 auth_service.proxy_listener_modeseparate 로 설정하여 TLS 라우팅을 비활성화합니다. 또한 Proxy 서비스에 대한 SSH 포트(listen_addr )와 리버스 터널 포트(tunnel_listen_addr )를 명시적으로 할당합니다.

proxy_service 섹션에서는 Teleport Proxy 서비스(enabled )를 활성화하고 TLS 자격 증명을 /etc/teleport-tls 디렉토리에서 찾도록 지시했습니다(https_keypairs ).

각 Proxy 서비스 인스턴스에서 Auth 서비스를 비활성화하도록 auth_service.enabledfalse 로 설정했습니다. 이는 기본적으로 활성화되어 있습니다.

ssh_service

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

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

이는 teleport 포드가 기본 노드에 직접 접근할 수 없는 Kubernetes에서 Teleport를 배포하는 데 적합합니다.

가상 머신 클러스터에 Teleport를 배포하는 경우, SSH 서비스를 실행하고 호스트에 대한 안전한 접근을 활성화하려면 이 줄을 제거하십시오.

인증 서비스 풀

열린 포트

각 인증 서비스 인스턴스에서 다음 포트가 열려 있는지 확인하십시오:

Port설명
3025Proxy 서비스 인스턴스에 열어야 하는 gRPC 포트입니다.

라이센스 파일

Teleport Enterprise를 배포하는 경우, 라이센스 파일을 다운로드하여 Teleport Auth Service 인스턴스에서 사용할 수 있게 해야 합니다.

Teleport Auth 서비스는 Teleport Enterprise 계정을 인증하기 위해 라이센스 파일을 읽습니다.

라이센스 파일을 얻으려면 Teleport 계정 대시보드로 이동하여 로그인하십시오. teleport.sh에서 시작하여 Teleport 계정 이름(예: my-company)을 입력합니다. 로그인 후 "GENERATE LICENSE KEY" 버튼이 표시되며, 이를 클릭하면 새 라이센스 파일이 생성되고 다운로드할 수 있습니다.

라이센스 파일은 각 Teleport Auth Service 인스턴스에서 /var/lib/teleport/license.pem 에 있어야 합니다.

구성

구성 파일을 생성하고 각 인증 서비스 인스턴스에 /etc/teleport.yaml 에 제공하십시오. 고가용성 Teleport 배포를 위한 필수 구성 필드를 아래에서 설명하겠습니다. 이는 최소 요구 사항이며, 고가용성 배포를 계획할 때는 환경에 맞는 더 구체적인 배포 가이드를 따르는 것이 좋습니다.

storage

작성할 첫 번째 구성 섹션은 Auth Service의 클러스터 상태 백엔드 및 세션 녹화 백엔드를 구성하는 storage 섹션입니다:

version: v3
teleport:
  storage:
    # ...

storage 섹션에서 설정해야 하는 구성 필드는 백엔드 참조를 참조하십시오.

auth_serviceproxy_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.enabledfalse 로 설정하여 프록시 서비스를 비활성화하였습니다.

ssh_service

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

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

다음 단계

계획 개선

고가용성 Teleport 배포에 대한 일반 원칙을 알게 되었으니, 선호하는 클라우드에서 Kubernetes 또는 가상 머신 클러스터에 자체 배포를 설계하는 방법에 대해 읽어보십시오:

높은 성능 보장

귀하는 또한 Teleport 배포가 예상대로 성능을 발휘하는 방법에 익숙해져야 합니다:

Teleport 서비스 배포

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

시작하려면 다음에 대해 읽어보십시오:

Teleport 원문 보기