InfoGrab 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 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 Auth Service 백엔드를 관리하기 위해 Teleport Terraform 공급자와 Kubernetes 오퍼레이터 및 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 클러스터에 로그인합니다:

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

  2. 새 클러스터의 도메인 이름으로 를 교체하여 새 Teleport Enterprise 클러스터에 로그인합니다:

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

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

Warning

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

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

원본과 새 Teleport 클러스터가 모두 실행 중인지 확인한 후 한 클러스터에서 다음 클러스터로 동적 Teleport 리소스를 마이그레이션할 수 있습니다.

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

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

  • 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 공급자 또는 Kubernetes 오퍼레이터로 동적 리소스를 관리하는 것을 권장합니다. 이 경우 새 Teleport 클러스터에서 동적 리소스를 관리하도록 이러한 도구를 구성할 수 있습니다.

SSO 인증 커넥터의 경우 대부분의 SSO 통합은 단일 구성된 엔드포인트에서만 작동합니다. ID 공급자에서 새 Teleport Enterprise 엔드포인트용으로 별도의 SSO 커넥터를 생성하고 새 Teleport Enterprise 테넌트에서 새 Auth Connector를 구성하는 것이 권장됩니다.

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

Teleport Agents, 머신 및 워크로드 아이덴티티 Bot, 플러그인과 같은 서비스를 마이그레이션하려면 먼저 Teleport로 관리하는 다양한 서비스를 카탈로그화하세요. 다음 리소스를 마이그레이션 대상으로 고려해야 합니다:

  • Teleport Agents
  • 머신 및 워크로드 아이덴티티 Bot
  • Access Request 플러그인
  • Teleport Event Handler

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

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

Teleport Agents 마이그레이션#

Teleport Agents를 마이그레이션하려면:

  1. 각 Agent와 머신 및 워크로드 아이덴티티 Bot에 대해 유효한 조인 토큰을 받습니다. 위임된 조인 방법을 사용하는 것이 좋습니다.

  2. 임시 토큰을 사용하는 경우 Teleport 서비스와 일치하는 적절한 토큰 유형을 지정해야 합니다. 토큰 유형에는 Teleport 클러스터에 조인하려는 서비스에 따라 node, app, kube, db, windowsdesktop 등이 포함될 수 있습니다.

  3. 다음 예제에서 새 토큰은 15분의 TTL로 생성됩니다:

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

    이 명령에서 토큰에 node, app, db 유형을 할당하여 Teleport ssh_service, db_service, app_service를 실행하는 에이전트가 조인할 수 있음을 나타냅니다.

    이 가이드의 나중에 사용하기 위해 토큰을 복사합니다.

  4. 각 Agent에서 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 바이너리의 엔터프라이즈 버전은 Teleport Enterprise (Cloud) 또는 Teleport Enterprise (Self-Hosted)에 연결할 때 사용해야 합니다.

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

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

    Agent 구성에 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 서버에서 각 Agent의 로컬 에이전트 캐시를 삭제하고 Teleport 프로세스를 재시작하여 에이전트가 새 Teleport Enterprise 클러스터에 다시 조인하도록 강제합니다. 기본적으로 데이터는 /var/lib/teleport 디렉터리에 있습니다:

    rm -rf /var/lib/teleport

  10. teleport-kube-agent Helm 차트를 사용하는 경우 기존 상태를 지우고 Kubernetes 파드를 재순환하여 Kubernetes Agent가 새 클러스터에 다시 조인하도록 합니다. 이렇게 하면 에이전트가 새 Teleport Enterprise 클러스터에 다시 등록하고 새 클러스터의 인증 기관이 서명한 새 인증서를 받습니다.

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

    새 Teleport Kubernetes Agent의 설정은 enterprise 값이 true로 설정되어 있어야 합니다.

머신 및 워크로드 아이덴티티 Bot 마이그레이션#

일반적으로 다음 단계를 사용하여 머신 및 워크로드 아이덴티티 Bot을 마이그레이션할 수 있습니다:

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

인프라에 맞게 Bot을 재시작하고 구성하는 방법을 알아보려면 머신 및 워크로드 아이덴티티 배포 가이드를 읽으세요.

Access Request 플러그인 및 Event Handler#

일반적으로 다음 단계를 사용하여 Teleport 플러그인을 마이그레이션할 수 있습니다:

  1. 머신 및 워크로드 아이덴티티를 사용하여 플러그인의 자격증명을 생성하는 경우 Bot을 새 Teleport 클러스터에 연결하도록 재구성하고 Bot을 재시작합니다.

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

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

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

인프라에서 실행 중인 특정 플러그인에 대한 전체 문서를 읽으세요:

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를 실행할 수 있습니다.

부팅 시 5분 동안 OpenSSH를 시작한 다음 종료하도록 systemd를 구성하는 것이 좋습니다. 마스터 키는 보안 볼트에 저장해야 합니다. 비상 접근이 필요한 경우 마스터 키를 받아 서버를 재부팅하고 5분 이내에 OpenSSH 클라이언트를 사용하여 연결합니다.

추가 읽기#

클라우드 호스팅 Teleport Enterprise 사용에 대한 자세한 정보는 클라우드 호스팅 Teleport Enterprise 계정 등록 문서를 참조하세요.

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

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 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 Auth Service 백엔드를 관리하기 위해 Teleport Terraform 공급자와 Kubernetes 오퍼레이터 및 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 클러스터에 로그인합니다:

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

  2. 새 클러스터의 도메인 이름으로 를 교체하여 새 Teleport Enterprise 클러스터에 로그인합니다:

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

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

Warning

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

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

원본과 새 Teleport 클러스터가 모두 실행 중인지 확인한 후 한 클러스터에서 다음 클러스터로 동적 Teleport 리소스를 마이그레이션할 수 있습니다.

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

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

  • 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 공급자 또는 Kubernetes 오퍼레이터로 동적 리소스를 관리하는 것을 권장합니다. 이 경우 새 Teleport 클러스터에서 동적 리소스를 관리하도록 이러한 도구를 구성할 수 있습니다.

SSO 인증 커넥터의 경우 대부분의 SSO 통합은 단일 구성된 엔드포인트에서만 작동합니다. ID 공급자에서 새 Teleport Enterprise 엔드포인트용으로 별도의 SSO 커넥터를 생성하고 새 Teleport Enterprise 테넌트에서 새 Auth Connector를 구성하는 것이 권장됩니다.

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

Teleport Agents, 머신 및 워크로드 아이덴티티 Bot, 플러그인과 같은 서비스를 마이그레이션하려면 먼저 Teleport로 관리하는 다양한 서비스를 카탈로그화하세요. 다음 리소스를 마이그레이션 대상으로 고려해야 합니다:

  • Teleport Agents
  • 머신 및 워크로드 아이덴티티 Bot
  • Access Request 플러그인
  • Teleport Event Handler

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

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

Teleport Agents 마이그레이션#

Teleport Agents를 마이그레이션하려면:

  1. 각 Agent와 머신 및 워크로드 아이덴티티 Bot에 대해 유효한 조인 토큰을 받습니다. 위임된 조인 방법을 사용하는 것이 좋습니다.

  2. 임시 토큰을 사용하는 경우 Teleport 서비스와 일치하는 적절한 토큰 유형을 지정해야 합니다. 토큰 유형에는 Teleport 클러스터에 조인하려는 서비스에 따라 node, app, kube, db, windowsdesktop 등이 포함될 수 있습니다.

  3. 다음 예제에서 새 토큰은 15분의 TTL로 생성됩니다:

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

    이 명령에서 토큰에 node, app, db 유형을 할당하여 Teleport ssh_service, db_service, app_service를 실행하는 에이전트가 조인할 수 있음을 나타냅니다.

    이 가이드의 나중에 사용하기 위해 토큰을 복사합니다.

  4. 각 Agent에서 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 바이너리의 엔터프라이즈 버전은 Teleport Enterprise (Cloud) 또는 Teleport Enterprise (Self-Hosted)에 연결할 때 사용해야 합니다.

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

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

    Agent 구성에 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 서버에서 각 Agent의 로컬 에이전트 캐시를 삭제하고 Teleport 프로세스를 재시작하여 에이전트가 새 Teleport Enterprise 클러스터에 다시 조인하도록 강제합니다. 기본적으로 데이터는 /var/lib/teleport 디렉터리에 있습니다:

    rm -rf /var/lib/teleport

  10. teleport-kube-agent Helm 차트를 사용하는 경우 기존 상태를 지우고 Kubernetes 파드를 재순환하여 Kubernetes Agent가 새 클러스터에 다시 조인하도록 합니다. 이렇게 하면 에이전트가 새 Teleport Enterprise 클러스터에 다시 등록하고 새 클러스터의 인증 기관이 서명한 새 인증서를 받습니다.

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

    새 Teleport Kubernetes Agent의 설정은 enterprise 값이 true로 설정되어 있어야 합니다.

머신 및 워크로드 아이덴티티 Bot 마이그레이션#

일반적으로 다음 단계를 사용하여 머신 및 워크로드 아이덴티티 Bot을 마이그레이션할 수 있습니다:

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

인프라에 맞게 Bot을 재시작하고 구성하는 방법을 알아보려면 머신 및 워크로드 아이덴티티 배포 가이드를 읽으세요.

Access Request 플러그인 및 Event Handler#

일반적으로 다음 단계를 사용하여 Teleport 플러그인을 마이그레이션할 수 있습니다:

  1. 머신 및 워크로드 아이덴티티를 사용하여 플러그인의 자격증명을 생성하는 경우 Bot을 새 Teleport 클러스터에 연결하도록 재구성하고 Bot을 재시작합니다.

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

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

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

인프라에서 실행 중인 특정 플러그인에 대한 전체 문서를 읽으세요:

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를 실행할 수 있습니다.

부팅 시 5분 동안 OpenSSH를 시작한 다음 종료하도록 systemd를 구성하는 것이 좋습니다. 마스터 키는 보안 볼트에 저장해야 합니다. 비상 접근이 필요한 경우 마스터 키를 받아 서버를 재부팅하고 5분 이내에 OpenSSH 클라이언트를 사용하여 연결합니다.

추가 읽기#

클라우드 호스팅 Teleport Enterprise 사용에 대한 자세한 정보는 클라우드 호스팅 Teleport Enterprise 계정 등록 문서를 참조하세요.

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