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

11단계(선택사항): 워크로드 아이덴티티 구성

Apigee Hybrid v.1.13은 GKE의 워크로드 아이덴티티와 AKS 및 EKS의 워크로드 아이덴티티 제휴를 지원합니다. 이 가이드의 절차에서는 GKE의 워크로드 아이덴티티 구성만 다룹니다. AKS 및 AKS의 경우 AKS 및 EKS에서 워크로드 아이덴티티 제휴 사용 설정의 절차를 따르세요.

GKE에서 워크로드 아이덴티티 구성

Google Cloud 서비스 계정 및 Kubernetes 서비스 계정

Google Cloud 서비스 계정은 서비스 계정 자체로 인증하여 승인된 API 호출을 수행하는 데 사용할 수 있는 특별한 종류의 계정입니다. Google Cloud 서비스 계정에는 개별 사용자와 비슷한 역할 및 권한을 부여할 수 있습니다. 애플리케이션이 서비스 계정으로 인증되면 서비스 계정에 액세스 권한이 있는 모든 리소스에 액세스할 수 있습니다. Google Cloud 서비스 계정에 대해 자세히 알아보려면 서비스 계정 개요를 참조하세요.

4단계: 서비스 계정 만들기에서 Apigee Hybrid 설치에 대한 Google Cloud 서비스 계정을 만들었습니다. Apigee는 이러한 서비스 계정을 사용해서 하이브리드 구성요소를 인증합니다.

Kubernetes 서비스 계정은 Google Cloud 서비스 계정과 비슷합니다. Kubernetes 서비스 계정은 포드에서 실행되는 프로세스에 대한 ID를 제공하며 사용자와 비슷하게 API 서버에 인증을 수행하도록 허용합니다. Kubernetes 서비스 계정에 대해 자세히 알아보려면 포드에 대한 서비스 계정 구성을 참조하세요.

재정의 파일에서 gcp.workloadIdentity.enabled를 true로 설정한 경우 각 하이브리드 구성요소의 Helm 차트는 11단계: Helm 차트를 사용하여 Apigee Hybrid 설치에서 수행한 것처럼 설치 또는 업그레이드할 때 구성요소의 Kubernetes 서비스 계정을 만듭니다.

GKE에서 워크로드 아이덴티티를 구성하면 Google Cloud 서비스 계정이 Kubernetes 클러스터에 있는 Kubernetes 서비스 계정과 연결됩니다. 이렇게 하면 Kubernetes 서비스 계정이 Google Cloud 서비스 계정을 가장하고 할당된 역할 및 권한을 사용해서 하이브리드 구성요소에 인증을 수행할 수 있습니다.

안내에 따라 프로젝트에 대해 워크로드 아이덴티티를 구성합니다.

워크로드 아이덴티티 구성 준비

재정의 파일에서 워크로드 아이덴티티가 사용 설정되었는지 확인합니다. 재정의 파일의 다음 속성에서 사용 설정해야 합니다.
- namespace 필드는 필수 항목입니다. 예를 들면 다음과 같습니다.
```
instanceID: "hybrid-instance-1"
namespace: "apigee"
```
- 모든 구성요소에 단일 서비스 계정(비프로덕션)을 사용하는 경우 gcp.workloadIdentity.gsa로 지정합니다. 예를 들면 다음과 같습니다.
```
  gcp:
    workloadIdentity:
      enabled: true
      gsa: "apigee-non-prod@my-hybrid-project.iam.gserviceaccount.com"
  
```
- 구성요소마다 별도의 서비스 계정을 사용하는 경우(프로덕션 설치) 구성요소의 gsa 속성으로 서비스 계정을 지정합니다. 예를 들면 다음과 같습니다.
```
  logger:
    gsa: "apigee-logger@my-hybrid-project.iam.gserviceaccount.com"
  
```
참조: gcp.workloadIdentity.enabled.
다음 명령어를 사용하여 현재 gcloud 구성이 Google Cloud 프로젝트 ID로 설정되었는지 확인합니다.
```
gcloud config get project
```

필요한 경우 현재 gcloud 구성을 설정합니다.

gcloud config set project $PROJECT_ID

GKE 클러스터에 대한 워크로드 아이덴티티가 사용 설정되었는지 확인합니다. 1단계: 클러스터 만들기에서 클러스터를 만든 경우 6단계는 워크로드 아이덴티티를 사용 설정하는 것이었습니다. 다음 명령어를 실행하여 워크로드 아이덴티티가 사용 설정되었는지 확인할 수 있습니다.
리전 클러스터
```
gcloud container clusters describe $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'
```
영역 클러스터
```
gcloud container clusters describe $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten 'workloadIdentityConfig'
```
다음과 유사하게 출력됩니다.
```
  ---
  workloadPool: PROJECT_ID.svc.id.goog
```
결과에 null가 대신 표시되면 다음 명령어를 실행하여 클러스터에 대해 워크로드 아이덴티티를 사용 설정합니다.
리전 클러스터
```
gcloud container clusters update $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --project $PROJECT_ID \
  --region $CLUSTER_LOCATION
```
영역 클러스터
```
gcloud container clusters update  $CLUSTER_NAME \
  --workload-pool=$PROJECT_ID.svc.id.goog \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID
```
다음 명령어를 사용해서 각 노드 풀에 대해 워크로드 아이덴티티를 사용 설정합니다. 이 작업은 각 노드에 대해 최대 30분 정도 걸릴 수 있습니다.
리전 클러스터
```
gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA
```
영역 클러스터
```
gcloud container node-pools update NODE_POOL_NAME \
  --cluster=$CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --workload-metadata=GKE_METADATA
```
여기서 NODE_POOL_NAME는 각 노드 풀의 이름입니다. 대부분의 Apigee Hybrid 설치에서 두 기본 노드 풀의 이름은 apigee-data 및 apigee-runtime입니다.

다음 명령어를 사용해서 노드 풀에서 워크로드 아이덴티티가 사용 설정되었는지 확인합니다.

리전 클러스터

gcloud container node-pools describe apigee-data \
  --cluster $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

gcloud container node-pools describe apigee-runtime \
  --cluster $CLUSTER_NAME \
  --region $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

영역 클러스터

gcloud container node-pools describe apigee-data \
  --cluster $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

gcloud container node-pools describe apigee-runtime \
  --cluster $CLUSTER_NAME \
  --zone $CLUSTER_LOCATION \
  --project $PROJECT_ID \
  --flatten "config:"

다음과 비슷한 결과가 출력됩니다.

---
diskSizeGb: 100
diskType: pd-standard
...
workloadMetadataConfig:
  mode: GKE_METADATA

워크로드 아이덴티티 구성

다음 하이브리드 구성요소에 대해 워크로드 아이덴티티를 사용 설정하려면 다음 절차를 따르세요.

apigee-datastore
apigee-telemetry
apigee-org
apigee-env

apigee-datastore, apigee-env, apigee-org, apigee-telemetry 차트에 --dry-run 플래그를 사용하여 helm upgrade를 실행하면 올바른 GSA 및 KSA 이름으로 워크로드 아이덴티티를 구성하는 데 필요한 명령어가 출력에 포함됩니다.

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

helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server

NAME: datastore
  ...
For C* backup GKE Workload Identity, please make sure to add the below membership to the IAM policy binding using the respective kubernetes SA (KSA).
  gcloud iam service-accounts add-iam-policy-binding  \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:my-project.svc.id.goog[apigee/apigee-cassandra-backup-sa]" \
        --project :my-project

apigee-datastore에 대해 워크로드 아이덴티티를 설정하는 명령어를 가져오고 출력에서 NOTES: 아래에 있는 명령어를 실행합니다.
```
helm upgrade datastore apigee-datastore/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
apigee-telemetry에 대해 워크로드 아이덴티티를 설정하는 명령어를 가져오고 출력에서 NOTES: 아래에 있는 명령어를 실행합니다.
```
helm upgrade telemetry apigee-telemetry/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
apigee-org에 대해 워크로드 아이덴티티를 설정하는 명령어를 가져오고 출력에서 NOTES: 아래에 있는 명령어를 실행합니다.
```
helm upgrade $ORG_NAME apigee-org/ \
  --namespace $NAMESPACE \
  -f overrides.yaml \
  --dry-run=server
```
apigee-env에 대해 워크로드 아이덴티티를 설정하는 명령어를 가져오고 출력에서 NOTES: 아래에 있는 명령어를 실행합니다.
```
helm upgrade $ENV_NAME apigee-env/ \
  --namespace $NAMESPACE \
  --set env=ENV_NAME \
  -f overrides.yaml \
  --dry-run=server
```
설치의 각 환경에서 이 단계를 반복합니다.
(선택사항) Google Cloud 콘솔의 Kubernetes: 워크로드 개요 페이지에서 Kubernetes 서비스 계정의 상태를 확인할 수 있습니다.
워크로드로 이동

참고: apigee-cassandra-backup 및 apigee-cassandra-restore 서비스 계정에 대한 오류 상태가 표시될 수 있습니다. 현재 백업 또는 복원을 실행하고 있지 않으며 이러한 프로세스가 아직 완전히 구성되지 않았기 때문입니다. Cassandra 백업 및 복원 방법에 대한 자세한 내용은 feedbackCassandra 백업 개요를 참조하세요.

다음 단계

다음 단계에서는 Apigee 인그레스 게이트웨이를 구성하고 프록시를 배포하여 설치를 테스트합니다.

다음 단계

(다음) 1단계: Apigee 인그레스 노출 2