이 가이드는 Teleport Community Edition, Teleport Enterprise (Self-Hosted) 및 Teleport Enterprise (Cloud)에서 다른 Teleport 플랜으로 마이그레이션하는 방법을 설명합니다.

우리는 Teleport 데모 클러스터를 Teleport Community Edition으로 사용해 보고, Teleport를 조직에 배포하기 위해 Teleport Enterprise (Cloud)로 마이그레이션하고, Teleport Enterprise (Cloud)에서 처리할 수 없는 보안 및 컴플라이언스 요구 사항이 있는 경우 자체 호스팅 Teleport Enterprise 클러스터를 배포할 것을 권장합니다.

작동 방식

클라우드 호스팅 Teleport Enterprise 플랜에서는 Teleport가 Auth
Service와 Proxy Service를 관리하지만, 동적 리소스와 Teleport 서비스를 직접 마이그레이션해야 합니다. 자체 호스팅 Teleport Enterprise 플랜과 Teleport Community Edition에서는 모든 Teleport 구성 요소를 관리해야 합니다.

Teleport 플랜 간에 마이그레이션하려면:

1. 새 클라우드 호스팅 Teleport Enterprise 계정 또는 Auth Service와 Proxy Service를 포함한 자체 호스팅 Teleport Enterprise 클러스터인 별도의 Teleport 플랜을 설정합니다.
2. 원래 클러스터의 Auth Service 백엔드에서 동적 Teleport 리소스를 가져오고 이를 새 클러스터의 Auth Service 백엔드에 적용합니다.
3. Teleport Agents와 플러그인을 재구성하여 새로운 Teleport 클러스터에 연결합니다.
4. 마이그레이션이 성공했는지 확인합니다.

Teleport Community Edition에는 사용자가 Teleport를 시험해 볼 수 있도록 하는 소규모 Teleport 기능 세트가 포함되어 있습니다. 이 가이드는 Teleport Enterprise에서 Teleport Community Edition으로 마이그레이션하지 않는다고 가정합니다.

전제 조건

• 기존 Teleport 클러스터.
• tsh 및 tctl 클라이언트 도구. 이 가이드는 동적 리소스를 관리하는 데 tctl 을 사용한다고 가정하지만, Teleport
  Terraform provider 및 Kubernetes
  operator를 사용하는 것이 가능하며, Teleport API를 사용하여 Teleport Auth Service 백엔드를 관리하는 사용자 정의 스크립트도 가능합니다.
• Teleport Enterprise (Cloud)로 마이그레이션하는 경우, 신뢰하는 클러스터가 등록된 계정이 없어야 합니다. 신뢰하는 클러스터는 클라우드 호스팅 Teleport Enterprise 계정에서 지원되지 않습니다. 신뢰하는 클러스터 리소스를 마이그레이션할 수 없습니다.

1/4단계. 새 Teleport 플랜 설정

1. 새 Teleport Enterprise 계정에 사용할 teleport.sh 하위 도메인을 결정합니다.

   Teleport Enterprise (Cloud)로 마이그레이션하는 경우, 자체 호스팅 Teleport Enterprise 클러스터의 라이선스 대시보드가 이미 원하는 하위 도메인을 사용하고 있는 경우, 도메인을 재사용하기 위해 Teleport 지원팀에 문의할 수 있습니다.

2. 새 Teleport Enterprise 계정을 설정하기 위해 연락하십시오.

3. 자체 호스팅 Teleport Enterprise 계정으로 마이그레이션하는 경우, 계정 관리 팀의 도움을 받아 배포를 계획하고 실행합니다. 이를 지원하려면 Self-Hosting
   Teleport 문서를 읽어보십시오.

4. 새 Teleport Enterprise 계정 버전보다 같은 주요 버전이거나 단지 한 주요 버전 낮은 버전의 Teleport Enterprise 에이전트를 실행하고 있는지 확인하십시오. Teleport Enterprise 에이전트의 버전을 확인하려면 tctl 명령을 사용하여 연결된 에이전트의 목록과 그 버전을 나열할 수 있습니다:

   이전 버전 확인
   tctl inventory ls --older-than=<version>
   최신 버전 확인
   tctl inventory ls --newer-than=<version>

5. Teleport Enterprise (Self-Hosted) 고객이 에이전트의 건강한 집합을 유지하기 위해 자동 업데이트를 설정할 것을 권장하며, 이는 Teleport Enterprise (Cloud)에서 필수 요구 사항입니다. 마이그레이션에 이 내용을 포함할 수 있는 방법은 Set up Automatic Agent Updates를 참조하십시오.

새 Teleport Enterprise 클러스터와 원래 Teleport Enterprise 클러스터 모두에 대한 연결을 검증하십시오. 두 Teleport 클러스터에 연결하고 현재 자격 증명을 사용하여 tctl 명령을 실행할 수 있어야 합니다.

1. 원래 Teleport 클러스터에 로그인하십시오:

   Single Sign-On으로 로그인하려면 --user 대신 --auth 플래그를 사용하십시오.
   tsh login --proxy=enterprise.example.com --user=myuser
   tctl status

2. 새 Teleport Enterprise 클러스터에 로그인하십시오:

   Single Sign-On으로 로그인하려면 --user 대신 --auth 플래그를 사용하십시오.
   tsh login --proxy=example.teleport.sh --user=myuser
   tctl status

3. 새로운 클러스터의 성능에 영향을 미치는 모든 문제를 최신 상태로 유지하기 위해 Teleport Enterprise 상태
   웹사이트를 구독하십시오.

2/4단계. Teleport 리소스 마이그레이션

원래의 Teleport 클러스터와 새로운 Teleport 클러스터가 모두 작동 중임을 확인한 후, 동적 Teleport 리소스를 한 클러스터에서 다른 클러스터로 마이그레이션할 수 있습니다.

역할 및 로컬 사용자와 같은 동적 Teleport 리소스는 Teleport Auth 서비스 백엔드에 저장됩니다. 원래의 Teleport 클러스터가 새로운 클러스터와는 별도의 Auth 서비스 백엔드를 사용하므로, 먼저 첫 번째 백엔드에서 리소스를 검색한 후 두 번째 백엔드에 다시 적용해야 합니다.

동적 리소스 목록을 리뷰하여 다른 리소스가 마이그레이션할 필요가 있는지 확인하십시오. 일반적인 동적 리소스에는 다음이 포함됩니다:

• windows_desktop
• apps
• dbs
• login_rule

이를 달성하기 위해:

1. 원래 Teleport 클러스터에 로그인하고 위에서 언급한 동적 리소스 구성을 tctl 관리 도구를 사용하여 내보내십시오. 아래에 예시가 나와 있습니다:

   --user 대신 --auth 플래그를 사용하여 Single Sign-On으로 로그인합니다.
   tsh login --proxy=teleport.example.com --user=admin@example.com
   tctl get roles > roles.yaml
   tctl get users > users.yaml

2. 위의 리소스 구성 파일을 확보한 후, 관리자 사용자로 새로운 Teleport Enterprise 계정에 로그인하고 내보낸 파일에서 리소스를 생성합니다:

   --user 대신 --auth 플래그를 사용하여 Single Sign-On으로 로그인합니다.
   tsh login --proxy=example.teleport.sh --user=admin@example.com
   tctl create -f roles.yaml
   tctl create -f user.yaml

SSO 인증 커넥터의 경우, 대부분의 SSO 통합은 단일 구성된 엔드포인트에서만 작동합니다. 새 Teleport Enterprise 엔드포인트에 대해 별도의 SSO 커넥터를 Identity Provider에 생성하고, 새 Teleport Enterprise 테넌트에서 새로운 인증 커넥터를 구성하는 것이 좋습니다.

3/4단계. Teleport 서비스 및 플러그인 마이그레이션

Teleport 에이전트, 머신 ID 봇 및 플러그인과 같은 서비스를 마이그레이션하려면, 먼저 Teleport로 관리하는 다양한 서비스를 목록화해야 합니다. 마이그레이션을 고려해야 할 다음 리소스가 있습니다:

• Teleport 에이전트
• 머신 ID 봇
• 접근 요청 플러그인
• Teleport 이벤트 핸들러

서비스를 마이그레이션하기 전, 새로운 Teleport Enterprise 계정에 로그인했는지 확인하십시오.

Teleport 서비스를 한 번에 또는 점진적으로 마이그레이션할 수 있으며, 이는 비즈니스 요구 사항에 따라 다릅니다. Teleport를 대규모로 운영하는 경우, 일반적으로 구성 관리 도구를 사용하여 에이전트 구성을 마이그레이션하는 작업을 자동화하고 간소화하는 것이 좋습니다.

Teleport 에이전트 마이그레이션

Teleport 에이전트를 마이그레이션하려면:

1. 각 에이전트 및 머신 ID 봇에 대해 유효한 조인 토큰을 얻으십시오. 위임된 조인 방법 사용을 권장합니다.

2. 에페메랄 토큰을 사용하는 경우, Teleport 서비스에 맞는 적절한 토큰 유형을 지정해야 합니다. 토큰 유형에는 node , app , kube , db , windowsdesktop 등이 있으며, 이는 Teleport 클러스터에 조인하려는 서비스에 따라 다릅니다.

3. 다음 예시에서는 TTL이 15분인 새로운 토큰이 생성됩니다:

   tctl tokens add --type node,app,db --ttl 15m

   이 명령어에서, 우리는 토큰에 node , app 및 db 유형을 할당하였으며, 이는 이 토큰이 Teleport의 ssh_service , db_service 및 app_service 를 실행 중인 에이전트가 조인하는 것을 허용함을 의미합니다.

   나중에 이 가이드에서 사용할 수 있도록 토큰을 복사하십시오.

4. 각 에이전트에서 Teleport 서비스를 중지합니다(해당하는 경우).

5. Linux에 설치된 Teleport 리포지토리를 사용하는 경우, Teleport Enterprise(Cloud)용으로 stable/cloud 의 리포지토리 채널을 업데이트하십시오. 자가 호스팅 Teleport Enterprise인 경우 주요 버전 stable/v17 또는 자동 업그레이드를 사용하는 경우 stable/rolling 채널이 모든 릴리스 버전을 포함합니다.

6. Teleport Community Edition을 사용하는 경우, Teleport 제거하고 teleport 이진 파일의 엔터프라이즈 에디션을 설치하십시오. 이진 파일이 올바른지 확인하려면 teleport version 명령을 실행하십시오. 출력에 Teleport Enterprise 라는 단어가 포함되어야 합니다. Teleport Enterprise(Cloud) 또는 Teleport Enterprise(Self-Hosted)에 연결하려면 엔터프라이즈 에디션의 teleport 이진 파일을 사용해야 합니다.

7. 각 에이전트 구성 파일의 proxy_server 또는 auth_servers 필드를 새 Teleport Enterprise 클러스터의 주소를 가리키도록 업데이트합니다. 기본적으로 Linux 서버에서는 구성 파일이 /etc/teleport.yaml 디렉토리에 있습니다:

   version: v3
   teleport:
     proxy_server: example.teleport.sh:443
   

   에이전트 구성에 teleport.proxy_server 필드가 포함되지 않고 대신 teleport.auth_server 또는 teleport.auth_servers 필드가 있는 경우, 구성을 version: v3 로 마이그레이션하고 teleport.proxy_server 를 사용하는 것이 좋습니다.

   teleport.proxy_server 필드를 사용하면, 에이전트는 여러 모드가 아닌 단일 모드를 사용하여 Teleport 클러스터에 연결을 시도하여, 시간도 덜 걸리고 문제 해결을 위한 기능도 줄일 수 있습니다.

8. 새로 생성된 토큰으로 auth_token 또는 join_params.token_name 필드를 업데이트합니다.

   teleport:
     join_params:
       method: token
       token_name: new-token-goes-here
   

9. Linux 서버에서 로컬 에이전트 캐시를 삭제하고 각 에이전트에서 Teleport 프로세스를 재시작하여 에이전트가 새 Teleport Enterprise 클러스터에 재조인하도록 강제합니다. 기본적으로 데이터는 /var/lib/teleport 디렉토리에 위치합니다:

   rm -rf /var/lib/teleport

10. teleport-kube-agent Helm 차트를 사용하는 경우, 기존 상태를 삭제하고 Kubernetes 파드를 재활용하여 Kubernetes 에이전트를 새 클러스터에 재조인하도록 합니다. 이렇게 하면 에이전트가 새 Teleport Enterprise 클러스터에 다시 등록되고 새로운 클러스터의 인증 기관에 의해 서명된 새로운 인증서를 얻습니다.

릴리스 이름 가져오기
helm -n <namespace> ls
상태 비밀 삭제
kubectl -n <namespace> delete secret <release-name>-0-state

새 Teleport Kubernetes 에이전트에 대한 설정은 enterprise 값이 true로 설정되어야 합니다.

머신 ID 봇 마이그레이션

일반적으로, 머신 ID 봇을 마이그레이션하기 위해 다음 단계를 따를 수 있습니다:

1. 새로운 조인 토큰을 확보합니다.
2. tbot 구성 파일에서 proxy_server 구성 필드를 새 Teleport 클러스터 주소와 포트 443 를 가리키도록 수정합니다.
3. tbot 을 재시작합니다.

인프라에서 머신 ID 봇을 재시작하고 구성하는 방법을 배우려면, 머신 ID 봇 배포에 대한 전체 문서를 읽어보세요.

액세스 요청 플러그인 및 이벤트 핸들러

일반적으로, Teleport 플러그인을 마이그레이션하기 위해 다음 단계를 따를 수 있습니다:

1. 머신 ID를 사용하여 플러그인에 대한 자격 증명을 생성하는 경우, 머신 ID 봇을 새 Teleport 클러스터에 연결하도록 재구성하고 봇을 재시작합니다.

   그렇지 않은 경우, tctl 을 사용하여 새 Teleport 클러스터에 연결하고 수동으로 신원 파일을 생성한 다음 이를 플러그인에 사용할 수 있도록 합니다.

2. 플러그인을 재구성하려면 플러그인 구성 파일의 teleport.address 필드를 새 Teleport 클러스터의 주소와 포트 443 을 가리키도록 수정합니다.

3. 플러그인을 재시작합니다.

인프라에서 실행되는 특정 플러그인에 대한 전체 문서를 읽으려면 다음을 참조하세요:

• 액세스 요청 플러그인
• Teleport 이벤트 핸들러

4/4단계. 최종 사용자 액세스 및 성능 확인

동적 리소스를 마이그레이션하고 서비스가 새 Teleport 클러스터에 연결되도록 재구성한 후, 설정이 완료되었는지 확인합니다.

1. 모든 예상 리소스가 Teleport 클러스터에 존재하는지 확인하고, 상태와 연결성을 검증하여 올바르게 등록되고 연결 가능함을 확인합니다. 웹 UI를 통해 확인하거나 tctl 을 사용하여 모든 리소스의 목록을 얻고 등록 상태를 확인할 수 있습니다.

   예를 들어, Teleport 클러스터에 등록된 모든 노드를 나열하려면 아래 명령어를 실행할 수 있습니다:

   tctl nodes ls

   마찬가지로, 등록된 모든 기타 리소스를 나열하려면 아래 명령어를 실행할 수 있습니다:

   등록된 모든 Kubernetes 클러스터 나열:

   tctl kube ls

   등록된 모든 데이터베이스 나열:

   tctl db ls

   등록된 모든 애플리케이션 나열:

   tctl apps ls

   등록된 모든 Windows 데스크탑 나열:

   tctl desktop ls

2. 최종 사용자가 인프라에 대해 예상된 SSO 액세스를 가지고 있는지 확인합니다.

3. 새 Teleport Enterprise 클러스터가 사용할 수 없게 되는 경우 인프라에 접근할 수 있도록 비상 절차를 수립합니다.

   예를 들어, 우리의 모범 사례를 따라 SSH를 적절히 사용하는 방법에 따라 제한된 키로 OpenSSH를 실행할 수 있습니다.

   시스템 부팅 시 OpenSSH를 5분 동안 시작한 다음 종료하도록 systemd를 구성하는 것이 좋습니다. 마스터 키는 안전한 금고에 저장해야 합니다. 유리창을 깨려면 마스터 키를 확보하고 서버를 재부팅한 후 5분 이내에 OpenSSH 클라이언트를 사용하여 연결합니다.

추가 읽기

클라우드 호스팅 Teleport Enterprise 사용에 대한 자세한 정보는 클라우드 호스팅 Teleport Enterprise 계정에 가입하기 문서를 참조하십시오.

셀프 호스팅 Teleport Enterprise에 대한 문서를 읽어보세요.