이 배포 아키텍처에는 두 가지 중요한 설계 결정이 포함되어 있습니다:

• Amazon Route 53 지연 시간 기반 라우팅을 사용하여 사용자와 에이전트가 가장 가까운 프록시에 연결하도록 합니다.
• Teleport의 프록시 피어링을 사용하여 Teleport 클러스터의 총 터널 연결 수를 줄입니다.

이 배포 아키텍처는 사용자나 리소스가 단일 리전에 집중되어 있거나, 고객에게 별도의 클러스터를 제공해야 하는 매니지드 서비스 제공업체에게는 권장되지 않습니다.

이 아키텍처는 전 세계에 분산된 리소스와 최소 지연 시간을 유지하면서 단일 진입점을 선호하는 최종 사용자에게 가장 적합합니다.

이 가이드는 인프라가 AWS GovCloud에 호스팅되어 있지 않고 에어갭 AWS 환경(EKS Anywhere)에 있지 않다고 가정합니다. 그런 경우라면 배포 계획 지원을 위해 Teleport 팀에 연락하세요.

주요 배포 구성 요소#

• AWS 에코시스템에 독점적으로 배포
• 단일 리전에 있어야 하는 Auth Service 인스턴스의 고가용성 Auto Scaling 그룹
• 여러 리전에 배포된 Proxy Service 인스턴스의 고가용성 Auto Scaling 그룹
• Amazon Route 53 지연 시간 기반 라우팅
• Teleport 사용에 필요한 포트 수를 줄이기 위한 Teleport TLS 라우팅
• 리소스 연결 수를 줄이기 위한 Teleport 프록시 피어링
• AWS 네트워크 로드 밸런싱
• 클러스터 상태 저장을 위한 Amazon DynamoDB
• 세션 녹화 저장을 위한 AWS S3

이 배포 아키텍처의 장점#

• 여러 리전에서 여러 Teleport 클러스터를 유지하는 복잡성과 비용을 제거합니다.
• 사용자를 리소스에 연결하는 데 가장 낮은 지연 경로를 사용합니다.
• 조직의 요구에 따라 신속하게 확장할 수 있는 고탄력, 중복 HA 아키텍처를 제공합니다.
• 모든 필요한 Teleport 구성 요소를 AWS 에코시스템 내에서 프로비저닝할 수 있습니다.
• Proxy Service 및 Auth Service에 로드 밸런서를 사용하면 Teleport 클러스터 업그레이드 중 가용성이 향상됩니다.

이 배포 아키텍처의 단점#

• Teleport Auth Service 인스턴스가 단일 리전으로 제한될 때 AWS 리전 중단 중 가용성 감소 가능성이 높습니다.
• 단일 리전 Teleport 클러스터보다 기술적으로 배포가 복잡합니다.

AWS 네트워크 로드 밸런서(NLB)#

이 고가용성 배포 아키텍처에는 AWS NLB가 필요합니다. NLB는 사용자 및 서비스로부터 사용 가능한 Teleport Proxy Service 인스턴스로 트래픽을 전달합니다. TLS를 종료해서는 안 되며, 수신하는 TCP 트래픽을 투명하게 전달해야 합니다. 즉, 이는 레이어 4 로드 밸런서여야 하며, 레이어 7(예: HTTP) 로드 밸런서가 아닙니다.

참고

여러 영역에 걸쳐 트래픽을 라우팅하려면 Auth Service 및 Proxy Service NLB 구성에 교차 영역 로드 밸런싱이 필요합니다. 이렇게 하면 로컬화된 AWS 영역 중단에 대한 탄력성이 향상됩니다.

Proxy Service NLB 구성#

로드 밸런서의 다음 포트에서 사용 가능한 Teleport 인스턴스의 해당 포트로 트래픽을 전달하도록 로드 밸런서를 구성합니다.

Auth Service NLB 구성#

로드 밸런서의 다음 포트에서 사용 가능한 Teleport 인스턴스의 해당 포트로 트래픽을 전달하도록 로드 밸런서를 구성합니다.

참고

프록시는 Auth Service NLB에 대한 네트워크 접근이 있어야 합니다. VPC 피어링 또는 Transit Gateway를 사용하여 이를 달성할 수 있습니다.

내부 NLB Auth Service 포트

TLS 자격 증명 프로비저닝#

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

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

Route 53을 사용한 지연 시간 기반 라우팅#

Teleport 리소스의 트래픽이 리소스가 연결하는 VPC의 리전을 기반으로 가장 가깝거나 가장 낮은 지연 경로의 프록시 NLB로 라우팅되도록 하려면 공개 호스팅 영역에서 지연 시간 기반 라우팅을 사용해야 합니다.

이 동작을 구성하려면 Teleport에 연결된 리소스가 포함된 VPC가 있는 각 리전에 대한 CNAME 레코드를 생성합니다. Teleport로 애플리케이션을 등록할 계획이라면 모든 리전에 대한 와일드카드 레코드를 추가하는 것이 좋습니다.

다음 CNAME 레코드 값을 설정해야 합니다:

• Value: example-region-1에 위치한 Teleport 리소스 트래픽을 라우팅해야 하는 NLB의 도메인 이름
• 라우팅 정책: 지연 시간
• 리전: Value에 나열된 NLB로 트래픽을 라우팅할 AWS 리전
• 헬스 체크 ID: 항상 정상 NLB로 트래픽이 라우팅되도록 이를 설정하는 것이 좋습니다

AWS Route53 지연 시간 라우팅을 사용한 호스팅 영역 예시:

Teleport의 루트 레코드#

Teleport 프록시 리전별 DNS 레코드#

필요한 권한

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

Teleport 리소스 에이전트 구성#

지연 시간 기반 라우팅을 용이하게 하려면 리소스 에이전트는 특정 프록시 NLB 주소가 아닌 Route53에 구성된 CNAME으로 proxy_server를 가리키도록 구성해야 합니다.

예를 들어:

version: v3
teleport:
    nodename: ssh-node
    ...
    proxy_server: teleport.example.com:443
    ...
    ssh_service:
        enabled: true
    ...

추가 설정은 구성 참조 페이지를 검토하세요.

프록시 피어링 구성#

이 배포 아키텍처에서 프록시 피어링은 Teleport 클러스터의 리소스에서 프록시로 연결 수를 제한하는 데 사용됩니다.

Auth Service 프록시 피어링 구성#

Teleport Auth Service는 아래 예시와 같이 proxy_peering 터널 전략을 사용하도록 구성해야 합니다:

auth_service:
 ...
 tunnel_strategy:
  type: proxy_peering
  agent_connection_count: 2

추가 설정은 Auth Service 구성 참조 페이지를 참조하세요.

Proxy Service 프록시 피어링 구성#

프록시는 프록시 피어가 서로 연결을 설정하기 위한 피어 주소를 알려야 합니다. Teleport 프록시 인스턴스에 노출된 포트는 프록시 피어링 트래픽을 공개 인터넷을 통해 라우팅하는지 여부에 따라 다릅니다:

공개 프록시 피어링 포트:

VPC 피어링 프록시 피어링 포트:

peer_public_addr을 해당 프록시의 특정 이름으로 설정합니다. 이것이 가장 낮은 지연 시간과 가장 신뢰할 수 있는 연결을 위한 권장 방법입니다.

version: v3
teleport:
...
proxy_service:
  ...
  peer_public_addr: teleport-proxy-eu-west-1-host1.example.com:3021
  ...

참고

Auth Service의 agent_connection_count는 에이전트를 사용할 수 없을 가능성을 줄이기 위해 >=2 값으로 설정해야 합니다.

추가 설정은 Proxy Service 구성 참조 페이지를 참조하세요.