Google Cloud KMS에 Teleport 개인 키 저장

요약

이 가이드는 Google Cloud Key Management Service(KMS)를 사용하여 Teleport 클러스터에서 발급하는 모든 인증서에 서명하는 데 사용되는 CA 개인 키 자료를 저장하고 처리하도록 Teleport 클러스터를 설정하는 방법을 보여줍니다.

작동 방식#

Teleport는 첫 번째 Auth Service 인스턴스의 초기 시작 시 내부 인증 기관(CA)에 대한 개인 키 자료를 생성합니다. 이 CA는 Teleport 클러스터의 클라이언트와 호스트에 발급되는 모든 인증서에 서명하는 데 사용됩니다. Google Cloud KMS를 사용하도록 구성된 경우 이 CA에 대한 모든 개인 키 자료는 Google Cloud KMS 내에서 생성, 저장 및 서명에 사용됩니다. 실제 개인 키 대신 Teleport는 KMS 키의 ID만 저장합니다. 즉, 개인 키 자료는 절대 Google Cloud KMS를 벗어나지 않습니다.

새 Teleport 클러스터를 시작하는 경우 구성 후 추가 개입 없이 초기 시작 시 모두 처리됩니다. 이미 소프트웨어 개인 키를 생성한 기존 Teleport 클러스터의 경우 CA 로테이션을 수행해야 합니다. 자세한 내용은 기존 클러스터 마이그레이션을 참조하세요.

사전 요구사항#

Teleport Enterprise (자체 호스팅).
Google Cloud 계정.

1단계/5. GCP에서 키 링 생성#

각 Teleport Auth Service 인스턴스는 해당 Auth Service 인스턴스에서 생성하고 사용하는 모든 키를 보유하는 GCP 키 링을 사용하도록 구성해야 합니다. 두 개 이상의 Auth Service 인스턴스가 있는 고가용성 Teleport 클러스터를 실행하는 경우 모든 Auth Service 인스턴스가 동일한 키 링을 사용하도록 구성하거나, 원하는 경우 각 인스턴스가 다른 리전에서 고유한 키 링을 사용하도록 구성할 수 있습니다(중복성 또는 대기 시간 감소를 위해).

Teleport 전용으로 사용되는 키 링을 생성하여 클라우드 계정의 다른 키와 논리적으로 분리하는 것이 좋습니다. Teleport Auth Service 인스턴스에 지리적으로 가까운 지원되는 KMS 위치를 선택하세요.

Google Cloud 콘솔에서 또는 gcloud CLI 도구에서 키 링을 생성할 수 있습니다. 이 가이드를 따르거나 gcloud CLI가 구성된 경우 다음 명령을 실행합니다:

$ gcloud kms keyrings create "" --location

2단계/5. GCP 서비스 계정 생성#

Teleport는 키 링에서 KMS 키를 생성, 나열, 삭제, 서명 및 조회하는 권한이 필요합니다. 다음 사용자 정의 IAM 역할을 정의하는 것으로 시작합니다.

# teleport_kms_role.yaml
title: teleport_kms_role
description: 'Teleport permissions for using KMS keys'
stage: ALPHA
includedPermissions:
- cloudkms.cryptoKeys.create
- cloudkms.cryptoKeys.list
- cloudkms.cryptoKeyVersions.create
- cloudkms.cryptoKeyVersions.destroy
- cloudkms.cryptoKeyVersions.useToSign
- cloudkms.cryptoKeyVersions.useToDecrypt
- cloudkms.cryptoKeyVersions.viewPublicKey

를 Google Cloud 프로젝트 ID로 지정하여 역할을 생성합니다:

$ gcloud iam roles create teleport_kms_role \
    --project  \
    --file teleport_kms_role.yaml \
    --format yaml

출력의 name 필드를 확인하세요. 이것이 사용자 정의 역할의 완전히 정규화된 이름이며 이후 단계에서 사용해야 합니다.

$ export IAM_ROLE=<role name output from above>

Teleport Auth Service용 GCP 서비스 계정이 아직 없다면 다음 명령으로 생성하거나, 기존 서비스 계정을 사용하세요.

$ gcloud iam service-accounts create teleport-auth-server \
    --description="Service account for Teleport Auth Service" \
    --display-name="Teleport Auth Service" \
    --format=yaml

출력의 email 필드를 확인하세요. 이것이 서비스 계정의 식별자로 사용되어야 합니다.

$ export SERVICE_ACCOUNT=<email output from above command>

이 키 링에 대해 서비스 계정에 역할을 부여하는 IAM 정책 바인딩을 생성합니다.

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

경고

이 서비스 계정에 접근 권한이 있는 누구나 Teleport CA인 것처럼 서명을 생성할 수 있다는 점에 유의하세요. 이것은 고도로 권한이 있는 것으로 간주되어야 하며 접근은 가능한 한 제한되어야 합니다.

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

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

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

권한 수동 확인

자격 증명이 올바르게 구성되었는지 확인하려면 Teleport Auth Service 환경에서 gcloud CLI 도구를 실행할 수 있습니다. 디버그에 사용할 수 있는 몇 가지 예시 명령은 다음과 같습니다:

$ gcloud kms keys list --location  --keyring ""
Listed 0 items.
$ gcloud kms keys create --location  --keyring "" \
    --purpose asymmetric-signing \
    --default-algorithm rsa-sign-pkcs1-4096-sha512 \
    test-key
$ gcloud kms keys list --location  --keyring ""
NAME                                                                                   PURPOSE          ALGORITHM                   PROTECTION_LEVEL
projects/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 "" --location  \
    --key "test-key" --version 1 \
    --input-file /tmp/hello.txt --signature-file /tmp/hello.sig
$ gcloud kms keys versions destroy --keyring "" --location  --key "test-key" 1

4단계/5. KMS 키를 사용하도록 Auth Service 구성#

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

GCP 콘솔에서 또는 다음을 실행하여 1단계에서 생성한 KMS 키 링의 완전히 정규화된 이름을 찾습니다:

$ gcloud kms keyrings list --location

보호 수준 선택

지원되는 KMS 보호 수준은 SOFTWARE와 HSM입니다. SOFTWARE를 선택하면 GCP KMS가 소프트웨어에서 모든 암호화 작업을 수행합니다(Teleport는 암호화 작업을 수행하지 않음). HSM을 선택하면 GCP KMS가 하드웨어 보안 모듈에서 모든 암호화 작업을 수행합니다.

두 보호 수준 모두 Google과 Teleport에서 안전하다고 간주하며, 결정을 내릴 때 조직의 요구 사항과 보안 정책을 평가해야 합니다.

한 가지 관련 차이점은 각 보호 수준의 키에 사용 가능한 사용 할당량입니다. 작성 시점에서 소프트웨어 키는 분당 6만 건의 암호화 작업이라는 프로젝트 전체 할당량을 가지고 있는 반면, 비대칭 HSM 키는 분당 3,000건의 작업 할당량을 가지고 있습니다. 업데이트된 수치는 KMS 문서를 참조하세요. 클러스터에 수천 명의 호스트나 활성 사용자가 있는 경우 소프트웨어 키의 더 높은 할당량이 특히 많은 새 인증서에 서명해야 하는 CA 로테이션 중에 잠재적인 제한을 피하는 데 도움이 될 수 있습니다.

auth_service 섹션에 다음 ca_key_params 구성을 포함합니다.

# /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 Service를 시작한 후 GCP 콘솔에서 또는 다음을 실행하여 Teleport가 키 링에 키를 생성했는지 확인할 수 있습니다:

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

Teleport 사용자로 클러스터에 로그인하여 오류 없이 새 인증서에 서명할 수 있는지 확인합니다.

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

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

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

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

teleport start는 CA 로테이션이 필요한 경우 시작 시 경고를 출력합니다. Teleport 역할에서 cert_authority 리소스에 대해 update 동사가 허용된 사용자는 CA를 로테이션하도록 상기시키는 클러스터 알림도 볼 수 있습니다.

CA 로테이션은 수동 또는 반자동으로 수행할 수 있습니다. 인증서 로테이션에 관한 관리자 가이드를 참조하세요. tctl status 출력에 나열된 모든 CA를 로테이션해야 합니다.