이 페이지는 Cloud Translation API를 통해 번역되었습니다.

GKE용 관리형 워크로드 ID 인증 구성
컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

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

GKE용 관리 워크로드 ID를 설정하고 사용하려면 다음 단계를 따르세요.

관리형 워크로드 아이덴티티의 인증서를 발급하도록 Certificate Authority Service를 구성합니다.
CA를 워크로드 아이덴티티 풀에 바인딩합니다.
CA 풀에서 인증서를 요청하도록 관리형 워크로드 아이덴티티를 승인합니다.
관리형 워크로드 아이덴티티로 워크로드 배포

Google에서 관리하는 워크로드 아이덴티티 풀

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

Google에서 풀을 완전히 관리하므로 네임스페이스, ID, ID 공급자와 같은 하위 리소스를 만들 수 없습니다.
이 풀은 GKE 워크로드에만 사용할 수 있습니다. Compute Engine VM과 같은 다른 유형의 워크로드는 풀에 추가할 수 없습니다.
풀의 모든 클러스터에는 표준 Kubernetes 네임스페이스 동일성 모델이 적용됩니다. 즉, 풀의 모든 클러스터에 동일한 권한이 부여됩니다. 풀의 클러스터에서 실행되는 워크로드는 풀에 있는 모든 아이덴티티를 사용할 수 있습니다.

다중 프로젝트 구성

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

시작하기 전에

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.

관리형 워크로드 아이덴티티를 이해합니다.
GKE 클러스터가 하나 이상 있는지 확인합니다. 클러스터가 버전 1.32.2-gke.1652000 이상을 실행하는지 확인합니다. 1.30.1-gke.1156000 이전 버전으로 생성된 클러스터는 1.32.2-gke.1652000으로 업그레이드하더라도 관리 워크로드 ID를 사용할 수 없습니다.
GKE Fleet에 클러스터를 추가합니다. 클러스터가 Autopilot 클러스터인 경우 --enable-workload-identity를 생략합니다. Fleets는 신뢰할 수 있는 도메인 역할을 하는 Google 관리형 워크로드 아이덴티티 풀을 자동으로 만듭니다.

다음 명령어를 실행하여 GKE 함대를 사용 설정합니다.
```
gcloud container clusters update CLUSTER_NAME \
    --enable-workload-identity \
    --enable-fleet \
    --fleet-project=PROJECT_ID
```
다음을 바꿉니다.
- CLUSTER_NAME: GKE Fleet에 등록하려는 GKE 클러스터의 이름입니다.
- PROJECT_ID: GKE Fleet 호스트 프로젝트 ID
Enable the IAM and Certificate Authority Service APIs:
```
gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com
```
결제 및 할당량 프로젝트를 사용하도록 Google Cloud CLI를 구성합니다.
```
gcloud config set billing/quota_project PROJECT_ID
```
PROJECT_ID를 Fleet 프로젝트의 ID로 바꿉니다.

필요한 역할

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

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

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

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

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

GKE에 관리형 워크로드 ID를 구성하려면 먼저 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를 만들려면 다음 단계를 따르세요.

대규모의 단기 인증서 발급을 위한 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 풀 만들기를 참조하세요.
하위 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를 워크로드 ID 풀에 바인딩하려면 인증서 발급 구성이 있어야 합니다. 원하는 경우 워크로드가 여러 신뢰 도메인에서 인증해야 하는 경우 신뢰 구성 구성으로 풀을 업데이트할 수도 있습니다.

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

{
  "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: 선택사항. 리프 인증서 유효 기간(초)입니다. 값은 86,400 (1일)~25,920,000 (30일) 사이여야 합니다. 지정하지 않으면 기본값 86400 (1일)이 사용됩니다. 발급된 인증서의 실제 유효성 검사는 발급된 인증서의 수명을 제한할 수 있으므로 발급하는 CA에 따라 달라집니다.
ROTATION_WINDOW_PERCENTAGE: 선택사항: 갱신이 트리거되는 인증서 수명의 비율입니다. 값은 50에서 80 사이여야 합니다. 기본값은 50입니다.

신뢰 구성 파일 만들기

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

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

신뢰 구성 파일을 만들려면 다음 단계를 따르세요.

인증서를 다운로드합니다.
```
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 풀의 리전

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를 워크로드 ID 풀에 바인딩

CA 계층 구조를 만들고 각 CA의 인증서 발급 구성을 만든 후 CA를 워크로드 ID 풀에 바인딩합니다. 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를 생략해도 됩니다.

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

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

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

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

명령어 결과는 다음과 유사합니다.

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를 승인하려면 다음 단계를 따르세요.

각 하위 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입니다.
관리형 워크로드 아이덴티티에 하위 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 풀을 구성한 후 관리형 워크로드 아이덴티티가 있는 워크로드를 배포할 수 있습니다.

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

포드 배포

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

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

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

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

kubectl create namespace KUBERNETES_NAMESPACE

테스트 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

인증서 보기

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

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

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

인증서 파일을 확인합니다.
```
cat certfile
```
인증서의 X509v3 Subject Alternative Name 속성에는 다음 형식의 SPIFFE ID가 표시됩니다. spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

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

워크로드 간 인증 테스트

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

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

다음 단계

GKE용 관리 워크로드 ID 문제 해결
CA 풀 만들기 자세히 알아보기

직접 사용해 보기

Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

무료로 시작하기

GKE용 관리형 워크로드 ID 인증 구성 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Google에서 관리하는 워크로드 아이덴티티 풀

다중 프로젝트 구성

시작하기 전에

필요한 역할

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

루트 CA 풀 구성

루트 CA 구성

하위 CA 구성

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

신뢰 구성 파일 만들기

CA를 워크로드 ID 풀에 바인딩

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

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

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

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

포드 배포

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

인증서 보기

워크로드 간 인증 테스트

다음 단계

직접 사용해 보기

GKE용 관리형 워크로드 ID 인증 구성
컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.