AWS에서 워크로드 아이덴티티 사용

이 주제에서는 Anthos clusters on AWS(GKE on AWS) 워크로드에 워크로드 아이덴티티를 사용 설정하여 AWS 리소스에 대한 액세스를 제어하는 방법을 설명합니다.

Google Cloud Identity and Access Management(IAM) 계정과 함께 워크로드 아이덴티티를 사용하여 GCP 리소스에 대해 액세스를 제어하는 방법은 Google Cloud와 함께 워크로드 아이덴티티 사용을 참조하세요.

개요

워크로드 아이덴티티는 AWS IAM 권한을 사용하여 클라우드 리소스에 대한 액세스를 제어합니다. 워크로드 아이덴티티를 사용하면 각 워크로드에 서로 다른 IAM 역할을 할당할 수 있습니다. 이러한 세분화된 권한 제어를 통해 최소 권한 원칙을 따를 수 있습니다. 워크로드 아이덴티티가 없으면 Anthos clusters on AWS 노드에 AWS IAM 역할을 할당하여 노드의 모든 워크로드에 노드와 동일한 권한을 부여해야 합니다.

클러스터에 워크로드 아이덴티티를 사용 설정하려면 이를 수행하는 관리자 역할별로 분류된 다음 단계를 완료합니다.

클러스터 관리자

1. OIDC 검색 데이터를 저장할 Cloud Storage 버킷을 만듭니다.
2. 버킷에서 읽기를 위해 Identity and Access Management 역할을 만듭니다.
3. 워크로드 아이덴티티가 사용 설정된 사용자 클러스터를 만듭니다.
4. 생성 시 pod에 워크로드 아이덴티티 사용자 인증 정보를 적용하는 클러스터에 웹훅을 만듭니다. 웹훅을 사용하지 않으려면 pod에 환경 변수를 수동으로 설정할 수 있습니다.
5. AWS OIDC 공급자 구성
6. AWS IAM 역할 및 정책 만들기.

클러스터 관리자 또는 개발자

6. Kubernetes 서비스 계정을 만들고 여기에 AWS 정책을 결합합니다.

개발자

7. pod에 사용자 인증 정보를 적용합니다.

기본 요건

이 문서의 단계를 완료하려면 다음 설정이 있어야 합니다.

• Anthos clusters on AWS 관리 서비스

• Kubernetes 1.17.9 이후 버전을 실행하는 사용자 클러스터

  참고: Kubernetes 1.17 또는 1.18 클러스터를 만든 경우 Kubernetes 1.19로 업그레이드하기 전 웹훅을 업그레이드해야 합니다.

• 다음 권한 및 도구

권한

워크로드 아이덴티티가 사용 설정된 클러스터를 만들려면 다음 권한이 있어야 합니다.

Google Cloud

• 균일한 버킷 수준 액세스 권한을 사용 설정하여 공개적으로 읽을 수 있는 Cloud Storage 버킷을 만듭니다.
• 버킷에 대한 management-sa@PROJECT_NAME.iam.gserviceaccount.com 읽기/쓰기 권한을 부여합니다.

AWS

• AWS OIDC 공급자 만들기
• AWS IAM 역할 만들기

도구

로컬 머신에 jq 도구를 설치하는 것이 좋습니다.

OIDC 검색 버킷 만들기

이 섹션은 클러스터 관리자를 위해 작성되었습니다.

사용자 클러스터는 공개적으로 액세스할 수 있는 Cloud Storage 버킷에 OIDC 검색 데이터를 저장해야 합니다. 버킷에는 OIDC 검색 구성과 공개 키가 포함됩니다. AWS는 콘텐츠를 사용하여 사용자 클러스터의 요청을 인증합니다.

버킷에 다음 속성이 있어야 합니다.

• 공개적으로 읽기 가능
• 균일한 버킷 수준 액세스 사용 설정

이러한 속성이 포함된 버킷이 없으면 다음 gsutil 명령어를 사용하여 버킷을 만드세요.

BUCKET=BUCKET_NAME
gsutil mb -b on gs://${BUCKET}
gsutil iam ch allUsers:objectViewer gs://${BUCKET}

BUCKET_NAME을 새 버킷의 이름으로 바꿉니다.

관리 서비스 계정에 권한 부여

Anthos clusters on AWS 관리 서비스의 Identity and Access Management 서비스 계정에는 객체를 읽고 이 버킷에서 쓸 수 있는 권한이 필요합니다.

1. 다음 gsutil 명령어를 사용하여 관리 서비스 계정에 권한을 부여합니다.

   MANAGEMENT_SA=management-sa@PROJECT_NAME.iam.gserviceaccount.com
   gsutil iam ch serviceAccount:${MANAGEMENT_SA}:admin gs://${BUCKET}
   

   PROJECT_NAME를 Google Cloud 프로젝트 ID로 바꿉니다.

2. 이 버킷 관리를 위해 권한이 있는 새 IAM 역할을 만듭니다. 역할을 만들려면 먼저 역할 정의를 파일에 저장한 후 역할을 만들고 역할을 관리 서비스 계정에 바인딩합니다.

   이러한 단계를 완료하려면 다음 명령어를 실행합니다.

   cat << EOF >  anthos-oidc-role.yaml
   title: anthosAwsOidcStorageAdmin
   description: permissions to manage the OIDC buckets
   stage: GA
   includedPermissions:
   - storage.buckets.get
   EOF
   
   gcloud iam roles create anthosAwsOidcStorageAdmin --project=PROJECT_NAME \
     --file=anthos-oidc-role.yaml
   
   gcloud projects add-iam-policy-binding \
     PROJECT_NAME \
     --member=serviceAccount:${MANAGEMENT_SA} \
     --role=projects/PROJECT_NAME/roles/anthosAwsOidcStorageAdmin
   

   PROJECT_NAME를 Google Cloud 프로젝트 ID로 바꿉니다.

   Google Cloud CLI가 정책 바인딩이 생성되었는지 확인합니다.

사용자 클러스터 만들기

이 섹션은 클러스터 관리자를 위해 작성되었습니다.

워크로드 아이덴티티가 사용 설정된 사용자 클러스터를 만듭니다.

OIDC 검색 버킷에 대한 세부정보가 포함된 사용자 클러스터를 만듭니다. 이 정보를 AWSCluster의 spec.controlPlane.workloadIdentity.oidcDiscoveryGCSBucket 필드에 설정합니다.

이 예시에서는 AWSCluster 및 AWSNodePool CRD에서 수동으로 클러스터를 만듭니다.

1. AWS용 Anthos 클러스터 구성이 있는 디렉터리로 변경합니다. 이 디렉터리는 관리 서비스를 설치할 때 생성됩니다.

   cd anthos-aws

2. anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 관리 서비스로 전환합니다.

   cd anthos-aws
   anthos-gke aws management get-credentials

   참고: anthos-gke에서는 aws configure를 실행할 때 지정한 사용자 인증 정보를 사용합니다.

3. 텍스트 편집기를 열고 다음 AWSCluster 정의를 custom-cluster.yaml이라는 파일에 복사합니다.

   apiVersion: multicloud.cluster.gke.io/v1
   kind: AWSCluster
   metadata:
     name: CLUSTER_NAME
   spec:
     region: AWS_REGION
     networking:
       vpcID: VPC_ID
       podAddressCIDRBlocks: POD_ADDRESS_CIDR_BLOCKS
       serviceAddressCIDRBlocks: SERVICE_ADDRESS_CIDR_BLOCKS
       ServiceLoadBalancerSubnetIDs: SERVICE_LOAD_BALANCER_SUBNETS
     controlPlane:
       version:  CLUSTER_VERSION # Latest version is 1.25.5-gke.2100
       instanceType: AWS_INSTANCE_TYPE
       keyName: SSH_KEY_NAME
       subnetIDs:
       - CONTROL_PLANE_SUBNET_IDS
       securityGroupIDs:
       - CONTROL_PLANE_SECURITY_GROUPS
       iamInstanceProfile: CONTROL_PLANE_IAM_ROLE
       rootVolume:
         sizeGiB: ROOT_VOLUME_SIZE
         volumeType: ROOT_VOLUME_TYPE # Optional
         iops: ROOT_VOLUME_IOPS # Optional
         kmsKeyARN: ROOT_VOLUME_KEY # Optional
       etcd:
         mainVolume:
           sizeGiB: ETCD_VOLUME_SIZE
           volumeType: ETCD_VOLUME_TYPE # Optional
           iops: ETCD_VOLUME_IOPS # Optional
           kmsKeyARN: ETCD_VOLUME_KEY # Optional
       databaseEncryption:
         kmsKeyARN: ARN_OF_KMS_KEY
       hub: # Optional
         membershipName: ANTHOS_CONNECT_NAME
       cloudOperations: # Optional
         projectID: YOUR_PROJECT
         location: GCP_REGION
         enableLogging: ENABLE_LOGGING
         enableMonitoring: ENABLE_MONITORING
       workloadIdentity: # Optional
         oidcDiscoveryGCSBucket: WORKLOAD_IDENTITY_BUCKET
   

   다음을 바꿉니다.

   • CLUSTER_NAME: 클러스터 이름입니다.

   • AWS_REGION: 클러스터가 실행되는 AWS 리전입니다.

     참고: 관리 서비스와 동일한 리전에 사용자 클러스터를 만들어야 합니다.

   • VPC_ID: 클러스터가 실행되는 VPC의 ID입니다.

   • POD_ADDRESS_CIDR_BLOCKS: 클러스터 pod에서 사용되는 IPv4 주소 범위입니다. 현재 단일 범위만 지원됩니다. 범위는 네트워크에서 연결할 수 있는 서브넷과 겹치지 않아야 합니다. 여러 다른 AWSCluster 객체에 같은 범위를 사용하는 것이 안전합니다. 예를 들면 10.2.0.0/16입니다.

   • SERVICE_ADDRESS_CIDR_BLOCKS: 클러스터 서비스에서 사용하는 IPv4 주소의 범위로 바꿉니다. 현재 단일 범위만 지원됩니다. 범위는 네트워크에서 연결할 수 있는 서브넷과 겹치지 않아야 합니다. 여러 다른 AWSCluster 객체에 같은 범위를 사용하는 것이 안전합니다. 예를 들면 10.1.0.0/16입니다.

   • SERVICE_LOAD_BALANCER_SUBNETS: AWS용 Anthos 클러스터가 공개 또는 비공개 부하 분산기를 만들 수 있는 서브넷 ID입니다.

   • CLUSTER_VERSION: AWS용 Anthos 클러스터에서 지원하는 Kubernetes 버전입니다. 최신 버전은 1.25.5-gke.2100입니다.

   • AWS_INSTANCE_TYPE: 지원되는 EC2 인스턴스 유형입니다.

   • SSH_KEY_NAME: AWS EC2 키 쌍입니다.

   • CONTROL_PLANE_SUBNET_IDS: 제어 영역 인스턴스가 실행될 AZ의 서브넷 ID입니다.

   • CONTROL_PLANE_SECURITY_GROUPS: 관리 서비스 설치 중에 생성된 securityGroupID입니다. 제어 영역에 연결하는 데 필요한 securityGroupID를 추가하여 이를 맞춤설정할 수 있습니다.

   • CONTROL_PLANE_IAM_PROFILE: 제어 영역 복제본에 할당된 AWS EC2 인스턴스 프로필의 이름입니다.

   • ROOT_VOLUME_SIZE: 제어 영역 루트 볼륨의 크기(기비바이트)입니다.

   • EBS 볼륨 유형이 있는 ROOT_VOLUME_TYPE입니다. 예를 들면 gp3입니다.

   • 볼륨에 대해 초당 프로비저닝된 IO 작업량(IOPS)이 있는 ROOT_VOLUME_IOPS입니다. volumeType가 GP3일 때만 유효합니다. 자세한 내용은 범용 SSD 볼륨(gp3)을 참조하세요.

   • 제어 영역 인스턴스 루트 볼륨을 암호화하는 AWS KMS 키의 Amazon 리소스 이름이 있는 ROOT_VOLUME_KEY입니다.

   • ETCD_VOLUME_SIZE: etcd에서 사용하는 볼륨의 크기입니다.

   • EBS 볼륨 유형이 있는 ETCD_VOLUME_TYPE입니다. 예를 들면 gp3입니다.

   • 볼륨에 대해 초당 프로비저닝된 IO 작업량(IOPS)이 있는 ETCD_VOLUME_IOPS입니다. volumeType가 gp3일 때만 유효합니다. 자세한 내용은 범용 SSD 볼륨(gp3)을 참조하세요.

   • 제어 영역 etcd 데이터 볼륨을 암호화하는 AWS KMS 키의 Amazon 리소스 이름이 있는 ETCD_VOLUME_KEY입니다.

   • ARN_OF_KMS_KEY: 클러스터 보안 비밀을 암호화하는 데 사용되는 AWS KMS 키입니다.

   • ANTHOS_CONNECT_NAME: 클러스터를 등록하는 데 사용된 Connect 멤버십 이름입니다. 멤버십 이름은 고유해야 합니다. 예를 들면 projects/YOUR_PROJECT/locations/global/memberships/CLUSTER_NAME입니다. 여기서 YOUR_PROJECT는 Google Cloud 프로젝트이고 CLUSTER_NAME는 프로젝트의 고유한 이름입니다. 이 필드는 선택사항입니다.

   • YOUR_PROJECT: 프로젝트 ID입니다.

   • GCP_REGION: 로그를 저장할 Google Cloud 리전입니다. AWS 리전과 가까운 리전을 선택합니다. 자세한 내용은 글로벌 위치 - 리전 및 영역을 참조하세요. 예를 들면 us-central1입니다.

   • ENABLE_LOGGING: true 또는 false(제어 영역 노드에서 Cloud Logging 사용 설정 여부)

   • ENABLE_MONITORING: true 또는 false(제어 영역 노드에서 Cloud Monitoring 사용 설정 여부)

   • WORKLOAD_IDENTITY_BUCKET: 워크로드 아이덴티티 검색 정보가 포함된 Cloud Storage 버킷 이름입니다. 이 필드는 선택사항입니다.

4. 클러스터에 하나 이상의 AWSNodePool을 만듭니다. 텍스트 편집기를 열고 다음 AWSCluster 정의를 custom-nodepools.yaml이라는 파일에 복사합니다.

   apiVersion: multicloud.cluster.gke.io/v1
   kind: AWSNodePool
   metadata:
     name: NODE_POOL_NAME
   spec:
     clusterName: AWSCLUSTER_NAME
     version:  CLUSTER_VERSION # latest version is 1.25.5-gke.2100
     region: AWS_REGION
     subnetID: AWS_SUBNET_ID
     minNodeCount: MINIMUM_NODE_COUNT
     maxNodeCount: MAXIMUM_NODE_COUNT
     maxPodsPerNode: MAXIMUM_PODS_PER_NODE_COUNT
     instanceType: AWS_NODE_TYPE
     keyName: KMS_KEY_PAIR_NAME
     iamInstanceProfile: NODE_IAM_PROFILE
     proxySecretName: PROXY_SECRET_NAME
     rootVolume:
       sizeGiB: ROOT_VOLUME_SIZE
       volumeType: VOLUME_TYPE # Optional
       iops: IOPS # Optional
       kmsKeyARN: NODE_VOLUME_KEY # Optional
   

   다음을 바꿉니다.

   • NODE_POOL_NAME: AWSNodePool의 고유한 이름입니다.
   • AWSCLUSTER_NAME: AWSCluster의 이름입니다. 예를 들면 staging-cluster입니다.
   • CLUSTER_VERSION: AWS Kubernetes용 Anthos 클러스터가 지원되는 버전입니다.
   • AWS_REGION: AWSCluster와 동일한 AWS 리전입니다.
   • AWS_SUBNET_ID: AWSCluster와 동일한 리전의 AWS 서브넷입니다.
   • MINIMUM_NODE_COUNT: 노드 풀의 최소 노드 수입니다. 자세한 내용은 사용자 클러스터 확장을 참조하세요.
   • MAXIMUM_NODE_COUNT: 노드 풀의 최대 노드 수입니다.
   • MAXIMUM_PODS_PER_NODE_COUNT: AWS용 Anthos 클러스터가 노드에 할당할 수 있는 최대 pod 수입니다.
   • AWS_NODE_TYPE: AWS EC2 인스턴스 유형입니다.
   • KMS_KEY_PAIR_NAME: 각 노드 풀 작업자에 할당된 AWS KMS 키 쌍입니다.
   • NODE_IAM_PROFILE: 풀의 노드에 할당된 AWS EC2 인스턴스 프로필의 이름입니다.
   • ROOT_VOLUME_SIZE: 제어 영역 루트 볼륨의 크기(기비바이트)입니다.
   • VOLUME_TYPE: 노드의 AWS EBS 볼륨 유형입니다. 예를 들면 gp3입니다.
   • IOPS: 볼륨에 대해 초당 프로비저닝된 IO 작업량 (IOPS) 입니다. volumeType가 gp3일 때만 유효합니다.
   • NODE_VOLUME_KEY: 볼륨을 암호화하는 데 사용되는 AWS KMS 키의 ARN입니다. 자세한 내용은 고객 관리 CMK를 사용하여 볼륨 암호화를 참조하세요.

5. 관리 서비스에 매니페스트를 적용합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl apply -f custom-cluster.yaml
   env HTTPS_PROXY=http://localhost:8118 \
     kubectl apply -f custom-nodepools.yaml
   

   참고: 클러스터를 시작하는 데 몇 분 정도 걸립니다.

kubeconfig 만들기

사용자 클러스터를 시작할 때 새 사용자 클러스터의 kubeconfig 컨텍스트를 만들 수 있습니다. 컨텍스트를 사용하여 사용자 또는 관리자 클러스터에 인증합니다.

1. anthos-gke aws clusters get-credentials를 사용하여 ~/.kube/config의 사용자 클러스터에 대한 kubeconfig를 생성합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials CLUSTER_NAME
   

   CLUSTER_NAME을 클러스터 이름으로 바꿉니다. 예를 들면 cluster-0입니다.

2. kubectl을 사용하여 새 사용자 클러스터를 인증합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl cluster-info
   

   클러스터가 준비되면 클러스터에 있는 Kubernetes 구성요소에 대한 URL이 반환됩니다.

클러스터 상태 보기

AWSCluster 또는 AWSNodePool을 적용할 때 관리 서비스가 AWS 리소스를 프로비저닝합니다.

1. anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 관리 서비스로 전환합니다.

   cd anthos-aws
   anthos-gke aws management get-credentials

   참고: anthos-gke에서는 aws configure를 실행할 때 지정한 사용자 인증 정보를 사용합니다.

2. 클러스터를 나열하려면 kubectl get AWSClusters를 사용합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl get AWSClusters
   

   결과에는 각 클러스터의 이름, 상태, 사용 기간, 버전, 엔드포인트가 포함됩니다.

   예를 들어 다음 결과에는 cluster-0이라는 AWSCluster가 하나 포함되어 있습니다.

   NAME        STATE          AGE     VERSION         ENDPOINT
   cluster-0   Provisioning   2m41s   1.25.5-gke.2100   gke-xyz.elb.us-east-1.amazonaws.com
   

클러스터 이벤트 보기

사용자 클러스터에서 최근의 Kubernetes 이벤트를 보려면 kubectl get events를 사용합니다.

1. anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 관리 서비스로 전환합니다.

   cd anthos-aws
   anthos-gke aws management get-credentials

   참고: anthos-gke에서는 aws configure를 실행할 때 지정한 사용자 인증 정보를 사용합니다.

2. kubectl get events를 실행합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl get events
   

출력에는 관리 서비스의 정보, 경고, 오류가 포함됩니다.

워크로드 아이덴티티 웹훅 만들기

중요: 워크로드 아이덴티티 웹훅은 클러스터 버전 1.22 이상에서 지원되지 않습니다. 1.22로 업그레이드한 후에 웹훅을 사용하는 애플리케이션에서 사용자 인증 정보를 받지 못할 수 있습니다.

이 섹션은 클러스터 관리자를 위해 작성되었습니다.

추가 구성 없이 워크로드에 워크로드 아이덴티티 사용자 인증 정보를 제공하기 위해 사용자 클러스터에서 선택적으로 웹훅을 만들 수 있습니다. 이 웹훅은 pod 생성 요청을 가로채고 다음과 같은 AWS IAM 정보를 환경 변수로 pod에 제공합니다.

• AWS_ROLE_ARN: IAM 역할의 Amazon 리소스 이름(ARN)
• aws-iam-token: AWS IAM 사용자 인증 정보를 위해 교환되는 토큰
• AWS_WEB_IDENTITY_TOKEN_FILE: 토큰이 저장되는 경로

이러한 변수를 사용하면 워크로드가 AWS 명령줄 도구를 호출하거나 SDK가 AWS 역할에 부여된 리소스에 액세스할 수 있습니다.

웹훅을 만드는 것은 선택사항입니다. 웹훅을 만들지 않으려면 이전에 pod에 나열된 환경 변수를 설정해야 합니다. 웹훅을 사용하지 않는 방법에 대한 자세한 내용은 웹훅 없이 사용자 인증 정보 적용을 참조하세요.

웹훅의 YAML 파일 만들기

웹훅을 배포하려면 다음 단계를 수행합니다.

1. anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 관리 서비스로 전환합니다.

   cd anthos-aws
   anthos-gke aws management get-credentials

   참고: anthos-gke에서는 aws configure를 실행할 때 지정한 사용자 인증 정보를 사용합니다.

2. kubectl를 사용하여 사용자 클러스터 이름을 가져옵니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl get awscluster
   

   kubectl에는 모든 사용자 클러스터가 나열됩니다. 워크로드 아이덴티티를 사용 설정한 상태에서 생성한 사용자 클러스터를 선택합니다.

3. 환경 변수에 클러스터 이름을 설정합니다.

   CLUSTER_NAME=CLUSTER_NAME
   

   CLUSTER_NAME을 클러스터 이름으로 바꿉니다. 예를 들면 cluster-0입니다.

4. 워크로드 아이덴티티 pod 이미지 및 네임스페이스의 환경 변수를 설정합니다.

   IDENTITY_IMAGE=amazon/amazon-eks-pod-identity-webhook:ed8c41f
   
   WEBHOOK_NAMESPACE=workload-identity-webhook
   

5. 다음 단계를 수행하여 aws-webhook.yaml이라는 파일에 웹훅 YAML 매니페스트를 생성합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials ${CLUSTER_NAME}
   
   CLUSTER_CA=$(env HTTPS_PROXY=http://localhost:8118 \
     kubectl config view --raw -o json  | jq -r '.clusters[] | select(.name == "'$(kubectl config current-context)'") | .cluster."certificate-authority-data"')
   
   cat << EOF > aws-webhook.yaml
   apiVersion: v1
   kind: Namespace
   metadata:
     name: ${WEBHOOK_NAMESPACE}
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: pod-identity-webhook
     namespace: ${WEBHOOK_NAMESPACE}
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: pod-identity-webhook
     namespace: ${WEBHOOK_NAMESPACE}
   rules:
     - apiGroups: ['']
       resources: ['secrets']
       verbs: ['create']
     - apiGroups: ['']
       resources: ['secrets']
       verbs: ['get', 'update', 'patch']
       resourceNames:
         - pod-identity-webhook
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: pod-identity-webhook
     namespace: ${WEBHOOK_NAMESPACE}
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: pod-identity-webhook
   subjects:
     - kind: ServiceAccount
       name: pod-identity-webhook
       namespace: ${WEBHOOK_NAMESPACE}
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: pod-identity-webhook
   rules:
     - apiGroups: ['']
       resources: ['serviceaccounts']
       verbs: ['get', 'watch',  'list']
     - apiGroups:  ['certificates.k8s.io']
       resources: ['certificatesigningrequests']
       verbs:  ['create', 'get', 'list', 'watch']
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: pod-identity-webhook
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: pod-identity-webhook
   subjects:
     - kind: ServiceAccount
       name: pod-identity-webhook
       namespace: ${WEBHOOK_NAMESPACE}
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: pod-identity-webhook
     namespace: ${WEBHOOK_NAMESPACE}
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: pod-identity-webhook
     template:
       metadata:
         labels:
           app: pod-identity-webhook
       spec:
         serviceAccountName: pod-identity-webhook
         containers:
           - name: pod-identity-webhook
             image: ${IDENTITY_IMAGE}
             imagePullPolicy: Always
             command:
               - /webhook
               - --in-cluster
               - --namespace=${WEBHOOK_NAMESPACE}
               - --service-name=pod-identity-webhook
               - --tls-secret=pod-identity-webhook
               - --annotation-prefix=eks.amazonaws.com
               - --token-audience=sts.amazonaws.com
               - --logtostderr
             volumeMounts:
               - name: webhook-certs
                 mountPath: /var/run/app/certs
                 readOnly: false
         volumes:
           - name: webhook-certs
             emptyDir: {}
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: pod-identity-webhook
     namespace: ${WEBHOOK_NAMESPACE}
     annotations:
       prometheus.io/port: '443'
       prometheus.io/scheme: https
       prometheus.io/scrape: 'true'
   spec:
     ports:
       - port: 443
         targetPort: 443
     selector:
       app: pod-identity-webhook
   ---
   apiVersion: admissionregistration.k8s.io/v1
   kind: MutatingWebhookConfiguration
   metadata:
     name: pod-identity-webhook
     namespace: ${WEBHOOK_NAMESPACE}
   webhooks:
     - name: pod-identity-webhook.amazonaws.com
       failurePolicy: Ignore
       sideEffects: 'None'
       admissionReviewVersions: ['v1beta1']
       clientConfig:
         service:
           name: pod-identity-webhook
           namespace: ${WEBHOOK_NAMESPACE}
           path: /mutate
         caBundle: ${CLUSTER_CA}
       rules:
         - operations: ['CREATE']
           apiGroups: ['']
           apiVersions: ['v1']
           resources: ['pods']
   EOF
   

   aws-webhook.yaml의 콘텐츠를 클러스터에 적용할 준비가 되었습니다.

사용자 클러스터에 웹훅 적용

사용자 클러스터에 웹훅을 적용하려면 다음 단계를 수행하세요.

1. 사용자 클러스터에 aws-webhook.yaml 파일을 적용합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl apply -f aws-webhook.yaml
   

2. 매니페스트를 적용하면 웹훅 pod는 Kubernetes 인증서 서명 요청(CSR)을 생성합니다. kubectl certificate approve로 system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook의 모든 요청을 승인합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl certificate approve $(env HTTPS_PROXY=http://localhost:8118 \ &&\
     kubectl get csr -o \
       jsonpath="{.items[?(@.spec.username==\"system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook\")].metadata.name}")
   

3. 승인되지 않은 CSR이 없는지 확인합니다.

   kubectl get csr을 사용하여 요청자 system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook의 모든 CSR이 승인되었는지 확인합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl get csr
   

   응답:

   NAME        AGE   REQUESTOR                                            CONDITION
   csr-mxrt8   10s   system:serviceaccount:default:pod-identity-webhook   Approved,Issued
   

AWS OIDC 공급자 구성

이 섹션은 클러스터 관리자를 위해 작성되었습니다.

AWS에 OIDC 공급자를 생성하려면 AWS에 중간 인증 기관(CA) 또는 서버 인증서 단축키가 필요합니다. OIDC 검색 사용자 인증 정보는 storage.googleapis.com에서 GTS CA 1C3라는 이름의 중간 CA가 서명한 인증서로 저장됩니다. 중간 CA GTS CA 1C3의 SHA-1 지문은 08745487E891C19E3078C1F2A07E452950EF36F6입니다.

AWS를 사용하여 OIDC 검색 버킷을 OIDC 공급자로 등록하려면 다음 단계를 따르세요.

1. anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 관리 서비스로 전환합니다.

   cd anthos-aws
   anthos-gke aws management get-credentials

   참고: anthos-gke에서는 aws configure를 실행할 때 지정한 사용자 인증 정보를 사용합니다.

2. OIDC 발급기관 URL, 발급기관 호스트 경로, Cloud Storage 지문을 환경 변수에 저장하세요.

   ISSUER_URL=$(env HTTPS_PROXY=http://localhost:8118 \
     kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.workloadIdentityInfo.issuerURL}')
   ISSUER_HOSTPATH=${ISSUER_URL#"https://"}
   CA_THUMBPRINT=08745487E891C19E3078C1F2A07E452950EF36F6
   

3. aws 명령줄 도구를 사용하여 AWS에서 OIDC 공급자를 만듭니다.

   aws iam create-open-id-connect-provider \
     --url ${ISSUER_URL} \
     --thumbprint-list ${CA_THUMBPRINT} \
     --client-id-list sts.amazonaws.com
   

지문 업데이트

Google에서 storage.googleapis.com에 대해 CA를 순환하는 경우 다음 명령어를 실행합니다.

1. 업데이트된 인증서 지문 08745487E891C19E3078C1F2A07E452950EF36F6을 복사합니다.

2. aws iam update-open-id-connect-provider-thumbprint 명령어의 안내를 따릅니다. storage.googleapis.com을 대상 호스트 이름으로, 08745487E891C19E3078C1F2A07E452950EF36F6을 지문으로 사용합니다.

AWS IAM 역할 및 정책 만들기

이 섹션은 클러스터 관리자를 위해 작성되었습니다.

AWS IAM 역할을 만들어 Kubernetes 서비스 계정에 결합합니다. IAM 역할은 sts:AssumeRoleWithWebIdentity에 대한 권한이 있습니다.

역할을 만들려면 다음 단계를 수행하세요.

1. 워크로드에 필요한 권한을 부여하는 AWS IAM 정책을 찾거나 만듭니다.

   정책의 Amazon 리소스 이름(ARN) AWS IAM 정책이 필요합니다. 예를 들면 arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess입니다.

2. 인증 정보를 사용하여 환경 변수를 설정합니다.

   KSA_NAME=KUBERNETES_SERVICE_ACCOUNT
   WORKLOAD_NAMESPACE=WORKLOAD_IDENTITY_NAMESPACE
   
   AWS_ROLE_NAME=AWS_ROLE_NAME
   AWS_POLICY=EXISTING_AWS_POLICY
   

   다음을 바꿉니다.

   • KUBERNETES_SERVICE_ACCOUNT: 새 Kubernetes 서비스 계정의 이름
   • WORKLOAD_IDENTITY_NAMESPACE: 워크로드가 실행되는 네임스페이스 이름
   • AWS_ROLE_NAME: 워크로드의 새 AWS 역할 이름입니다.
   • EXISTING_AWS_POLICY: 기존 AWS IAM 정책의 Amazon 리소스 이름(ARN)입니다(예: arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess).

3. anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 관리 서비스로 전환합니다.

   cd anthos-aws
   anthos-gke aws management get-credentials

   참고: anthos-gke에서는 aws configure를 실행할 때 지정한 사용자 인증 정보를 사용합니다.

4. AWS 보안 토큰 서비스를 사용해 사용자 클러스터에서 임시 보안 사용자 인증 정보를 추정할 수 있는 AWS IAM 정책을 만듭니다.

   CLUSTER_ID=$(env HTTPS_PROXY=http://localhost:8118 \
     kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.clusterID}')
   
   # Get the ID Provider ARN
   PROVIDER_ARN=$(aws iam list-open-id-connect-providers  \
   | jq '.OpenIDConnectProviderList' \
   | jq ".[] | select(.Arn |  contains(\"${CLUSTER_ID}\"))"   \
   | jq  '.Arn' | tr -d '"')
   
   # Create AWS role and policy
   cat > irp-trust-policy.json << EOF
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "${PROVIDER_ARN}"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "${ISSUER_HOSTPATH}:sub": "system:serviceaccount:${WORKLOAD_NAMESPACE}:${KSA_NAME}"
           }
         }
       }
     ]
   }
   EOF
   

   참고: "Version": "2012-10-17" 값은 AWS 정책 스키마 버전입니다. 이 값은 변경하지 마세요.

5. 이 정책을 사용하여 AWS IAM 역할을 만들고 기존 정책을 역할에 연결하려면 다음 명령어를 수행합니다.

   aws iam create-role \
     --role-name ${AWS_ROLE_NAME} \
     --assume-role-policy-document file://irp-trust-policy.json
   aws iam update-assume-role-policy \
     --role-name ${AWS_ROLE_NAME} \
     --policy-document file://irp-trust-policy.json
   aws iam attach-role-policy \
     --role-name ${AWS_ROLE_NAME} \
     --policy-arn ${AWS_POLICY}
   

   aws 명령줄 도구에서 정책이 내 역할에 연결되었는지 확인합니다.

워크로드의 Kubernetes 서비스 계정 만들기

이 섹션은 개발자 또는 클러스터 관리자를 위해 작성되었습니다.

이전에 지정된 AWS IAM 역할에 결합되는 Kubernetes 서비스 계정을 만들려면 다음 단계를 수행합니다.

1. anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 사용자 클러스터로 전환합니다.

   cd anthos-aws
   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials CLUSTER_NAME

   CLUSTER_NAME을 사용자 클러스터 이름으로 바꿉니다.

2. 다음 명령어를 실행하여 Kubernetes 서비스 계정을 만듭니다.

   S3_ROLE_ARN=$(aws iam get-role \
     --role-name AWS_ROLE_NAME \
     --query Role.Arn --output text)
   
   cat << EOF  > k8s-service-account.yaml
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: ${KSA_NAME}
     namespace: WORKLOAD_IDENTITY_NAMESPACE
   EOF
   
   env HTTPS_PROXY=http://localhost:8118 \
   kubectl apply -f k8s-service-account.yaml
   
   env HTTPS_PROXY=http://localhost:8118 \
   kubectl annotate sa --namespace ${WORKLOAD_NAMESPACE} ${KSA_NAME} eks.amazonaws.com/role-arn=${S3_ROLE_ARN}
   

   다음을 바꿉니다.

   • AWS_ROLE_NAME: 워크로드에 적용할 AWS IAM 역할 이름
   • WORKLOAD_IDENTITY_NAMESPACE: 워크로드가 실행되는 네임스페이스 이름

pod에 사용자 인증 정보 적용

이 섹션은 개발자를 위해 작성되었습니다.

이 섹션에서는 워크로드 아이덴티티 웹훅을 배포했다고 가정합니다. 웹훅을 배포하지 않은 경우 웹훅 없이 사용자 인증 정보 적용으로 건너뜁니다.

웹훅을 사용하여 사용자 인증 정보 적용

이 섹션에서는 웹훅이 제공하는 사용자 인증 정보를 읽을 수 있도록 pod를 구성하는 방법을 설명합니다.

pod에 서비스 계정 추가

워크로드로 워크로드 아이덴티티를 사용하려면 Kubernetes 서비스 계정을 다음 필드에 추가합니다.

• 배포: spec.template.spec.serviceAccountName
• pod: spec.serviceAccount

다음 pod 매니페스트는 기본 CentOS 이미지를 시작하고 spec.serviceAccount 필드를 포함합니다.

apiVersion: v1
kind: Pod
metadata:
  name: sample-centos-pod
  namespace: WORKLOAD_IDENTITY_NAMESPACE
spec:
  containers:
  - command:
    - /bin/bash
    - -ec
    - while :; do echo '.'; sleep 500 ; done
    image: amazon/aws-cli
    name: centos
  serviceAccount: KUBERNETES_SERVICE_ACCOUNT

다음을 바꿉니다.

• WORKLOAD_IDENTITY_NAMESPACE: 워크로드가 실행되는 네임스페이스 이름
• KUBERNETES_SERVICE_ACCOUNT: 이전에 만든 Kubernetes 서비스 계정의 이름

pod에 환경 변수가 설정되었는지 확인

pod에 환경 변수가 설정되었는지 확인하려면 다음 명령어를 실행하여 pod 정보를 가져옵니다.

kubectl get pod --namespace WORKLOAD_IDENTITY_NAMESPACE POD_NAME -o yaml

다음을 바꿉니다.

• WORKLOAD_IDENTITY_NAMESPACE: 워크로드가 실행되는 네임스페이스 이름
• POD_NAME: 확인할 pod의 이름

출력에는 spec.containers.command.env의 환경 변수 값과 AWS IAM 토큰의 마운트 지점이 포함됩니다. 다음은 pod 매니페스트의 예시입니다.

apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  containers:
  - command:
    - /bin/bash
    - -ec
    - while :; do echo '.'; sleep 500 ; done
    env:
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::1234567890:role/my-example-workload-role-1
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    image: amazon/aws-cli
    imagePullPolicy: IfNotPresent
    name: centos
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: my-k8s-serviceaccount-token-d4nz4
      readOnly: true
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  serviceAccount: my-k8s-serviceaccount
  serviceAccountName: my-k8s-serviceaccount
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
  - name: my-k8s-serviceaccount-token-d4nz4
    secret:
      defaultMode: 420
      secretName: my-k8s-serviceaccount-token-d4nz4
   ...
status:
  ...

웹훅 없이 사용자 인증 정보 적용

워크로드 아이덴티티 웹훅을 배포하지 않으면 다음을 수행해야 합니다.

• 다음 환경 변수가 설정되었는지 확인

  • AWS_ROLE_ARN: IAM 역할의 Amazon 리소스 이름(ARN)
  • AWS_WEB_IDENTITY_TOKEN_FILE: 토큰이 저장되는 경로

• IAM 토큰(aws-iam-token)과 AWS IAM 역할과 연결된 서비스 계정의 마운트 지점을 만듭니다.

워크로드 아이덴티티에 대한 사용자 인증 정보로 pod 만들기

워크로드 아이덴티티에 필요한 사용자 인증 정보가 포함된 pod를 만들려면 다음 단계를 수행합니다.

1. 다음 pod 매니페스트를 sample-pod-no-webhook.yaml이라는 파일에 복사합니다. 구성에서 필요한 사용자 인증 정보가 포함된 기본 CentOS 이미지를 시작합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-centos-pod-no-webhook
     namespace: WORKLOAD_IDENTITY_NAMESPACE
   spec:
     containers:
     - command:
       - /bin/bash
       - -ec
       - while :; do echo '.'; sleep 500 ; done
       image: centos:7
       name: centos
       env:
       - name: AWS_ROLE_ARN
         value: IAM_ROLE_ARN
       - name: AWS_WEB_IDENTITY_TOKEN_FILE
         value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
       volumeMounts:
       - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
         name: aws-iam-token
         readOnly: true
     volumes:
     - name: aws-iam-token
       projected:
         defaultMode: 420
         sources:
         - serviceAccountToken:
             audience: sts.amazonaws.com
             expirationSeconds: 86400
             path: token
     serviceAccount: KUBERNETES_SERVICE_ACCOUNT
   

   다음을 바꿉니다.

   • WORKLOAD_IDENTITY_NAMESPACE: 워크로드가 실행되는 네임스페이스 이름
   • IAM_ROLE_ARN: pod에 부여된 IAM 역할의 ARN입니다. 예를 들면 arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess입니다.
   • KUBERNETES_SERVICE_ACCOUNT: 이전에 만든 Kubernetes 서비스 계정의 이름

2. kubectl을 사용하여 pod 매니페스트를 클러스터에 적용합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl apply -f sample-pod-no-webhook.yaml
   

pod가 AWS 리소스에 액세스할 수 있는지 확인

다음 절차는 pod가 워크로드 아이덴티티가 작동하는 데 필요한 사용자 인증 정보를 수신했는지 확인하는 방법을 설명합니다.

단계를 완료하려면 다음이 필요합니다.

• 컨테이너에 대한 bash 셸 액세스입니다. 대부분의 프로덕션 이미지에는 셸을 사용할 수 없습니다. 다음 예시에서는 이전 섹션에서 지정된 pod를 사용하여 AWS S3에 액세스하는 방법을 보여줍니다.

• AWS 명령줄 인터페이스를 다운로드하려면 pod가 인터넷에 대한 아웃바운드 액세스 권한이 있어야 합니다.

pod가 S3 버킷에 액세스할 수 있는지 확인하려면 다음 단계를 수행합니다.

1. kubectl exec를 사용하여 pod sample-centos-pod-no-webhook에서 대화형 bash 셸을 실행합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl exec -it --namespace ${WORKLOAD_NAMESPACE} sample-centos-pod-no-webhook -- bash
   

   터미널이 pod에서 bash 셸을 엽니다.

2. aws 도구를 사용하여 AWS IAM 권한 및 사용자 인증 정보를 확인합니다.

   aws sts assume-role-with-web-identity \
    --role-arn ${AWS_ROLE_ARN} \
    --role-session-name mh9test \
    --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token \
    --duration-seconds 1000
   

   aws 도구는 다음과 유사한 사용자 인증 정보 정보를 출력합니다.

   {
       "AssumedRoleUser": {
           "AssumedRoleId": "AROAR2ZZZLEXVSDCDJ37N:mh9test",
           "Arn": "arn:aws:sts::126285863215:assumed-role/my-example-workload-role-1/mh9test"
       },
       "Audience": "sts.amazonaws.com",
       "Provider": "arn:aws:iam::126285863215:oidc-provider/storage.googleapis.com/gke-issuer-cec6c353",
       "SubjectFromWebIdentityToken": "system:serviceaccount:default:my-s3-reader-ksa",
       "Credentials": {
           "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
           "SessionToken": "MY_TOKEN",
           "Expiration": "2020-08-14T22:46:36Z",
           "AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
       }
   }
   

   다음 메시지가 표시되면 버킷에 공개적으로 액세스할 수 있는지 확인하세요. An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements

웹훅 업그레이드

워크로드 아이덴티티가 사용 설정된 워크로드 아이덴티티 웹훅 버전 release-0.2.2-gke.0의 Kubernetes 1.18 이하 클러스터를 만든 경우 Kubernetes 1.19로 업그레이드하기 전에 웹훅을 업그레이드해야 합니다.

웹훅을 업그레이드하려면 다음 단계를 수행합니다.

1. 다음 명령어를 실행하여 웹훅이 설치되었는지 확인합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl get MutatingWebhookConfiguration
   

   클러스터에 웹훅이 배포되었으면 출력에 다음이 포함됩니다.

   NAME                   WEBHOOKS   AGE
   pod-identity-webhook   1          11m
   

   웹훅이 클러스터에 배포되지 않았으면 다음 단계를 건너뛸 수 있습니다.

2. aws-webhook.yaml 파일을 저장한 경우 매니페스트를 삭제할 수 있습니다. 이 파일을 사용할 수 없으면 웹훅의 구성요소를 수동으로 삭제할 수 있습니다. 아래 파일 또는 구성요소 중에서 선택합니다.

   파일

   아직 aws-webhook.yaml 파일이 있는 경우 다음 명령어를 실행하여 웹훅을 삭제합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl delete -f aws-webhook.yaml
   

   구성요소

   웹훅 구성요소를 수동으로 삭제하려면 다음 명령어를 실행합니다.

   env HTTPS_PROXY=http://localhost:8118 \
      kubectl delete namespace WEBHOOK_NAMESPACE
   env HTTPS_PROXY=http://localhost:8118 \
      kubectl delete clusterrole pod-identity-webhook
   env HTTPS_PROXY=http://localhost:8118 \
      kubectl delete clusterrolebinding pod-identity-webhook
   env HTTPS_PROXY=http://localhost:8118 \
      kubectl delete mutatingwebhookconfiguration pod-identity-webhook
   

   WEBHOOK_NAMESPACE를 워크로드 아이덴티티 웹훅을 설치한 네임스페이스로 바꿉니다. 예를 들면 workload-identity-webhook입니다.

3. 다음 명령어를 실행하여 인증서 서명 요청(CSR)이 남아 있는지 확인합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl get csr |grep pod-identity-webhook
   

   출력이 비어 있으면 다음 단계로 건너뜁니다. 남은 CSR이 있으면 kubectl 명령어가 기존 CSR을 계속 나열합니다. CSR을 삭제하려면 다음 명령어를 실행합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl delete csr $(kubectl get csr -o \
     jsonpath="{.items[?(@.spec.username==\"system:serviceaccount:WEBHOOK_NAMESPACE:pod-identity-webhook\")].metadata.name}")
   

   WEBHOOK_NAMESPACE를 워크로드 아이덴티티 웹훅을 설치한 네임스페이스로 바꿉니다. 예를 들면 workload-identity-webhook입니다.

4. 웹훅 만들기의 단계를 따라 새 웹훅 버전을 배포합니다.

   새 웹훅 버전을 배포한 후 웹훅을 사용하는 pod를 다시 시작해야 합니다. 사용자 클러스터를 업그레이드하면 pod를 다시 시작할 수 있습니다.

삭제

이 섹션에서는 이 문서에서 이전에 만든 리소스를 삭제하는 방법을 설명합니다.

서비스 계정 및 연결된 IAM 역할 삭제

서비스 계정 및 연결된 IAM 역할을 삭제하려면 다음 단계를 수행하세요.

1. 서비스 계정을 정리합니다.

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl delete sa KUBERNETES_SERVICE_ACCOUNT --namespace WORKLOAD_IDENTITY_NAMESPACE
   

   다음을 바꿉니다.

   • KUBERNETES_SERVICE_ACCOUNT: 새 Kubernetes 서비스 계정의 이름
   • WORKLOAD_IDENTITY_NAMESPACE: 워크로드가 실행되는 네임스페이스 이름

2. AWS IAM 역할을 삭제합니다. 다음 중 하나를 선택하세요.

   • AWS 콘솔을 사용하여 AWS IAM 역할을 삭제합니다.

   • 다음 명령어를 사용하여 AWS 명령줄 도구로 역할을 삭제합니다.

     aws iam  detach-role-policy \
       --role-name=${AWS_ROLE_NAME} \
       --policy-arn=${AWS_POLICY}
     aws iam delete-role --role-name=${AWS_ROLE_NAME}
     

사용자 클러스터 삭제

사용자 클러스터를 삭제하려면 Anthos clusters on AWS 제거를 수행하세요.

AWS OIDC 공급자 정리

사용자 클러스터가 삭제된 후 다음 bash 셸 명령어 또는 AWS 콘솔을 사용하여 AWS에서 OIDC 공급자를 등록 취소하고 삭제합니다.

1. anthos-aws 디렉터리에서 anthos-gke를 사용하여 컨텍스트를 관리 서비스로 전환합니다.

   cd anthos-aws
   anthos-gke aws management get-credentials

   참고: anthos-gke에서는 aws configure를 실행할 때 지정한 사용자 인증 정보를 사용합니다.

2. 다음 명령어를 사용하여 AWS 명령줄 도구로 역할을 삭제합니다.

   CLUSTER_ID=$(env HTTPS_PROXY=http://localhost:8118 \
     kubectl get awscluster ${CLUSTER_NAME} -o jsonpath='{.status.clusterID}')
   
   PROVIDER_ARN=$(aws iam list-open-id-connect-providers  \
   | jq '.OpenIDConnectProviderList' \
   | jq ".[] | select(.Arn |  contains(\"${CLUSTER_ID}\"))"   \
   | jq  '.Arn' | tr -d '"')
   
   aws iam delete-open-id-connect-provider \
     --open-id-connect-provider-arn=${PROVIDER_ARN}
   

   AWS OIDC 공급자가 삭제되었다는 확인 메시지가 표시됩니다.

다음 단계

• Anthos clusters on AWS가 워크로드 아이덴티티에 사용하는 AWS 서비스 계정용 IAM 역할(IRSA)에 대해 알아봅니다.
• Google Cloud에서 워크로드 아이덴티티 사용 알아보기