이 가이드는 Teleport 클러스터를 설정하여 구글 클라우드 키 관리 서비스(KMS)를 사용하여 모든 인증서에 서명하는 데 사용되는 CA 개인 키 자료를 저장하고 처리하는 방법을 보여줍니다.

Teleport는 첫 번째 Auth 서버의 초기 시작 시 내부 인증 기관(CA)을 위한 개인 키 자료를 생성합니다. 이 CA는 Teleport 클러스터 내의 클라이언트와 호스트에 발급된 모든 인증서에 서명하는 데 사용됩니다. 구글 클라우드 KMS를 사용하도록 구성하면, 이러한 CA에 대한 모든 개인 키 자료는 구글 클라우드 KMS 내에서 생성, 저장 및 서명에 사용됩니다. 실제 개인 키 대신, Teleport는 KMS 키의 ID만 저장합니다. 간단히 말해, 개인 키 자료는 결코 구글 클라우드 KMS를 떠나지 않습니다.

새로운 Teleport 클러스터를 시작하는 경우, 초기 시작 동안 모든 것이 처리되며 구성 후 특별한 개입이 필요하지 않습니다. 이미 소프트웨어 개인 키를 생성한 기존 Teleport 클러스터의 경우 CA 회전이 필요합니다. 자세한 내용은 기존 클러스터 마이그레이션을 읽어보세요.

필수 조건

• Teleport v17.0.0-dev 기업(자체 호스팅).
• 연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:

  tsh login --proxy=teleport.example.com --user=email@example.com
  tctl status
  클러스터  teleport.example.com
  버전  17.0.0-dev
  CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

  클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
  자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.
• 구글 클라우드 계정.

1/5단계. GCP에서 키 링 만들기

각 Teleport Auth 서버는 해당 Auth 서버가 생성하고 사용하는 모든 키를 보관할 GCP 키 링을 사용하도록 구성되어야 합니다. 고가용성 Teleport 클러스터에서 두 개 이상의 Auth 서버를 실행하는 경우, 모든 Auth 서버가 동일한 키 링을 사용하도록 구성할 수 있으며, 원하는 경우 각 서버를 서로 다른 지역의 고유한 키 링을 사용하도록 구성할 수 있습니다(중복성 또는 지연 시간 감소를 위해).

Teleport에서는 다른 클라우드 계정의 키와 논리적으로 분리하기 위해 전용 키 링을 만드는 것이 좋습니다. Teleport Auth 서버와 지리적으로 가까운 KMS 위치를 선택하십시오.

구글 클라우드 콘솔이나 gcloud CLI 도구에서 키 링을 만들 수 있습니다. 다음 가이드를 따르거나 gcloud CLI가 구성된 경우 다음 명령을 실행하세요:

gcloud kms keyrings create "teleport-keyring" --location location

2/5단계. GCP 서비스 계정 만들기

Teleport는 키 링 내의 KMS 키를 생성, 목록, 제거, 서명 및 조회할 수 있는 권한이 필요합니다. 다음 사용자 정의 IAM 역할을 만들며 시작하십시오.

# teleport_kms_role.yaml
title: teleport_kms_role
description: "KMS 키 사용을 위한 Teleport 권한"
stage: ALPHA
includedPermissions:
  - cloudkms.cryptoKeys.create
  - cloudkms.cryptoKeys.list
  - cloudkms.cryptoKeyVersions.create
  - cloudkms.cryptoKeyVersions.destroy
  - cloudkms.cryptoKeyVersions.useToSign
  - cloudkms.cryptoKeyVersions.viewPublicKey

gcloud iam roles create teleport_kms_role \    --project GCP-Project-ID \    --file teleport_kms_role.yaml \    --format yaml

출력의 name 필드는 사용자 정의 역할의 전체 자격 이름으로, 이후 단계에서 사용해야 합니다.

export IAM_ROLE=<위의 출력에서 역할 이름>

Teleport Auth 서버에 대한 GCP 서비스 계정이 없는 경우, 다음 명령으로 만들 수 있으며, 그렇지 않으면 기존 서비스 계정을 사용하십시오.

gcloud iam service-accounts create teleport-auth-server \    --description="Teleport Auth Server를 위한 서비스 계정" \    --display-name="Teleport Auth Server" \    --format=yaml

출력의 email 필드를 주의하십시오. 이는 서비스 계정의 식별자로 사용해야 합니다.

export SERVICE_ACCOUNT=<위의 명령에서 출력된 이메일>

이 키 링에 대한 서비스 계정에 역할을 부여하기 위해 IAM 정책 바인딩을 만듭니다.

gcloud kms keyrings add-iam-policy-binding teleport-keyring \    --location location \    --member "serviceAccount:${SERVICE_ACCOUNT}" \    --role "${IAM_ROLE}"

3/5단계. Auth 서버에 서비스 계정 자격 증명 제공

Teleport Auth 서버는 GCP KMS 서비스에 요청을 하기 위해 Application Default Credentials를 사용합니다.
2단계에서 생성한 teleport-auth-server 서비스 계정의 자격 증명을 Teleport Auth 서버를 실행 중인 환경의 Application Default Credentials에 제공해야 합니다.
지원되는 환경에는 GCE VM, GKE pod 등이 포함됩니다.

GCP 문서를 참조하여
Application Default Credentials
선호하는 환경에 자격 증명을 제공하는 방법을 알아보세요.

gcloud kms keys list --location location --keyring "teleport-keyring"
Listed 0 items.
gcloud kms keys create --location location --keyring "teleport-keyring" \    --purpose asymmetric-signing \    --default-algorithm rsa-sign-pkcs1-4096-sha512 \    test-key
gcloud kms keys list --location location --keyring "teleport-keyring"
NAME                                                                                   PURPOSE          ALGORITHM                   PROTECTION_LEVELprojects/my-gcp-account/locations/global/keyRings/teleport-keyring/cryptoKeys/test-key ASYMMETRIC_SIGN  RSA_SIGN_PKCS1_4096_SHA512  SOFTWARE
echo hello > /tmp/hello.txt
gcloud kms asymmetric-sign --keyring "teleport-keyring" --location location \    --key "test-key" --version 1 \    --input-file /tmp/hello.txt --signature-file /tmp/hello.sig
gcloud kms keys versions destroy --keyring "teleport-keyring" --location location --key "test-key" 1

4/5단계. Auth 서버를 KMS 키 사용으로 구성하기

CA 키 매개변수는 클러스터의 Teleport Auth 서버의 teleport.yaml 구성 파일에 정적으로 구성됩니다.

1단계에서 생성한 KMS 키 링의 완전한 이름을 GCP 콘솔에서 찾거나
다음 명령을 실행하여 확인할 수 있습니다:

gcloud kms keyrings list --location location

다음 ca_key_params 구성을 auth_service 섹션에 포함하세요.

# /etc/teleport.yaml
auth_service:
  # ...
  ca_key_params:
    gcp_kms:
      keyring: "projects/<your-gcp-project>/locations/<location>/keyRings/<your-teleport-keyring>"
      protection_level: "SOFTWARE"

새 Teleport 클러스터의 첫 번째 시작 전에 이를 구성하면 초기 CA 키가 GCP에서 생성되며 추가 단계가 필요하지 않습니다.
소프트웨어 키에서 GCP KMS 키로 기존 Teleport 클러스터를 마이그레이션하려면
기존 클러스터 마이그레이션 문서를 계속 읽어보세요.

5/5단계. 모든 것이 작동하는지 확인하기

gcp_kms 구성으로 Auth Server를 시작한 후, Teleport가 GCP 콘솔에 있는 키링에 키를 생성했는지 확인하거나 다음 명령어를 실행하여 확인할 수 있습니다.

gcloud kms keys list --keyring "teleport-keyring" --location location

Teleport 사용자로 클러스터에 로그인하여 새 인증서가 오류 없이 서명될 수 있는지 확인하십시오.

tctl status 는 또한 모든 인증 기관 키에 대해 storage 방법으로 GCP KMS 를 표시해야 합니다.

기존 클러스터 마이그레이션

기존 Teleport 클러스터가 있다면 첫 시작 시 소프트웨어 CA 키를 이미 생성했을 것입니다.
이 기존 CA 키는 모든 기존 사용자 및 호스트 인증서를 서명하는 데 사용되었으며, 클러스터 내의 다른 모든 서비스에서 신뢰받게 됩니다.

Teleport Auth Service가 GCP KMS에서 새 키를 생성하고 나머지 클러스터에서 신뢰받도록 하려면 모든 Teleport CA를 교체해야 합니다.

teleport start 는 CA가 교체되어야 하는 경우 시작 중 경고를 출력합니다.
인증서 기관(cert_authority ) 리소스에 대한 update 동사를 허용받은 사용자들은 CA를 교체하라는 클러스터 경고를 보게 됩니다.

CA 교체는 수동으로 또는 반자동으로 수행할 수 있으며, 인증서 교체에 대한 관리자 가이드를 참조하십시오.
tctl status 의 출력에 나열된 모든 CA는 교체되어야 합니다.