InfoGrab Docs

Amazon EKS Teleport 클러스터에서 재해 복구 관리

요약

클라우드 제공자 리전에서 장애가 발생하는 경우 Teleport 클러스터를 정상 상태로 복구할 수 있어야 합니다. 이 가이드는 자체 호스팅 Teleport 클러스터가 Amazon Elastic Kubernetes Service에서 실행되고 teleport-cluster Helm 차트를 사용한다고 가정합니다.

클라우드 제공자 리전에서 장애가 발생하는 경우 Teleport 클러스터를 정상 상태로 복구할 수 있어야 합니다. 이 가이드에서는 자체 호스팅 Teleport 클러스터에 대한 재해 복구 접근 방식의 개요를 제공합니다.

이 가이드는 자체 호스팅 Teleport 클러스터가 Amazon Elastic Kubernetes Service에서 실행되고 teleport-cluster Helm 차트를 사용한다고 가정합니다. teleport-cluster Helm 차트는 Kubernetes에서 Teleport 클러스터를 빠르게 자체 호스팅하기 위해 권장되는 접근 방식이며, 차트 시작 방법은 Kubernetes에 Teleport 배포에서 읽을 수 있습니다.

작동 방식#

이 가이드에서 설명하는 접근 방식에서 AWS는 Teleport Auth Service 백엔드를 보조 리전에 백업합니다. 기본 리전이 장애로 인해 사용할 수 없게 되면 관리자는 보조 리전에 클러스터를 재배포하여 해당 리전의 새 백엔드에 연결하도록 Teleport Auth Service를 구성합니다.

Teleport 인증 기관은 이미 새 리전에 백업되어 있으므로 사용할 수 없는 리전 외부에서 실행되는 Teleport 에이전트와 봇은 클러스터에 재연결할 필요가 없습니다. 이 재해 복구 시나리오에서 복구 시간 목표는 새 리전에서 Auth Service와 Proxy Service를 재배포하는 데 걸리는 시간과 Teleport Proxy Service DNS 레코드의 TTL(Time to Live)에 따라 달라집니다.

사전 요구사항#

  • 자체 호스팅 Teleport 클러스터가 teleport-cluster Helm 차트를 사용하여 실행되었습니다. 자체 호스팅 Teleport 클러스터의 고수준 아키텍처 개요는 고가용성 Teleport 클러스터 배포를 읽어보는 것을 권장합니다.
  • 클러스터 상태 백엔드 및 감사 이벤트 백엔드에는 Amazon DynamoDB를, 세션 녹화 백엔드에는 Amazon S3를 사용하고 있습니다. Teleport 백엔드 선택에 대한 정보는 스토리지 백엔드를 참조하세요.

위험

이 가이드는 리전 장애에 대한 런북으로 의도되지 않았습니다.

런북 및 자동화를 포함한 재해 복구 계획 준비에 도움이 되도록 이 가이드를 읽으세요. 문제를 방지하기 위해 계획을 정기적으로 테스트할 것을 강력히 권장합니다.

1단계/4. Auth Service 백엔드 백업#

EKS의 Teleport 클러스터에 대한 재해 복구 절차를 설정하는 첫 번째 단계는 Teleport Auth Service 백엔드를 보조 리전에 백업하는 것입니다. 기본 리전을 사용할 수 없게 되면 보조 리전의 백엔드 복제본이 보조 리전에 재배포한 새 클러스터가 연결할 준비가 됩니다.

리전 장애 중 Teleport 클러스터의 복구 지점 목표는 Auth Service 백엔드를 얼마나 자주 백업하는지에 따라 달라집니다. 백업이 빈번할수록 재해 복구 시 클러스터를 복구할 때 잃는 백엔드 변경 사항이 줄어듭니다.

클러스터 상태 백엔드#

클러스터 상태 백엔드의 백업을 통해 Teleport Auth Service는 기존 인증 기관을 사용하여 클러스터 구성 요소에 대한 인증서에 서명할 수 있습니다. 새 백엔드로 Teleport 클러스터를 복원하고 백업이 없는 경우 Teleport로 보호되는 자체 호스팅 데이터베이스와 같은 클러스터 구성 요소가 새 CA를 신뢰하도록 구성해야 합니다.

백업 절차를 계획하려면 Amazon DynamoDB 문서를 읽어보세요.

AWS Key Management Service 사용자

클러스터의 Teleport Auth Service가 인증 기관 개인 키에 AWS Key Management Service를 사용하는 경우, teleport-cluster Helm 차트를 재설치하기 전에 키를 새 AWS 리전에 복제해야 합니다. 여러 리전에서 KMS 키 사용에 대한 정보는 AWS 문서를 참조하세요.

KMS 지원은 auth.teleportConfig values 필드(차트 참조)를 사용하는 teleport-cluster Helm 차트에서만 가능하며, 대부분의 teleport-cluster 사용자에게는 권장되지 않습니다.

감사 이벤트 백엔드#

클러스터 상태 백엔드 외에도 감사 이벤트에 대한 접근을 유지하기 위해 감사 이벤트 백엔드도 보조 리전에 백업해야 합니다. 클러스터 상태 백엔드와 마찬가지로 백업 절차를 계획하려면 Amazon DynamoDB 문서를 읽어보세요.

세션 녹화 백엔드#

리전 전체 장애 시 세션 녹화에 대한 접근을 유지하려면 세션 녹화를 보조 리전에 백업해야 합니다. 새 리전에 Teleport Auth Service를 재배포하면 새 리전의 S3 버킷에 연결하도록 구성할 수 있습니다.

S3 복제 규칙을 사용하여 기본 리전에서 백업 리전으로 지속적인 백업을 생성할 수 있습니다. 세션 녹화 백엔드에 대한 다중 리전 S3 버킷 복제를 계획하려면 다중 리전 블루프린트 가이드를 따르세요.

2단계/4. 기존 클러스터 중지#

존 또는 리전 장애를 감지하면 기존 Teleport 클러스터를 깔끔하게 중지하는 것이 중요합니다. 클라우드 제공자 수준의 장애는 Teleport 클러스터의 예상 기능을 방해하지만, 클러스터의 일부 작업은 성공적으로 계속될 수 있습니다. 장애가 종료된 후 기능이 유지되거나 다시 온라인 상태가 된 서비스는 클러스터가 예상치 못한 방식으로 동작할 수 있습니다.

예를 들어 Teleport 에이전트는 장애로 인해 사용할 수 없게 된 후에도 Teleport 클러스터에 연결된 상태를 유지할 수 있습니다. 에이전트가 Proxy Service를 통해 수명이 긴 gRPC 연결을 설정하고 대상 Proxy Service 인스턴스가 응답하지 않게 된 경우에도 이를 유지하기 때문입니다. Proxy Service를 중지하고 재시작하여 에이전트와 Proxy Service 간의 연결을 강제로 닫을 수 있습니다.

가능한 경우 클러스터의 Teleport Auth Service 및 Proxy Service 파드를 중지합니다. 이 명령은 릴리즈 이름이 teleport-cluster이고 teleport 네임스페이스에서 실행된다고 가정합니다:

$ helm --namespace teleport uninstall teleport-cluster

전체 리전 장애의 경우 기존 클러스터가 이미 사용할 수 없게 될 수 있습니다.

3단계/4. Auth Service 및 Proxy Service 재실행#

Auth Service 백엔드의 백업이 있으므로 새 리전에 Teleport 클러스터를 안전하게 배포할 수 있습니다.

values 파일 업데이트#

새 리전에 Teleport Auth Service와 Proxy Service를 배포할 때 teleport-cluster Helm 차트의 values 파일에서 다음 필드를 업데이트해야 합니다:

  • aws.region
  • aws.backendTable
  • aws.auditLogTable
  • aws.sessionRecordingBucket

Teleport 클러스터의 서드파티 의존성과 일치하도록 다른 값을 업데이트해야 할 수도 있습니다. 예를 들어 Let's Encrypt 대신 cert-manager를 배포하여 Teleport Proxy Service 인증서를 처리하려는 경우 certManager.issuerName 필드가 Kubernetes 클러스터의 cert-manager Issuer 이름과 일치하도록 설정해야 합니다.

새 AWS 리전에서 관리해야 하는 서드파티 의존성을 확인하려면 AWS, EKS, Helm을 사용하여 HA Teleport 클러스터 실행을 읽어보는 것을 권장합니다.

IAM 구성 업데이트#

Auth Service와 Proxy Service에서 사용하는 역할이 새 리전의 백엔드에 접근할 수 있는 권한을 서비스에 부여하는지 확인해야 합니다. 이러한 역할과 관련된 신뢰 정책이 새 리전의 주체에 접근을 허용하는지 확인하세요.

로드 밸런서에 자격 증명 프로비저닝#

teleport-cluster Helm 차트는 기본적으로 LoadBalancer 유형의 Kubernetes 서비스를 배포합니다. 새 AWS 리전에 Helm 차트를 재설치하면 로드 밸런서가 다시 생성됩니다.

로드 밸런서에 TLS 자격 증명을 프로비저닝하기 위해 AWS Certificate Manager 또는 cert-manager를 사용하는 경우 새 리전에 차트를 설치하기 전에 새 인증서와 개인 키를 생성해야 합니다.

Teleport Proxy Service 로드 밸런서와 함께 ACM과 cert-manager를 사용하도록 EKS 클러스터를 구성하는 지침은 Teleport TLS 인증서 구성을 참조하세요.

Helm 차트 재설치#

  1. 새 값으로 teleport-cluster Helm 차트를 설치합니다:

    $ helm install teleport-cluster teleport/teleport-cluster \
  --version (=teleport.version=) \
  --values teleport-cluster-values.yaml

  2. teleport-cluster 차트를 설치한 후 잠시 기다리고 Auth Service와 Proxy Service 파드가 모두 실행 중인지 확인합니다:

    $ kubectl get pods
NAME                                      READY   STATUS    RESTARTS   AGE
teleport-cluster-auth-000000000-00000     1/1     Running   0          114s
teleport-cluster-proxy-0000000000-00000   1/1     Running   0          114s

  3. 새 클러스터에서 Teleport Auth Service가 실행되면 Teleport Kubernetes 오퍼레이터가 관리할 수 있도록 새 클러스터에 Teleport 동적 리소스를 적용했는지 확인합니다.

    새 클러스터를 실행할 때 쉽게 적용할 수 있도록 Flux CD와 같은 GitOps 도구를 사용하여 Kubernetes 매니페스트 세트로 Teleport 리소스를 관리해야 합니다.

경고

Auth Service와 Proxy Service를 재배포할 때까지 정적 토큰으로 클러스터에 합류한 머신 및 워크로드 아이덴티티 봇은 갱신 기간을 놓치고 Teleport Auth Service가 새 토큰을 발급할 수 있을 때까지 클러스터에서 잠길 수 있습니다. 이 시나리오를 방지하려면 위임 합류 방법을 사용하는 것을 권장합니다.

4단계/4. DNS 레코드 업데이트#

새 AWS 리전에서 Teleport 클러스터를 실행한 후 Route 53 DNS 레코드가 새 클러스터를 가리키는지 확인해야 합니다.

클러스터의 Teleport Proxy Service에 대한 기존 DNS 레코드의 TTL이 낮은지(예: 1분) 확인합니다. 사용자 네트워크의 DNS 리졸버가 DNS 레코드의 TTL을 준수하여 레코드 전파 문제를 방지할 것으로 예상합니다.

안내#

이 가이드에서 설명하는 단계를 중심으로 재해 복구 전략을 계획했다면 다음 관행을 권장합니다.

재해 복구 절차 테스트#

재해 복구 계획을 테스트할 것을 강력히 권장합니다. 한 리전에서 Teleport 클러스터를 중지하고 Auth Service 클러스터 상태 백엔드의 백업을 사용하여 다른 리전에 재배포할 시간을 예약하세요. 클러스터를 재배포한 후 사용자가 Teleport로 보호된 리소스에 계속 연결할 수 있는지 확인합니다.

재해 복구 실패의 일반적인 원인은 다음과 같습니다:

  • 잘못 구성된 IAM 설정: 첫 번째 리전의 Teleport Auth Service는 백엔드에 접근할 수 있지만 두 번째 리전에서는 Auth Service가 불충분한 권한을 가진 역할을 가지고 있는 경우.
  • 잘못 구성된 백엔드 연결: Teleport Auth Service가 새 리전에서 잘못된 클러스터 상태 백엔드 URL로 구성되어 시작할 때 기존 CA를 검색하지 못하고 자체 서명된 인증서로 대신 부트스트랩하는 경우.

복구 시간 목표 단축#

Teleport 재해 복구 계획을 수립할 때 복구 시간 목표를 추정하기 위한 주요 고려 사항은 Teleport Auth Service가 보조 리전에서 온라인 상태가 되는 데 걸리는 시간입니다.

이 가이드에서 설명하는 재해 복구 절차는 최소 한 시간이 걸릴 것으로 예상되지만 정확한 세부 사항은 인프라와 조직에 따라 다릅니다. 정확한 벤치마크를 얻으려면 재해 복구 절차 테스트를 강력히 권장합니다.

재해 복구 절차의 복구 시간 목표를 단축하기 위한 조치를 취할 수 있습니다. 가능성은 다음과 같습니다:

  • Teleport Proxy Service에 대한 DNS 레코드의 TTL을 줄입니다. 클러스터를 새 리전에 재배포하는 데 걸리는 시간보다 길면 클라이언트가 이전 리전의 클러스터에 계속 연결을 시도할 수 있습니다.
  • teleport-cluster Helm 차트를 재설치하기 전에 백업에서 클러스터 상태와 감사 이벤트 백엔드 테이블을 복원하여 Teleport Auth Service가 테이블을 직접 초기화할 필요가 없도록 합니다.
  • 리전 장애가 발생하기 전에 보조 리전에서 Auth Service, Proxy Service, 백엔드 서비스를 실행합니다. 여러 리전에 걸쳐 중복 Teleport 클러스터 배포가 있는 경우 클러스터가 새 리전에 배포될 때까지 기다리는 동안 가용성을 잃을 필요가 없습니다. 다중 리전 Teleport 배포의 아키텍처는 다중 리전 블루프린트 가이드를 읽어보세요.

변경 동결 적용#

리전 클라우드 제공자 장애 중 이 가이드에서 설명하는 절차에는 영향을 받는 리전에서 Teleport 클러스터를 중지하는 것이 포함됩니다. 클러스터가 다시 온라인 상태가 될 때까지 사용자는 동적 리소스를 업데이트하거나 클러스터 CA를 교체할 수 없습니다. 그러나 일부 경우에는 백업에서 클러스터를 복원하는 동안 사용자가 클러스터 리소스를 업데이트하지 못하도록 변경 동결을 적용해야 할 수 있습니다.

동적 리소스를 편집할 수 있는 권한을 포함하는 Teleport 역할을 잠금으로써 변경 동결을 적용할 수 있습니다. Teleport 역할은 spec.allow.rules 필드를 통해 동적 리소스 수정에 대한 접근을 허용합니다.

다음 jq 명령을 사용하여 백엔드 리소스를 수정할 수 있는 권한을 부여하는 규칙이 하나 이상 있는 모든 역할을 나열할 수 있습니다. 이 예시에서는 사용자가 잠금을 생성, 나열, 읽기, 삭제할 수 있도록 허용하는 locksmith라는 역할이 있다고 가정합니다. 클러스터를 복구한 후 잠금을 제거할 수 있도록 locksmith 사용자를 건너뜁니다:

$ tctl get roles --format json | jq -r '.[] | select(.metadata.name != "locksmith" and .spec.allow.rules) | .metadata.name'
dashboard-admin
dashboard-user
device-admin
device-enroll
group-access

Teleport는 spec.allow.rules 필드를 통해 인증 기관 교체에 대한 접근을 허용합니다 - cert_authority 리소스에서 - 따라서 변경 동결을 적용하기 위해 역할 잠금을 사용하면 재해 복구 절차 중 의도하지 않은 인증 기관 교체도 방지됩니다.

tctl lock 명령을 사용하여 잠금을 생성합니다. 다음 예시는 contractor 역할을 24시간 동안 잠급니다:

$ tctl lock --role=contractor --message="change freeze during disaster recovery" --ttl=24h

Auth Service 파드에서 직접 명령을 실행할 수 있는 권한이 있는 사용자는 tctl을 사용하여 백엔드를 변경할 수 있습니다.

사용자가 클러스터 리소스를 수정하는 것이 안전해지면 tctl rm lock/<lock_id> 명령을 사용하여 각 잠금을 제거합니다. 잠금을 생성할 때 비슷한 --message 플래그 값을 각 잠금에 제공한 경우 단일 명령으로 생성한 모든 잠금을 제거할 수 있습니다. 이 명령은 change freeze 부분 문자열을 포함하는 메시지가 있는 모든 잠금을 제거합니다:

$ tctl get lock --format=json \
  | jq -r '.[] | select(.spec.message and (.spec.message | contains("change freeze"))) | .metadata.name' \
  | xargs -I{} tctl rm lock/{}

추가 읽을거리#

  • Teleport 클러스터 백엔드 백업에 대한 일반 정보는 백업 및 복구 가이드를 읽어보세요.
  • 역할이 클러스터 상태 백엔드를 변경하지 못하도록 방지하는 방법에 대한 자세한 내용은 세션 및 아이덴티티 잠금을 읽어보세요.

Amazon EKS Teleport 클러스터에서 재해 복구 관리

원문 보기
요약

클라우드 제공자 리전에서 장애가 발생하는 경우 Teleport 클러스터를 정상 상태로 복구할 수 있어야 합니다. 이 가이드는 자체 호스팅 Teleport 클러스터가 Amazon Elastic Kubernetes Service에서 실행되고 teleport-cluster Helm 차트를 사용한다고 가정합니다.

클라우드 제공자 리전에서 장애가 발생하는 경우 Teleport 클러스터를 정상 상태로 복구할 수 있어야 합니다. 이 가이드에서는 자체 호스팅 Teleport 클러스터에 대한 재해 복구 접근 방식의 개요를 제공합니다.

이 가이드는 자체 호스팅 Teleport 클러스터가 Amazon Elastic Kubernetes Service에서 실행되고 teleport-cluster Helm 차트를 사용한다고 가정합니다. teleport-cluster Helm 차트는 Kubernetes에서 Teleport 클러스터를 빠르게 자체 호스팅하기 위해 권장되는 접근 방식이며, 차트 시작 방법은 Kubernetes에 Teleport 배포에서 읽을 수 있습니다.

작동 방식#

이 가이드에서 설명하는 접근 방식에서 AWS는 Teleport Auth Service 백엔드를 보조 리전에 백업합니다. 기본 리전이 장애로 인해 사용할 수 없게 되면 관리자는 보조 리전에 클러스터를 재배포하여 해당 리전의 새 백엔드에 연결하도록 Teleport Auth Service를 구성합니다.

Teleport 인증 기관은 이미 새 리전에 백업되어 있으므로 사용할 수 없는 리전 외부에서 실행되는 Teleport 에이전트와 봇은 클러스터에 재연결할 필요가 없습니다. 이 재해 복구 시나리오에서 복구 시간 목표는 새 리전에서 Auth Service와 Proxy Service를 재배포하는 데 걸리는 시간과 Teleport Proxy Service DNS 레코드의 TTL(Time to Live)에 따라 달라집니다.

사전 요구사항#

  • 자체 호스팅 Teleport 클러스터가 teleport-cluster Helm 차트를 사용하여 실행되었습니다. 자체 호스팅 Teleport 클러스터의 고수준 아키텍처 개요는 고가용성 Teleport 클러스터 배포를 읽어보는 것을 권장합니다.
  • 클러스터 상태 백엔드 및 감사 이벤트 백엔드에는 Amazon DynamoDB를, 세션 녹화 백엔드에는 Amazon S3를 사용하고 있습니다. Teleport 백엔드 선택에 대한 정보는 스토리지 백엔드를 참조하세요.

위험

이 가이드는 리전 장애에 대한 런북으로 의도되지 않았습니다.

런북 및 자동화를 포함한 재해 복구 계획 준비에 도움이 되도록 이 가이드를 읽으세요. 문제를 방지하기 위해 계획을 정기적으로 테스트할 것을 강력히 권장합니다.

1단계/4. Auth Service 백엔드 백업#

EKS의 Teleport 클러스터에 대한 재해 복구 절차를 설정하는 첫 번째 단계는 Teleport Auth Service 백엔드를 보조 리전에 백업하는 것입니다. 기본 리전을 사용할 수 없게 되면 보조 리전의 백엔드 복제본이 보조 리전에 재배포한 새 클러스터가 연결할 준비가 됩니다.

리전 장애 중 Teleport 클러스터의 복구 지점 목표는 Auth Service 백엔드를 얼마나 자주 백업하는지에 따라 달라집니다. 백업이 빈번할수록 재해 복구 시 클러스터를 복구할 때 잃는 백엔드 변경 사항이 줄어듭니다.

클러스터 상태 백엔드#

클러스터 상태 백엔드의 백업을 통해 Teleport Auth Service는 기존 인증 기관을 사용하여 클러스터 구성 요소에 대한 인증서에 서명할 수 있습니다. 새 백엔드로 Teleport 클러스터를 복원하고 백업이 없는 경우 Teleport로 보호되는 자체 호스팅 데이터베이스와 같은 클러스터 구성 요소가 새 CA를 신뢰하도록 구성해야 합니다.

백업 절차를 계획하려면 Amazon DynamoDB 문서를 읽어보세요.

AWS Key Management Service 사용자

클러스터의 Teleport Auth Service가 인증 기관 개인 키에 AWS Key Management Service를 사용하는 경우, teleport-cluster Helm 차트를 재설치하기 전에 키를 새 AWS 리전에 복제해야 합니다. 여러 리전에서 KMS 키 사용에 대한 정보는 AWS 문서를 참조하세요.

KMS 지원은 auth.teleportConfig values 필드(차트 참조)를 사용하는 teleport-cluster Helm 차트에서만 가능하며, 대부분의 teleport-cluster 사용자에게는 권장되지 않습니다.

감사 이벤트 백엔드#

클러스터 상태 백엔드 외에도 감사 이벤트에 대한 접근을 유지하기 위해 감사 이벤트 백엔드도 보조 리전에 백업해야 합니다. 클러스터 상태 백엔드와 마찬가지로 백업 절차를 계획하려면 Amazon DynamoDB 문서를 읽어보세요.

세션 녹화 백엔드#

리전 전체 장애 시 세션 녹화에 대한 접근을 유지하려면 세션 녹화를 보조 리전에 백업해야 합니다. 새 리전에 Teleport Auth Service를 재배포하면 새 리전의 S3 버킷에 연결하도록 구성할 수 있습니다.

S3 복제 규칙을 사용하여 기본 리전에서 백업 리전으로 지속적인 백업을 생성할 수 있습니다. 세션 녹화 백엔드에 대한 다중 리전 S3 버킷 복제를 계획하려면 다중 리전 블루프린트 가이드를 따르세요.

2단계/4. 기존 클러스터 중지#

존 또는 리전 장애를 감지하면 기존 Teleport 클러스터를 깔끔하게 중지하는 것이 중요합니다. 클라우드 제공자 수준의 장애는 Teleport 클러스터의 예상 기능을 방해하지만, 클러스터의 일부 작업은 성공적으로 계속될 수 있습니다. 장애가 종료된 후 기능이 유지되거나 다시 온라인 상태가 된 서비스는 클러스터가 예상치 못한 방식으로 동작할 수 있습니다.

예를 들어 Teleport 에이전트는 장애로 인해 사용할 수 없게 된 후에도 Teleport 클러스터에 연결된 상태를 유지할 수 있습니다. 에이전트가 Proxy Service를 통해 수명이 긴 gRPC 연결을 설정하고 대상 Proxy Service 인스턴스가 응답하지 않게 된 경우에도 이를 유지하기 때문입니다. Proxy Service를 중지하고 재시작하여 에이전트와 Proxy Service 간의 연결을 강제로 닫을 수 있습니다.

가능한 경우 클러스터의 Teleport Auth Service 및 Proxy Service 파드를 중지합니다. 이 명령은 릴리즈 이름이 teleport-cluster이고 teleport 네임스페이스에서 실행된다고 가정합니다:

$ helm --namespace teleport uninstall teleport-cluster

전체 리전 장애의 경우 기존 클러스터가 이미 사용할 수 없게 될 수 있습니다.

3단계/4. Auth Service 및 Proxy Service 재실행#

Auth Service 백엔드의 백업이 있으므로 새 리전에 Teleport 클러스터를 안전하게 배포할 수 있습니다.

values 파일 업데이트#

새 리전에 Teleport Auth Service와 Proxy Service를 배포할 때 teleport-cluster Helm 차트의 values 파일에서 다음 필드를 업데이트해야 합니다:

  • aws.region
  • aws.backendTable
  • aws.auditLogTable
  • aws.sessionRecordingBucket

Teleport 클러스터의 서드파티 의존성과 일치하도록 다른 값을 업데이트해야 할 수도 있습니다. 예를 들어 Let's Encrypt 대신 cert-manager를 배포하여 Teleport Proxy Service 인증서를 처리하려는 경우 certManager.issuerName 필드가 Kubernetes 클러스터의 cert-manager Issuer 이름과 일치하도록 설정해야 합니다.

새 AWS 리전에서 관리해야 하는 서드파티 의존성을 확인하려면 AWS, EKS, Helm을 사용하여 HA Teleport 클러스터 실행을 읽어보는 것을 권장합니다.

IAM 구성 업데이트#

Auth Service와 Proxy Service에서 사용하는 역할이 새 리전의 백엔드에 접근할 수 있는 권한을 서비스에 부여하는지 확인해야 합니다. 이러한 역할과 관련된 신뢰 정책이 새 리전의 주체에 접근을 허용하는지 확인하세요.

로드 밸런서에 자격 증명 프로비저닝#

teleport-cluster Helm 차트는 기본적으로 LoadBalancer 유형의 Kubernetes 서비스를 배포합니다. 새 AWS 리전에 Helm 차트를 재설치하면 로드 밸런서가 다시 생성됩니다.

로드 밸런서에 TLS 자격 증명을 프로비저닝하기 위해 AWS Certificate Manager 또는 cert-manager를 사용하는 경우 새 리전에 차트를 설치하기 전에 새 인증서와 개인 키를 생성해야 합니다.

Teleport Proxy Service 로드 밸런서와 함께 ACM과 cert-manager를 사용하도록 EKS 클러스터를 구성하는 지침은 Teleport TLS 인증서 구성을 참조하세요.

Helm 차트 재설치#

  1. 새 값으로 teleport-cluster Helm 차트를 설치합니다:

    $ helm install teleport-cluster teleport/teleport-cluster \
  --version (=teleport.version=) \
  --values teleport-cluster-values.yaml

  2. teleport-cluster 차트를 설치한 후 잠시 기다리고 Auth Service와 Proxy Service 파드가 모두 실행 중인지 확인합니다:

    $ kubectl get pods
NAME                                      READY   STATUS    RESTARTS   AGE
teleport-cluster-auth-000000000-00000     1/1     Running   0          114s
teleport-cluster-proxy-0000000000-00000   1/1     Running   0          114s

  3. 새 클러스터에서 Teleport Auth Service가 실행되면 Teleport Kubernetes 오퍼레이터가 관리할 수 있도록 새 클러스터에 Teleport 동적 리소스를 적용했는지 확인합니다.

    새 클러스터를 실행할 때 쉽게 적용할 수 있도록 Flux CD와 같은 GitOps 도구를 사용하여 Kubernetes 매니페스트 세트로 Teleport 리소스를 관리해야 합니다.

경고

Auth Service와 Proxy Service를 재배포할 때까지 정적 토큰으로 클러스터에 합류한 머신 및 워크로드 아이덴티티 봇은 갱신 기간을 놓치고 Teleport Auth Service가 새 토큰을 발급할 수 있을 때까지 클러스터에서 잠길 수 있습니다. 이 시나리오를 방지하려면 위임 합류 방법을 사용하는 것을 권장합니다.

4단계/4. DNS 레코드 업데이트#

새 AWS 리전에서 Teleport 클러스터를 실행한 후 Route 53 DNS 레코드가 새 클러스터를 가리키는지 확인해야 합니다.

클러스터의 Teleport Proxy Service에 대한 기존 DNS 레코드의 TTL이 낮은지(예: 1분) 확인합니다. 사용자 네트워크의 DNS 리졸버가 DNS 레코드의 TTL을 준수하여 레코드 전파 문제를 방지할 것으로 예상합니다.

안내#

이 가이드에서 설명하는 단계를 중심으로 재해 복구 전략을 계획했다면 다음 관행을 권장합니다.

재해 복구 절차 테스트#

재해 복구 계획을 테스트할 것을 강력히 권장합니다. 한 리전에서 Teleport 클러스터를 중지하고 Auth Service 클러스터 상태 백엔드의 백업을 사용하여 다른 리전에 재배포할 시간을 예약하세요. 클러스터를 재배포한 후 사용자가 Teleport로 보호된 리소스에 계속 연결할 수 있는지 확인합니다.

재해 복구 실패의 일반적인 원인은 다음과 같습니다:

  • 잘못 구성된 IAM 설정: 첫 번째 리전의 Teleport Auth Service는 백엔드에 접근할 수 있지만 두 번째 리전에서는 Auth Service가 불충분한 권한을 가진 역할을 가지고 있는 경우.
  • 잘못 구성된 백엔드 연결: Teleport Auth Service가 새 리전에서 잘못된 클러스터 상태 백엔드 URL로 구성되어 시작할 때 기존 CA를 검색하지 못하고 자체 서명된 인증서로 대신 부트스트랩하는 경우.

복구 시간 목표 단축#

Teleport 재해 복구 계획을 수립할 때 복구 시간 목표를 추정하기 위한 주요 고려 사항은 Teleport Auth Service가 보조 리전에서 온라인 상태가 되는 데 걸리는 시간입니다.

이 가이드에서 설명하는 재해 복구 절차는 최소 한 시간이 걸릴 것으로 예상되지만 정확한 세부 사항은 인프라와 조직에 따라 다릅니다. 정확한 벤치마크를 얻으려면 재해 복구 절차 테스트를 강력히 권장합니다.

재해 복구 절차의 복구 시간 목표를 단축하기 위한 조치를 취할 수 있습니다. 가능성은 다음과 같습니다:

  • Teleport Proxy Service에 대한 DNS 레코드의 TTL을 줄입니다. 클러스터를 새 리전에 재배포하는 데 걸리는 시간보다 길면 클라이언트가 이전 리전의 클러스터에 계속 연결을 시도할 수 있습니다.
  • teleport-cluster Helm 차트를 재설치하기 전에 백업에서 클러스터 상태와 감사 이벤트 백엔드 테이블을 복원하여 Teleport Auth Service가 테이블을 직접 초기화할 필요가 없도록 합니다.
  • 리전 장애가 발생하기 전에 보조 리전에서 Auth Service, Proxy Service, 백엔드 서비스를 실행합니다. 여러 리전에 걸쳐 중복 Teleport 클러스터 배포가 있는 경우 클러스터가 새 리전에 배포될 때까지 기다리는 동안 가용성을 잃을 필요가 없습니다. 다중 리전 Teleport 배포의 아키텍처는 다중 리전 블루프린트 가이드를 읽어보세요.

변경 동결 적용#

리전 클라우드 제공자 장애 중 이 가이드에서 설명하는 절차에는 영향을 받는 리전에서 Teleport 클러스터를 중지하는 것이 포함됩니다. 클러스터가 다시 온라인 상태가 될 때까지 사용자는 동적 리소스를 업데이트하거나 클러스터 CA를 교체할 수 없습니다. 그러나 일부 경우에는 백업에서 클러스터를 복원하는 동안 사용자가 클러스터 리소스를 업데이트하지 못하도록 변경 동결을 적용해야 할 수 있습니다.

동적 리소스를 편집할 수 있는 권한을 포함하는 Teleport 역할을 잠금으로써 변경 동결을 적용할 수 있습니다. Teleport 역할은 spec.allow.rules 필드를 통해 동적 리소스 수정에 대한 접근을 허용합니다.

다음 jq 명령을 사용하여 백엔드 리소스를 수정할 수 있는 권한을 부여하는 규칙이 하나 이상 있는 모든 역할을 나열할 수 있습니다. 이 예시에서는 사용자가 잠금을 생성, 나열, 읽기, 삭제할 수 있도록 허용하는 locksmith라는 역할이 있다고 가정합니다. 클러스터를 복구한 후 잠금을 제거할 수 있도록 locksmith 사용자를 건너뜁니다:

$ tctl get roles --format json | jq -r '.[] | select(.metadata.name != "locksmith" and .spec.allow.rules) | .metadata.name'
dashboard-admin
dashboard-user
device-admin
device-enroll
group-access

Teleport는 spec.allow.rules 필드를 통해 인증 기관 교체에 대한 접근을 허용합니다 - cert_authority 리소스에서 - 따라서 변경 동결을 적용하기 위해 역할 잠금을 사용하면 재해 복구 절차 중 의도하지 않은 인증 기관 교체도 방지됩니다.

tctl lock 명령을 사용하여 잠금을 생성합니다. 다음 예시는 contractor 역할을 24시간 동안 잠급니다:

$ tctl lock --role=contractor --message="change freeze during disaster recovery" --ttl=24h

Auth Service 파드에서 직접 명령을 실행할 수 있는 권한이 있는 사용자는 tctl을 사용하여 백엔드를 변경할 수 있습니다.

사용자가 클러스터 리소스를 수정하는 것이 안전해지면 tctl rm lock/<lock_id> 명령을 사용하여 각 잠금을 제거합니다. 잠금을 생성할 때 비슷한 --message 플래그 값을 각 잠금에 제공한 경우 단일 명령으로 생성한 모든 잠금을 제거할 수 있습니다. 이 명령은 change freeze 부분 문자열을 포함하는 메시지가 있는 모든 잠금을 제거합니다:

$ tctl get lock --format=json \
  | jq -r '.[] | select(.spec.message and (.spec.message | contains("change freeze"))) | .metadata.name' \
  | xargs -I{} tctl rm lock/{}

추가 읽을거리#

  • Teleport 클러스터 백엔드 백업에 대한 일반 정보는 백업 및 복구 가이드를 읽어보세요.
  • 역할이 클러스터 상태 백엔드를 변경하지 못하도록 방지하는 방법에 대한 자세한 내용은 세션 및 아이덴티티 잠금을 읽어보세요.