GKE용 관리형 워크로드 ID 인증 구성

이 문서에서는 GKE Fleet 관리형 클러스터에서 Google Kubernetes Engine(GKE)용 관리형 워크로드 아이덴티티를 구성하는 방법을 설명합니다. 또한 워크로드를 배포하고 워크로드의 ID와 인증서를 확인하는 방법도 설명합니다.

GKE용 관리형 워크로드 아이덴티티를 설정하고 사용하는 단계는 다음과 같습니다.

1. 관리형 워크로드 아이덴티티의 인증서를 발급하도록 Certificate Authority Service를 구성합니다.

2. CA를 워크로드 아이덴티티 풀에 바인딩합니다.

3. CA 풀에서 인증서를 요청하도록 관리형 워크로드 아이덴티티를 승인합니다.

4. 관리형 워크로드 아이덴티티로 워크로드를 배포합니다.

Google 관리형 워크로드 아이덴티티 풀

클러스터를 GKE Fleet에 추가하면 Fleet에서 트러스트 도메인의 루트 역할을 하는 Google 관리형 워크로드 아이덴티티 풀을 자동으로 만듭니다. Google 관리형 워크로드 아이덴티티 풀에는 다음과 같은 제약 조건이 있습니다.

• Google에서 풀을 완전히 관리하므로 네임스페이스, ID, ID 공급업체 등의 하위 리소스를 만들 수 없습니다.

• 풀은 GKE 워크로드에만 사용할 수 있습니다. Compute Engine VM과 같은 다른 유형의 워크로드를 풀에 추가할 수 없습니다.

• 풀의 모든 클러스터에는 표준 Kubernetes 네임스페이스 동일성 모델이 적용됩니다. 즉, 풀의 모든 클러스터에 동일한 권한이 부여됩니다. 풀의 클러스터에서 실행되는 워크로드는 풀에 있는 모든 ID를 사용할 수 있습니다.

다중 프로젝트 구성

이 문서에서 사용하는Google Cloud 리소스(예: GKE 클러스터, 루트 CA, 하위 CA)는 별도의 프로젝트에 있을 수 있습니다. 이러한 리소스를 참조할 때는 --project 플래그를 사용하여 각 리소스에 올바른 프로젝트를 지정합니다.

시작하기 전에

1. Create or select a Google Cloud project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

2. 관리형 워크로드 아이덴티티를 이해합니다.

3. GKE 클러스터가 하나 이상 있는지 확인합니다. 클러스터에서 버전 1.33.0-gke.2248000 이상을 실행하는지 확인합니다.

4. 클러스터를 GKE Fleet에 추가합니다. 클러스터가 Autopilot 클러스터인 경우 --enable-workload-identity를 생략합니다. Fleet은 트러스트 도메인 역할을 하는 Google 관리형 워크로드 아이덴티티 풀을 자동으로 만듭니다.

   다음 명령어를 실행하여 GKE Fleet를 사용 설정합니다.

   gcloud container clusters update CLUSTER_NAME \
       --workload-pool=PROJECT_ID.svc.id.goog \
       --enable-fleet \
       --fleet-project=PROJECT_ID
   

   다음을 바꿉니다.

   • CLUSTER_NAME: GKE Fleet에 등록하려는 GKE 클러스터의 이름
   • PROJECT_ID: GKE Fleet 호스트 프로젝트 ID

5. Enable the IAM and Certificate Authority Service APIs:

   gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com

6. 결제 및 할당량 프로젝트를 사용하도록 Google Cloud CLI를 구성합니다.

   gcloud config set billing/quota_project PROJECT_ID
   

   PROJECT_ID를 Fleet 프로젝트의 ID로 바꿉니다.

필요한 역할

관리형 워크로드 아이덴티티를 만들고 관리형 워크로드 아이덴티티 인증서를 프로비저닝하는 데 필요한 권한을 얻으려면 관리자에게 프로젝트에 대한 다음 IAM 역할을 부여해 달라고 요청하세요.

• 관리형 워크로드 아이덴티티를 만들고 구성하려면 다음 안내를 따르세요. IAM 워크로드 아이덴티티 풀 관리자(roles/iam.workloadIdentityPoolAdmin)
• CA 풀을 만들고 구성하려는 경우: CA 서비스 관리자(roles/privateca.admin)

역할 부여에 대한 자세한 내용은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

커스텀 역할이나 다른 사전 정의된 역할을 통해 필요한 권한을 얻을 수도 있습니다.

관리형 워크로드 아이덴티티에 대해 인증서를 발급하도록 CA 서비스 구성

GKE용 관리형 워크로드 아이덴티티를 구성하려면 먼저 인증 기관(CA)과 하나 이상의 하위 CA를 구성해야 합니다. 이 구성을 CA 계층 구조라고 합니다.

CA 서비스 풀을 사용하여 이 계층 구조를 설정할 수 있습니다. 이 계층 구조를 사용하면 하위 CA 풀에서 워크로드에 X.509 워크로드 아이덴티티 인증서를 발급합니다.

루트 CA 풀 구성

루트 CA 풀을 만들려면 다음을 수행합니다.

gcloud privateca pools create를 사용하여 엔터프라이즈 등급에서 루트 CA 풀을 만듭니다. 이 등급은 소규모의 장기 인증서 발급을 위한 것입니다.

gcloud privateca pools create ROOT_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=enterprise

다음을 바꿉니다.

• ROOT_CA_POOL_ID: 루트 CA 풀의 고유 ID입니다. ID는 최대 64자이며 소문자 및 대문자 영숫자 문자, 밑줄, 하이픈만 포함해야 합니다. 풀 ID는 리전 내에서 고유해야 합니다.

• REGION: 루트 CA 풀이 있는 리전입니다.

• CA_PROJECT_ID: 루트 CA를 만들 프로젝트의 ID입니다.

CA 풀, 등급, 리전에 대해 자세히 알아보려면 CA 풀 만들기를 참조하세요.

루트 CA 구성

gcloud privateca roots create를 사용하여 루트 CA 풀에 루트 CA를 만듭니다. 루트 CA 풀에서 유일한 CA인 경우 루트 CA를 사용 설정하라는 메시지가 표시될 수 있습니다.

루트 CA를 만들려면 다음 명령어를 실행합니다.

gcloud privateca roots create ROOT_CA_ID \
    --pool=ROOT_CA_POOL_ID \
    --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --max-chain-length=1 \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --auto-enable

다음을 바꿉니다.

• ROOT_CA_ID: 루트 CA의 고유한 이름입니다. CA 이름은 최대 64자이며 소문자 및 대문자 영숫자 문자, 밑줄, 하이픈만 포함해야 합니다. CA 이름은 리전 내에서 고유해야 합니다.
• ROOT_CA_POOL_ID: 루트 CA 풀의 ID입니다.
• ROOT_CA_CN: 루트 CA의 일반 이름입니다.
• ROOT_CA_ORGANIZATION: 루트 CA의 조직입니다.
• KEY_ALGORITHM: 키 알고리즘입니다(예: ec-p256-sha256).
• REGION: 루트 CA 풀이 있는 리전입니다.
• CA_PROJECT_ID: 루트 CA를 만든 프로젝트의 ID입니다.

CA의 subject 필드에 대한 자세한 내용은 제목을 참조하세요.

필요한 경우 루트 CA 풀에 루트 CA를 추가로 만듭니다. 이렇게 하면 루트 CA 순환에 유용할 수 있습니다.

하위 CA 구성

원하는 경우 하위 CA를 구성할 수 있습니다. 하위 CA를 구성하면 다음 작업을 수행할 수 있습니다.

• 다중 인증서 발급 시나리오: 인증서 발급 시나리오가 여러 개 있는 경우 시나리오마다 하위 CA를 만들 수 있습니다.

• 보다 효과적인 부하 분산: CA 풀에 여러 하위 CA를 추가하면 인증서 요청의 부하를 더 효과적으로 분산할 수 있습니다.

하위 CA 풀과 하위 CA를 만들려면 다음을 수행합니다.

1. 대규모의 단기 인증서 발급을 위한 DevOps 등급에서 하위 CA 풀을 만듭니다.

   gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
       --location=REGION \
       --project=CA_PROJECT_ID \
       --tier=devops
   

   다음을 바꿉니다.

   • SUBORDINATE_CA_POOL_ID: 하위 CA 풀의 고유 ID입니다. ID는 최대 64자이며 소문자 및 대문자 영숫자 문자, 밑줄, 하이픈만 포함해야 합니다. 풀 ID는 리전 내에서 고유해야 합니다.
   • REGION: 하위 CA 풀을 만들 리전입니다.
   • CA_PROJECT_ID: 하위 CA를 만든 프로젝트의 ID입니다.

   자세한 내용은 CA 풀 만들기를 참조하세요.

2. 하위 CA 풀에 하위 CA를 만듭니다. 기본 구성 기반 발급 모드를 변경하지 마십시오.

   gcloud privateca subordinates create SUBORDINATE_CA_ID \
       --pool=SUBORDINATE_CA_POOL_ID \
       --location=REGION \
       --issuer-pool=ROOT_CA_POOL_ID \
       --issuer-location=REGION \
       --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \
       --key-algorithm="KEY_ALGORITHM" \
       --use-preset-profile=subordinate_mtls_pathlen_0 \
       --project=CA_PROJECT_ID \
       --auto-enable
   

   다음을 바꿉니다.

   • SUBORDINATE_CA_ID: 하위 CA의 고유한 이름입니다. 이름은 최대 64자이며 소문자 및 대문자 영숫자 문자, 밑줄, 하이픈만 포함해야 합니다. 풀 이름은 리전 내에서 고유해야 합니다.
   • SUBORDINATE_CA_POOL_ID: 하위 CA 풀의 이름입니다.
   • REGION: 하위 CA 풀이 있는 리전입니다.
   • ROOT_CA_POOL_ID: 루트 CA 풀의 ID입니다.
   • REGION: 루트 CA 풀의 리전입니다.
   • SUBORDINATE_CA_CN: 하위 CA의 일반 이름입니다.
   • SUBORDINATE_CA_ORGANIZATION: 하위 CA 발급 조직의 이름입니다.
   • KEY_ALGORITHM: 키 알고리즘입니다(예: ec-p256-sha256).
   • CA_PROJECT_ID: 하위 CA를 만든 프로젝트의 ID입니다.

   CA의 subject 필드에 대한 자세한 내용은 제목을 참조하세요.

인증서 발급 구성 파일 만들기

CA를 워크로드 아이덴티티 풀에 바인딩하려면 인증서 발급 구성이 있어야 합니다. 필요한 경우 여러 트러스트 도메인에서 워크로드를 인증하려면 트러스트 구성 설정으로 풀을 업데이트할 수도 있습니다.

인증서 발급 구성을 구성하려면 인증서 발급 구성 파일을 만듭니다. 파일의 형식은 다음과 비슷합니다.

{
  "inlineCertificateIssuanceConfig": {
      "caPools": {
        "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1",
        "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2"
      },
      "lifetime": "DURATION",
      "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE,
      "keyAlgorithm": "ALGORITHM"
  }
}

다음을 바꿉니다.

• REGION: CA가 있는 리전입니다.

• CA_PROJECT_NUMBER: 하위 CA 풀을 만든 프로젝트의 프로젝트 번호입니다. CA_PROJECT_ID 프로젝트에서 프로젝트 번호를 가져오려면 다음 명령어를 실행합니다.

  gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"
  

• SUBORDINATE_CA_POOL_ID: 하위 CA 풀의 이름입니다.

• ALGORITHM: 선택사항. 비공개 키를 생성하는 데 사용되는 암호화 알고리즘입니다. 유효한 값은 ECDSA_P256(기본값), ECDSA_P384, RSA_2048, RSA_3072, RSA_4096입니다.

• DURATION: 선택사항. 리프 인증서 유효 기간(초). 값은 86400(1일)에서 2592000(30일) 사이여야 합니다. 지정하지 않으면 기본값 86400(1일)이 사용됩니다. 발급된 인증서의 실제 유효성 검사는 발급된 인증서의 수명을 제한할 수 있으므로 발급하는 CA에 따라 달라집니다.

• ROTATION_WINDOW_PERCENTAGE: 선택사항: 갱신이 트리거되는 인증서 수명의 백분율. 값은 50에서 80 사이여야 합니다. 기본값은 50입니다.

트러스트 구성 파일 만들기

기본적으로 동일한 트러스트 도메인 내의 워크로드는 관리형 워크로드 아이덴티티를 사용하여 상호 인증할 수 있습니다. 서로 다른 트러스트 도메인에 있는 워크로드가 상호 인증하도록 하려면 워크로드 아이덴티티 풀에서 트러스트 관계를 명시적으로 선언해야 합니다. 각 도메인의 인증서를 제공하는 inlineTrustConfig가 포함된 트러스트 구성 파일을 만들어 이를 수행합니다.

트러스트 구성 파일에는 관리형 워크로드 아이덴티티가 피어 인증서를 검증하는 데 사용하는 신뢰 앵커 집합이 포함되어 있습니다. 트러스트 구성 파일은 SPIFFE 트러스트 도메인을 CA 인증서에 매핑합니다.

트러스트 구성 파일을 만들려면 다음을 수행하세요.

1. 인증서를 다운로드합니다.

   gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \
       --output-file=CERTIFICATE_PATH \
       --location=REGION
   

   다음을 바꿉니다.

   • ROOT_CA_POOL_ID: 루트 CA 풀의 ID
   • CERTIFICATE_PATH: PEM 인코딩 인증서를 출력할 경로
   • REGION: 루트 CA 풀의 리전

2. PEM 형식 인증서가 포함된 인라인 트러스트 구성이 포함된 파일을 만듭니다. 파일은 다음과 유사합니다.

   {
     "inlineTrustConfig": {
       "additionalTrustBundles": {
         "TRUST_DOMAIN_NAME1": {
           "trustAnchors": [
             {
                 "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
             },
             {
                 "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
             }
           ]
         },
         "TRUSTED_DOMAIN_NAME2": {
           "trustAnchors": [
             {
                 "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL3\n-----END CERTIFICATE-----"
             },
             {
                 "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL4\n-----END CERTIFICATE-----"
             }
           ]
         }
       }
     }
   }
   

   다음을 바꿉니다.

   • TRUST_DOMAIN_NAME: 다음과 같은 형식의 트러스트 도메인 이름입니다.

     PROJECT_ID.svc.id.goog
     

   • CERTIFICATE_MATERIAL: 트러스트 도메인에서 인증서를 발급할 수 있는 신뢰할 수 있는 PEM 형식의 CA 인증서 집합입니다.

CA를 워크로드 아이덴티티 풀에 바인딩

CA 계층 구조를 만들고 각 CA의 인증서 발급 구성을 만든 후 CA를 워크로드 아이덴티티 풀에 바인딩합니다. CA를 워크로드 아이덴티티 풀에 바인딩하려면 CA의 인증서 발급 구성으로 워크로드 아이덴티티 풀을 업데이트합니다. 그런 다음 풀이 업데이트되었는지 확인할 수 있습니다.

워크로드 아이덴티티 풀 업데이트

풀을 업데이트하려면 다음 명령어를 실행합니다.

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

다음을 바꿉니다.

• TRUST_DOMAIN_NAME: 트러스트 도메인 이름으로, 형식은 다음과 같습니다.

  PROJECT_ID.svc.id.goog
  

• CIC_JSON_FILE_PATH: 이전에 만든 JSON 형식의 인증서 발급 구성 파일(cic.json)의 경로입니다.

• TC_JSON_FILE_PATH: 선택사항. 이전에 만든 JSON 형식 트러스트 구성 파일(tc.json)의 경로입니다. 워크로드가 서로 다른 트러스트 도메인에서 인증하는 경우 이 파일을 지정해야 합니다. 그렇지 않으면 --inline-trust-config를 생략해도 됩니다.

워크로드 아이덴티티 풀이 업데이트되었는지 확인

워크로드 아이덴티티 풀이 인증서 발급 구성 및 트러스트 구성과 함께 업데이트되었는지 확인하려면 다음 명령어를 실행합니다.

gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \
    --location="global" \
    --project=PROJECT_ID

TRUST_DOMAIN_NAME을 이 문서 앞부분에서 워크로드 아이덴티티 풀을 업데이트하는 데 사용한 트러스트 도메인 이름으로 바꿉니다.

명령어 출력은 다음과 유사합니다.

inlineCertificateIssuanceConfig:
    caPools:
      REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1,
      REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2
    keyAlgorithm: ALGORITHM
    lifetime: DURATION
    rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE
inlineTrustConfig:
    additionalTrustBundles:
      example.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL1
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL2
            -----END CERTIFICATE-----
      myorg.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL3
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL4
            -----END CERTIFICATE-----
name: PROJECT_ID.svc.id.goog
state: ACTIVE

명령어 출력에 inlineCertificateIssuanceConfig 또는 inlineTrustConfig가 없으면 gcloud CLI가 결제 및 할당량에 올바른 프로젝트를 사용하도록 올바르게 구성했는지 확인합니다. 최신 버전의 gcloud CLI로 업데이트해야 할 수도 있습니다.

CA 풀에서 인증서를 요청하도록 관리형 워크로드 아이덴티티를 승인

CA를 워크로드 아이덴티티 풀에 바인딩한 후 관리형 워크로드 아이덴티티가 CA 풀에서 인증서를 요청하도록 승인해야 합니다. 이러한 ID를 승인하려면 다음을 수행하세요.

1. 각 하위 CA 풀에서 CA Service 워크로드 인증서 요청자(roles/privateca.workloadCertificateRequester) IAM 역할을 트러스트 도메인에 부여합니다. 다음 gcloud privateca pools add-iam-policy-binding 명령어는 트러스트 도메인이 CA 서비스 인증서 체인에서 인증서를 요청하도록 승인합니다.

   gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
       --location=REGION \
       --role=roles/privateca.workloadCertificateRequester \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \
       --project=CA_PROJECT_ID
   

   다음을 바꿉니다.

   • SUBORDINATE_CA_POOL_ID: 하위 CA 풀의 ID입니다.
   • REGION: 하위 CA 풀의 리전입니다.

   • PROJECT_NUMBER: GKE 워크로드 아이덴티티 풀이 포함된 프로젝트의 프로젝트 번호입니다.

     PROJECT_ID에서 PROJECT_NUMBER를 가져오려면 다음 명령어를 실행합니다.

     gcloud projects describe PROJECT_ID --format="value(projectNumber)"
     

   • PROJECT_ID: GKE Fleet 호스트 프로젝트의 프로젝트 ID입니다.

   • CA_PROJECT_ID: 하위 CA를 만든 프로젝트의 ID입니다.

2. 관리형 워크로드 아이덴티티에 종속 CA 풀에 대한 CA 서비스 풀 리더(roles/privateca.poolReader) 역할을 부여합니다. 이렇게 하면 관리형 워크로드 아이덴티티가 CA 인증서 체인에서 서명된 X.509 인증서를 가져올 수 있습니다.

   gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
       --location=REGION \
       --role=roles/privateca.poolReader \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \
       --project=CA_PROJECT_ID
   

   다음을 바꿉니다.

   • SUBORDINATE_CA_POOL_ID: 하위 CA 풀의 ID입니다.
   • REGION: 하위 CA 풀의 리전입니다.
   • PROJECT_NUMBER: GKE 워크로드 아이덴티티 풀이 포함된 프로젝트의 프로젝트 번호입니다.
   • PROJECT_ID: GKE Fleet 호스트 프로젝트의 프로젝트 ID입니다.
   • CA_PROJECT_ID: 하위 CA를 만든 프로젝트의 ID입니다.

관리형 워크로드 아이덴티티로 워크로드 배포

관리형 워크로드 아이덴티티의 인증서를 발급하도록 CA 풀을 구성한 후 관리형 워크로드 아이덴티티가 있는 워크로드를 배포할 수 있습니다.

이 섹션에서는 관리형 워크로드 아이덴티티가 있는 테스트 워크로드를 배포하는 방법을 보여줍니다. 이렇게 하려면 포드를 배포하고, 사용자 인증 정보가 생성되었는지 확인하고, 인증서와 SPIFFE ID를 확인합니다.

포드 배포

클러스터에 테스트 포드를 배포하려면 다음 단계를 따르세요.

1. 클러스터 사용자 인증 정보를 가져옵니다.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=CLUSTER_ZONE \
       --project=CLUSTER_PROJECT_ID
   

2. Kubernetes 네임스페이스를 만듭니다.

   kubectl create namespace KUBERNETES_NAMESPACE
   

3. 테스트 PodSpec을 배포합니다.

   cat <<EOF | kubectl apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     namespace: KUBERNETES_NAMESPACE
     name: example-pod
   spec:
     containers:
     - name: main
       image: debian
       command: ['sleep', 'infinity']
       volumeMounts:
       - name: fleet-spiffe-credentials
         mountPath: /var/run/secrets/workload-spiffe-credentials
         readOnly: true
     nodeSelector:
       iam.gke.io/gke-metadata-server-enabled: "true"
     volumes:
     - name: fleet-spiffe-credentials
       csi:
         driver: podcertificate.gke.io
         volumeAttributes:
           signerName: spiffe.gke.io/fleet-svid
           trustDomain: fleet-project/svc.id.goog
   EOF
   

워크로드 사용자 인증 정보 나열

워크로드 사용자 인증 정보를 나열하려면 다음 명령어를 실행합니다. 사용자 인증 정보를 만드는 데 몇 분 정도 걸릴 수 있습니다.

kubectl exec -it example-pod -n KUBERNETES_NAMESPACE -- ls  /var/run/secrets/workload-spiffe-credentials

다음과 같은 출력이 표시됩니다.

ca_certificates.pem
certificates.pem
private_key.pem
trust_bundles.json

인증서 보기

인증서를 보려면 다음 단계를 따르세요.

1. 인증서를 인증서 파일로 내보냅니다.

   kubectl exec -it example-pod --namespace=KUBERNETES_NAMESPACE -- cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -noout -text > certfile
   

2. 인증서 파일을 확인합니다.

   cat certfile
   

   인증서의 X509v3 Subject Alternative Name 속성에는 spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default 형식의 SPIFFE ID가 표시됩니다.

   default는 기본 Kubernetes ServiceAccount를 나타냅니다.

워크로드 간 인증 테스트

워크로드 간 인증을 테스트하려면 Go를 사용하여 mTLS 인증 테스트를 참조하세요.

저장소의 샘플 코드는 client 및 server 워크로드를 만듭니다. 이 문서의 앞부분에서 생성한 인증서를 사용하여 워크로드 간의 상호 인증을 테스트할 수 있습니다.

다음 단계

• GKE용 관리형 워크로드 아이덴티티 문제 해결
• CA 풀 만들기 자세히 알아보기