InfoGrab DocsInfoGrab Docs

Teleport 플랜 간 마이그레이션

요약

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

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

Teleport Community Edition으로 Teleport 데모 클러스터를 먼저 시도해 보고, 조직 전반에 Teleport를 배포하기 위해 Teleport Enterprise (Cloud)로 마이그레이션한 다음, Teleport Enterprise (Cloud)가 해결할 수 없는 보안 및 규정 준수 요구 사항이 있는 경우 자체 호스팅 Teleport Enterprise 클러스터를 배포하는 것을 권장합니다.

작동 방식#

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

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

  1. 별도의 Teleport 플랜을 설정합니다. 이는 새로운 클라우드 호스팅 Teleport Enterprise 계정이거나, Auth 서비스와 프록시 서비스를 포함하는 자체 호스팅 Teleport Enterprise 클러스터일 수 있습니다.
  2. 원본 클러스터의 Auth 서비스 백엔드에서 동적 Teleport 리소스를 가져와서 새 클러스터의 Auth 서비스 백엔드에 적용합니다.
  3. Teleport 에이전트와 플러그인이 새 Teleport 클러스터에 연결되도록 재구성합니다.
  4. 마이그레이션이 성공했는지 확인합니다.

Teleport Community Edition에는 사용자가 Teleport를 사용해 볼 수 있도록 Teleport 기능의 작은 하위 집합이 포함되어 있습니다. 이 가이드는 Teleport Enterprise에서 Teleport Community Edition으로 마이그레이션하는 것이 아니라고 가정합니다.

사전 요구사항#

  • 기존 Teleport 클러스터.
  • tsh 및 tctl 클라이언트 도구. 이 가이드에서는 동적 리소스를 관리할 때 tctl을 사용한다고 가정하지만, Teleport Terraform 프로바이더와 쿠버네티스 오퍼레이터를 사용하거나, Teleport Auth 서비스 백엔드를 관리하기 위해 Teleport API를 사용하는 사용자 정의 스크립트를 사용하는 것도 가능합니다.
  • 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 계정으로 마이그레이션하는 경우, 계정 관리 팀의 도움을 받아 배포를 계획하고 실행합니다. 이를 위해 Teleport 자체 호스팅 문서를 참고하세요.

  4. 새 Teleport Enterprise 계정 버전과 동일한 메이저 버전이거나 한 메이저 버전 낮은 버전의 Teleport Enterprise 에이전트를 실행하고 있는지 확인합니다. Teleport Enterprise 에이전트의 버전을 확인하려면 tctl 명령을 사용하여 연결된 에이전트와 해당 버전의 인벤토리를 나열할 수 있습니다:

    # check for older versions
$ tctl inventory ls --older-than=<version>
# check for newer versions
$ tctl inventory ls --newer-than=<version>

  5. Teleport Enterprise (Self-Hosted) 고객은 정상적인 에이전트 집합을 유지하기 위해 자동 업데이트를 설정하는 것을 권장하며, Teleport Enterprise (Cloud)에서는 이를 필수로 요구합니다. 마이그레이션에 이를 포함시키려면 에이전트 자동 업데이트 설정 방법을 확인하세요.

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

  1. 원본 Teleport 클러스터에 로그인합니다. 이때 enterprise.example.com을 클러스터 도메인 이름으로 바꿉니다:

    # Use the --auth flag instead of --user to log in with Single Sign-On.
$ tsh login --proxy=enterprise.example.com --user=myuser
$ tctl status

  2. 새 Teleport Enterprise 클러스터에 로그인합니다. 이때 example.teleport.sh를 새 클러스터의 도메인 이름으로 바꿉니다:

    # Use the --auth flag instead of --user to log in with Single Sign-On.
$ tsh login --proxy=example.teleport.sh --user=myuser
$ tctl status

  3. 새 클러스터의 성능에 영향을 미치는 문제를 최신 상태로 파악하려면 Teleport Enterprise 상태 웹사이트를 구독하세요.

Warning

Teleport Enterprise (Cloud) 클러스터로 마이그레이션하는 경우, Teleport Enterprise (Cloud) 계정을 처음 설정할 때 표시되는 복구 코드를 안전하게 저장하여 액세스를 잃지 않도록 해야 합니다. 보안상의 이유로 Teleport 지원팀은 비밀번호 재설정이나 분실한 자격 증명 복구를 지원할 수 없습니다.

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

원본 클러스터와 새 Teleport 클러스터가 모두 정상적으로 실행되고 있는지 확인한 후, 한 클러스터에서 다음 클러스터로 동적 Teleport 리소스를 마이그레이션할 수 있습니다.

역할과 로컬 사용자 같은 동적 Teleport 리소스는 Teleport Auth 서비스 백엔드에 저장됩니다. 원본 Teleport 클러스터는 새 클러스터와 별도의 Auth 서비스 백엔드를 사용하므로, 첫 번째 백엔드에서 리소스를 가져온 다음 두 번째 백엔드에 다시 적용해야 합니다.

마이그레이션이 필요한 다른 리소스가 있는지 확인하려면 동적 리소스 목록을 검토하세요. 일반적인 동적 리소스에는 다음이 포함됩니다:

  • windows_desktop
  • apps
  • dbs
  • login_rule

이를 수행하려면:

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

    # Use the --auth flag instead of --user to log in with 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 계정에 로그인하여 내보낸 파일에서 리소스를 생성합니다:

    # Use the --auth flag instead of --user to log in with Single Sign-On.
$ tsh login --proxy=example.teleport.sh --user=admin@example.com
$ tctl create -f roles.yaml
$ tctl create -f users.yaml
Tip

동적 리소스는 Teleport Terraform 프로바이더나 쿠버네티스 오퍼레이터로 관리하는 것을 권장합니다. 이 경우 새 Teleport 클러스터의 동적 리소스를 관리하도록 이 도구들을 구성할 수 있습니다.

SSO Auth 커넥터의 경우, 대부분의 SSO 통합은 하나의 구성된 엔드포인트에서만 작동합니다. ID 공급자(Identity Provider)에서 새 Teleport Enterprise 엔드포인트 전용으로 별도의 SSO 커넥터를 생성하고, 새 Teleport Enterprise 테넌트에 새 Auth 커넥터를 구성하는 것을 권장합니다.

3/4단계. Teleport 서비스와 플러그인 마이그레이션하기#

Teleport 에이전트, Machine & Workload Identity Bot, 플러그인과 같은 서비스를 마이그레이션하려면, 먼저 Teleport로 관리하는 다양한 서비스의 목록을 작성하는 것부터 시작합니다. 다음 리소스는 마이그레이션 대상으로 고려해야 합니다:

  • Teleport 에이전트
  • Machine & Workload Identity Bot
  • 접근 요청 플러그인
  • Teleport Event Handler

서비스를 마이그레이션하기 전에, 새 Teleport Enterprise 계정에 로그인되어 있는지 확인하세요.

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

Teleport 에이전트 마이그레이션하기#

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

  1. 각 에이전트와 Machine & Workload Identity Bot에 대해 유효한 조인 토큰을 확보합니다. 위임된 조인 방식을 사용하는 것을 권장합니다.

  2. 임시(ephemeral) 토큰을 사용하는 경우, Teleport 서비스에 맞는 적절한 토큰 유형을 지정했는지 확인하세요. 토큰 유형에는 연결하려는 서비스에 따라 node, app, kube, db, windowsdesktop 등이 포함될 수 있습니다.

  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/v<code>[teleport.major_version]</code>를 사용하거나, 자동 업그레이드를 사용하는 경우 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 차트를 사용하는 경우, 기존 상태를 지우고 쿠버네티스 파드를 재활용하여 쿠버네티스 에이전트를 새 클러스터에 다시 조인시킵니다. 이렇게 하면 에이전트가 새 Teleport Enterprise 클러스터에 다시 등록되고 새 클러스터의 인증 기관(certificate authority)이 서명한 새 인증서를 얻게 됩니다.

    # get the release name
helm -n <namespace> ls
# delete the state secret
kubectl -n <namespace> delete secret <release-name>-0-state

    새 Teleport 쿠버네티스 에이전트의 설정에는 enterprise 값이 true로 설정되어 있어야 합니다.

Machine & Workload Identity Bot 마이그레이션하기#

일반적으로 다음 단계에 따라 Machine & Workload Identity Bot을 마이그레이션할 수 있습니다:

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

인프라에서 Bot을 재시작하고 구성하는 방법을 알아보려면 Machine & Workload Identity 배포 가이드를 참고하세요.

접근 요청 플러그인과 Event Handler#

일반적으로 다음 단계에 따라 Teleport 플러그인을 마이그레이션할 수 있습니다:

  1. 플러그인용 자격 증명을 생성하기 위해 Machine & Workload Identity를 사용하는 경우, Bot이 새 Teleport 클러스터에 연결하도록 재구성하고 Bot을 재시작합니다.

    그렇지 않으면 tctl로 새 Teleport 클러스터에 연결하여 아이덴티티 파일을 수동으로 생성한 다음, 이를 플러그인에서 사용할 수 있도록 합니다.

  2. 플러그인 구성 파일의 teleport.address 필드를 편집하여 포트 443과 함께 새 Teleport 클러스터의 주소를 가리키도록 플러그인을 재구성합니다.

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

인프라에서 실행 중인 특정 플러그인에 대해서는 다음 전체 문서를 참고하세요:

4/4단계. 최종 사용자 접근 및 성능 확인하기#

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

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

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

    $ tctl nodes ls

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

    등록된 모든 쿠버네티스 클러스터 나열:

    $ tctl kube ls

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

    $ tctl db ls

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

    $ tctl apps ls

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

    $ tctl desktop ls

  2. 최종 사용자가 인프라에 예상대로 SSO 접근이 가능한지 확인합니다.

  3. 새 Teleport Enterprise 클러스터를 사용할 수 없게 되는 경우를 대비하여 인프라에 대한 접근을 보장하는 브레이크 글래스(break-glass) 접근 절차를 마련합니다.

    예를 들어, OpenSSH를 올바르게 사용하는 방법에 대한 모범 사례를 따라 제한된 키로 OpenSSH를 실행할 수 있습니다.

부팅 시 systemd가 OpenSSH를 5분 동안 시작한 다음 종료하도록 구성하는 것을 권장합니다. 마스터 키는 안전한 볼트에 보관해야 합니다. 브레이크 글래스를 수행하려면, 마스터 키를 확보하고, 서버를 재부팅한 다음, 5분 이내에 OpenSSH 클라이언트를 사용하여 연결하세요.

추가 자료#

클라우드 호스팅 Teleport Enterprise 사용에 대한 자세한 내용은 클라우드 호스팅 Teleport Enterprise 계정 가입하기 문서를 참고하세요.

Teleport Enterprise 자체 호스팅 문서를 읽어보세요.

Teleport 플랜 간 마이그레이션

Teleport v18.9
원문 보기
요약

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

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

Teleport Community Edition으로 Teleport 데모 클러스터를 먼저 시도해 보고, 조직 전반에 Teleport를 배포하기 위해 Teleport Enterprise (Cloud)로 마이그레이션한 다음, Teleport Enterprise (Cloud)가 해결할 수 없는 보안 및 규정 준수 요구 사항이 있는 경우 자체 호스팅 Teleport Enterprise 클러스터를 배포하는 것을 권장합니다.

작동 방식#

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

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

  1. 별도의 Teleport 플랜을 설정합니다. 이는 새로운 클라우드 호스팅 Teleport Enterprise 계정이거나, Auth 서비스와 프록시 서비스를 포함하는 자체 호스팅 Teleport Enterprise 클러스터일 수 있습니다.
  2. 원본 클러스터의 Auth 서비스 백엔드에서 동적 Teleport 리소스를 가져와서 새 클러스터의 Auth 서비스 백엔드에 적용합니다.
  3. Teleport 에이전트와 플러그인이 새 Teleport 클러스터에 연결되도록 재구성합니다.
  4. 마이그레이션이 성공했는지 확인합니다.

Teleport Community Edition에는 사용자가 Teleport를 사용해 볼 수 있도록 Teleport 기능의 작은 하위 집합이 포함되어 있습니다. 이 가이드는 Teleport Enterprise에서 Teleport Community Edition으로 마이그레이션하는 것이 아니라고 가정합니다.

사전 요구사항#

  • 기존 Teleport 클러스터.
  • tsh 및 tctl 클라이언트 도구. 이 가이드에서는 동적 리소스를 관리할 때 tctl을 사용한다고 가정하지만, Teleport Terraform 프로바이더와 쿠버네티스 오퍼레이터를 사용하거나, Teleport Auth 서비스 백엔드를 관리하기 위해 Teleport API를 사용하는 사용자 정의 스크립트를 사용하는 것도 가능합니다.
  • 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 계정으로 마이그레이션하는 경우, 계정 관리 팀의 도움을 받아 배포를 계획하고 실행합니다. 이를 위해 Teleport 자체 호스팅 문서를 참고하세요.

  4. 새 Teleport Enterprise 계정 버전과 동일한 메이저 버전이거나 한 메이저 버전 낮은 버전의 Teleport Enterprise 에이전트를 실행하고 있는지 확인합니다. Teleport Enterprise 에이전트의 버전을 확인하려면 tctl 명령을 사용하여 연결된 에이전트와 해당 버전의 인벤토리를 나열할 수 있습니다:

    # check for older versions
$ tctl inventory ls --older-than=<version>
# check for newer versions
$ tctl inventory ls --newer-than=<version>

  5. Teleport Enterprise (Self-Hosted) 고객은 정상적인 에이전트 집합을 유지하기 위해 자동 업데이트를 설정하는 것을 권장하며, Teleport Enterprise (Cloud)에서는 이를 필수로 요구합니다. 마이그레이션에 이를 포함시키려면 에이전트 자동 업데이트 설정 방법을 확인하세요.

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

  1. 원본 Teleport 클러스터에 로그인합니다. 이때 enterprise.example.com을 클러스터 도메인 이름으로 바꿉니다:

    # Use the --auth flag instead of --user to log in with Single Sign-On.
$ tsh login --proxy=enterprise.example.com --user=myuser
$ tctl status

  2. 새 Teleport Enterprise 클러스터에 로그인합니다. 이때 example.teleport.sh를 새 클러스터의 도메인 이름으로 바꿉니다:

    # Use the --auth flag instead of --user to log in with Single Sign-On.
$ tsh login --proxy=example.teleport.sh --user=myuser
$ tctl status

  3. 새 클러스터의 성능에 영향을 미치는 문제를 최신 상태로 파악하려면 Teleport Enterprise 상태 웹사이트를 구독하세요.

Warning

Teleport Enterprise (Cloud) 클러스터로 마이그레이션하는 경우, Teleport Enterprise (Cloud) 계정을 처음 설정할 때 표시되는 복구 코드를 안전하게 저장하여 액세스를 잃지 않도록 해야 합니다. 보안상의 이유로 Teleport 지원팀은 비밀번호 재설정이나 분실한 자격 증명 복구를 지원할 수 없습니다.

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

원본 클러스터와 새 Teleport 클러스터가 모두 정상적으로 실행되고 있는지 확인한 후, 한 클러스터에서 다음 클러스터로 동적 Teleport 리소스를 마이그레이션할 수 있습니다.

역할과 로컬 사용자 같은 동적 Teleport 리소스는 Teleport Auth 서비스 백엔드에 저장됩니다. 원본 Teleport 클러스터는 새 클러스터와 별도의 Auth 서비스 백엔드를 사용하므로, 첫 번째 백엔드에서 리소스를 가져온 다음 두 번째 백엔드에 다시 적용해야 합니다.

마이그레이션이 필요한 다른 리소스가 있는지 확인하려면 동적 리소스 목록을 검토하세요. 일반적인 동적 리소스에는 다음이 포함됩니다:

  • windows_desktop
  • apps
  • dbs
  • login_rule

이를 수행하려면:

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

    # Use the --auth flag instead of --user to log in with 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 계정에 로그인하여 내보낸 파일에서 리소스를 생성합니다:

    # Use the --auth flag instead of --user to log in with Single Sign-On.
$ tsh login --proxy=example.teleport.sh --user=admin@example.com
$ tctl create -f roles.yaml
$ tctl create -f users.yaml
Tip

동적 리소스는 Teleport Terraform 프로바이더나 쿠버네티스 오퍼레이터로 관리하는 것을 권장합니다. 이 경우 새 Teleport 클러스터의 동적 리소스를 관리하도록 이 도구들을 구성할 수 있습니다.

SSO Auth 커넥터의 경우, 대부분의 SSO 통합은 하나의 구성된 엔드포인트에서만 작동합니다. ID 공급자(Identity Provider)에서 새 Teleport Enterprise 엔드포인트 전용으로 별도의 SSO 커넥터를 생성하고, 새 Teleport Enterprise 테넌트에 새 Auth 커넥터를 구성하는 것을 권장합니다.

3/4단계. Teleport 서비스와 플러그인 마이그레이션하기#

Teleport 에이전트, Machine & Workload Identity Bot, 플러그인과 같은 서비스를 마이그레이션하려면, 먼저 Teleport로 관리하는 다양한 서비스의 목록을 작성하는 것부터 시작합니다. 다음 리소스는 마이그레이션 대상으로 고려해야 합니다:

  • Teleport 에이전트
  • Machine & Workload Identity Bot
  • 접근 요청 플러그인
  • Teleport Event Handler

서비스를 마이그레이션하기 전에, 새 Teleport Enterprise 계정에 로그인되어 있는지 확인하세요.

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

Teleport 에이전트 마이그레이션하기#

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

  1. 각 에이전트와 Machine & Workload Identity Bot에 대해 유효한 조인 토큰을 확보합니다. 위임된 조인 방식을 사용하는 것을 권장합니다.

  2. 임시(ephemeral) 토큰을 사용하는 경우, Teleport 서비스에 맞는 적절한 토큰 유형을 지정했는지 확인하세요. 토큰 유형에는 연결하려는 서비스에 따라 node, app, kube, db, windowsdesktop 등이 포함될 수 있습니다.

  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/v<code>[teleport.major_version]</code>를 사용하거나, 자동 업그레이드를 사용하는 경우 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 차트를 사용하는 경우, 기존 상태를 지우고 쿠버네티스 파드를 재활용하여 쿠버네티스 에이전트를 새 클러스터에 다시 조인시킵니다. 이렇게 하면 에이전트가 새 Teleport Enterprise 클러스터에 다시 등록되고 새 클러스터의 인증 기관(certificate authority)이 서명한 새 인증서를 얻게 됩니다.

    # get the release name
helm -n <namespace> ls
# delete the state secret
kubectl -n <namespace> delete secret <release-name>-0-state

    새 Teleport 쿠버네티스 에이전트의 설정에는 enterprise 값이 true로 설정되어 있어야 합니다.

Machine & Workload Identity Bot 마이그레이션하기#

일반적으로 다음 단계에 따라 Machine & Workload Identity Bot을 마이그레이션할 수 있습니다:

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

인프라에서 Bot을 재시작하고 구성하는 방법을 알아보려면 Machine & Workload Identity 배포 가이드를 참고하세요.

접근 요청 플러그인과 Event Handler#

일반적으로 다음 단계에 따라 Teleport 플러그인을 마이그레이션할 수 있습니다:

  1. 플러그인용 자격 증명을 생성하기 위해 Machine & Workload Identity를 사용하는 경우, Bot이 새 Teleport 클러스터에 연결하도록 재구성하고 Bot을 재시작합니다.

    그렇지 않으면 tctl로 새 Teleport 클러스터에 연결하여 아이덴티티 파일을 수동으로 생성한 다음, 이를 플러그인에서 사용할 수 있도록 합니다.

  2. 플러그인 구성 파일의 teleport.address 필드를 편집하여 포트 443과 함께 새 Teleport 클러스터의 주소를 가리키도록 플러그인을 재구성합니다.

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

인프라에서 실행 중인 특정 플러그인에 대해서는 다음 전체 문서를 참고하세요:

4/4단계. 최종 사용자 접근 및 성능 확인하기#

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

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

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

    $ tctl nodes ls

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

    등록된 모든 쿠버네티스 클러스터 나열:

    $ tctl kube ls

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

    $ tctl db ls

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

    $ tctl apps ls

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

    $ tctl desktop ls

  2. 최종 사용자가 인프라에 예상대로 SSO 접근이 가능한지 확인합니다.

  3. 새 Teleport Enterprise 클러스터를 사용할 수 없게 되는 경우를 대비하여 인프라에 대한 접근을 보장하는 브레이크 글래스(break-glass) 접근 절차를 마련합니다.

    예를 들어, OpenSSH를 올바르게 사용하는 방법에 대한 모범 사례를 따라 제한된 키로 OpenSSH를 실행할 수 있습니다.

부팅 시 systemd가 OpenSSH를 5분 동안 시작한 다음 종료하도록 구성하는 것을 권장합니다. 마스터 키는 안전한 볼트에 보관해야 합니다. 브레이크 글래스를 수행하려면, 마스터 키를 확보하고, 서버를 재부팅한 다음, 5분 이내에 OpenSSH 클라이언트를 사용하여 연결하세요.

추가 자료#

클라우드 호스팅 Teleport Enterprise 사용에 대한 자세한 내용은 클라우드 호스팅 Teleport Enterprise 계정 가입하기 문서를 참고하세요.

Teleport Enterprise 자체 호스팅 문서를 읽어보세요.