AKS 및 EKS에서 워크로드 아이덴티티 제휴 사용 설정

Version 1.12 (latest)

지원되는 버전:

• v1.12(최신 버전)                        
• v1.11                         
• v1.10                                        
• 지원되는 버전 목록

지원되지 않는 버전:

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

이 주제에서는 AKS 및 EKS 플랫폼에서 Apigee Hybrid 설치에 대해 워크로드 아이덴티티를 사용 설정하는 방법을 설명합니다.

개요

워크로드 아이덴티티 제휴를 사용하면 Google Cloud 외부에서 실행되는 애플리케이션이 외부 ID 공급업체의 사용자 인증 정보를 사용하여 Google Cloud Platform 서비스 계정을 가장할 수 있습니다.

워크로드 아이덴티티 제휴를 사용하면 외부 환경에서 제공되는 인증 메커니즘을 애플리케이션에 사용함으로써 보안을 향상시키는 데 도움이 될 수 있고 서비스 계정 키 교체가 가능합니다.

개요는 워크로드 아이덴티티 제휴 사용 권장사항을 참조하세요.

워크로드 아이덴티티 제휴 설정

Apigee Hybrid와 함께 워크로드 아이덴티티 제휴를 사용하려면 먼저 클러스터를 구성한 다음 Apigee Hybrid 설치에 기능을 적용합니다.

워크로드 아이덴티티 제휴를 사용하도록 클러스터 구성

Google Cloud 안내에 따라 다음 수정을 사용해서 Kubernetes용 워크로드 아이덴티티 제휴를 구성합니다.

1. 워크로드 아이덴티티 제휴 구성 단계에서 생성된 워크로드 아이덴티티 풀과 공급업체의 기본 대상은 다음과 같습니다. 이 기본 대상을 사용하거나 예상한 커스텀 대상을 설정하고 나중에 사용할 수 있도록 이 값을 저장하세요.

   https://iam.googleapis.com/projects/PROJECT_NUM/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID

2. 필요한 서비스 계정이 이미 생성되어 있어야 하므로 서비스 계정 쌍 만들기의 단계를 수행할 필요가 없습니다.
   • IAM 서비스 계정: create-service-account 도구를 사용하여 Apigee Hybrid를 처음 설치하는 동안 IAM 서비스 계정('Google 서비스 계정'이라고도 함)을 이미 만들었을 수 있습니다. Apigee Hybrid에 필요한 IAM 서비스 계정 목록은 서비스 계정 정보를 참조하세요.

     다음 명령어를 사용하여 프로젝트의 IAM 서비스 계정 목록을 볼 수 있습니다.

     gcloud iam service-accounts list --project PROJECT_ID

   • Kubernetes 서비스 계정: Apigee Hybrid 차트는 helm install 또는 helm update 명령어를 실행할 때 각 구성요소에 필요한 Kubernetes 서비스 계정을 만듭니다.

     kubectl get sa 명령어를 사용하여 클러스터의 Kubernetes 서비스 계정을 확인할 수 있습니다.

     kubectl get sa -n APIGEE_NAMESPACE
     kubectl get sa -n apigee-system

3. Kubernetes 워크로드 배포의 1단계 후에 중지합니다. 사용자 인증 정보 구성 파일을 저장하고 --credential-source-file 매개변수에 입력된 경로(예: /var/run/service-account/token)를 저장합니다.
   참고: 또한 사용자 인증 정보 구성 json 파일의 각각 .audience 및 .credential_source.file 경로에서 audience 및 credentialSourceFile의 값을 찾을 수 있습니다. Apigee Hybrid를 구성하려면 재정의 파일에 이러한 값이 필요합니다.

워크로드 아이덴티티 제휴를 사용하도록 Apigee Hybrid 구성

팁: 일부 또는 모든 구성요소에 워크로드 아이덴티티 제휴를 사용하도록 하이브리드 설치를 구성할 수 있습니다. 예를 들어 UDCA는 워크로드 아이덴티티 제휴를 사용하고 동기화 담당자는 Google IAM 서비스 계정을 사용하거나 그 반대로도 가능합니다.

1. 사용자 인증 정보 소스 파일 및 출력 파일(credential-configuration.json)을 다음 차트 디렉터리에 복사합니다. 이 값은 Kubernetes 워크로드 배포의 1단계에서 제공한 값입니다.
   • apigee-datastore/
   • apigee-env
   • apigee-org/
   • apigee-telemetry/
   TIp: 이러한 파일에 하위 디렉터리를 사용할 수 있습니다(예: apigee-datastore/fwi/).
2. 클러스터의 재정의 파일을 다음과 같이 전역으로 변경합니다.

   gcp:
     workloadIdentity:
       enabled: false # must be set to false to use Workload Identity Federation
     federatedWorkloadIdentity:
       enabled: true
       audience: "AUDIENCE"
       credentialSourceFile: "CREDENTIAL_SOURCE_FILE"
   

   각 항목의 의미는 다음과 같습니다.

   • AUDIENCE는 워크로드 아이덴티티 공급업체의 허용된 대상으로, Kubernetes 워크로드 배포의 1단계에서 구성한 사용자 인증 정보 구성 json 파일의 .audience 아래의 값입니다.
   • CREDENTIAL_SOURCE_FILE은 워크로드 아이덴티티 제휴에서 서비스 계정의 사용자 인증 정보를 가져오는 데 사용하는 사용자 인증 정보 소스 파일의 파일 이름과 경로입니다. 이 값은 Kubernetes 워크로드 배포의 1단계에서 create-cred-config 명령어로 워크로드 아이덴티티 제휴를 구성할 때 credential-source-file에 제공하는 값입니다. 예를 들면 다음과 같습니다.

   예를 들면 다음과 같습니다.

   gcp:
     workloadIdentity:
       enabled: false
     federatedWorkloadIdentity:
       enabled: true
       audience: "//iam.googleapis.com/projects/123456789012/locations/global/workloadIdentityPools/aws-pool/providers/aws-provider"
       credentialSourceFile: "/var/run/service-account/token"
   

3. 워크로드 아이덴티티 제휴를 사용하여 각 구성요소의 재정의를 구성합니다. 설치에 맞게 인증서 파일, Kubernetes 보안 비밀 또는 Vault에 대한 안내를 선택합니다. <

   인증서 파일

   serviceAccountPath 값을 사용자 인증 정보 소스 파일로 바꿉니다. 이 경로는 차트 디렉터리의 상대 경로여야 합니다. 예를 들면 다음과 같습니다.

   udca:
     serviceAccountPath: fwi/credential-configuration.json
   

   K8s 보안 비밀

   1. 사용자 인증 정보 소스 파일을 사용하여 새 Kubernetes 보안 비밀을 만듭니다.

      kubectl create secret -n apigee generic SECRET_NAME --from-file="client_secret.json=CREDENTIAL_CONFIGURATION_FILE"

      예를 들면 다음과 같습니다.

      kubectl create secret -n apigee generic udca-fwi-secret --from-file="client_secret.json=./fwi/credential-configuration.json"

   2. serviceAccountRef 값을 새 보안 비밀로 바꿉니다. 예를 들면

      udca:
        serviceAccountRef: udca-fwi-secret
      

      입니다.

   Vault

   Vault에서 서비스 계정 키 SAKEY를 사용자 인증 정보 소스 파일을 사용하여 업데이트합니다. UDCA의 경우를 예로 들겠습니다(절차는 모든 구성요소와 유사함).

   SAKEY=$(cat ./fwi/credential-configuration.json); kubectl -n apigee exec vault-0 -- vault kv patch secret/apigee/orgsakeys udca="$SAKEY"

4. helm update 명령어를 사용하여 영향을 받는 각 구성요소에 변경사항을 적용합니다.

   이 클러스터에서 Vault를 처음 사용하는 경우 apigee-operator 차트를 업데이트합니다.

   helm upgrade operator apigee-operator/ \
     --namespace apigee-system \
     --atomic \
     -f overrides.yaml
   

   영향을 받는 나머지 차트를 다음 순서로 업데이트합니다.

   helm upgrade datastore apigee-datastore/ \
     --namespace apigee \
     --atomic \
     -f overrides.yaml
   

   helm upgrade telemetry apigee-telemetry/ \
     --namespace apigee \
     --atomic \
     -f overrides.yaml
   

   helm upgrade $ORG_NAME apigee-org/ \
     --namespace apigee \
     --atomic \
     -f overrides.yaml
   

   각 환경의 apigee-env 차트를 업데이트하여 매번 ENV_NAME을 바꿉니다.

   helm upgrade $ENV_NAME apigee-env/ \
     --namespace apigee \
     --atomic \
     --set env=$ENV_NAME \
     -f overrides.yaml
   

   구성요소 목록 및 해당 차트는 Apigee Hybrid Helm 참조를 확인하세요.

워크로드 아이덴티티 제휴 및 권장사항에 대한 자세한 내용은 워크로드 아이덴티티 제휴 사용 권장사항을 참조하세요.