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

이 주제에서는 AKSAKS 플랫폼에서 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)를 저장합니다.

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

  1. 사용자 인증 정보 소스 파일 및 출력 파일(credential-configuration.json)을 다음 차트 디렉터리에 복사합니다. 이 값은 Kubernetes 워크로드 배포1단계에서 제공한 값입니다.
    • apigee-datastore/
    • apigee-env
    • apigee-org/
    • apigee-telemetry/
  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_NAMESPACE \
      --atomic \
      -f overrides.yaml
    

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

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

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

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

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

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