In diesem Thema wird beschrieben, wie Sie Workload Identity für Ihre Anthos-Cluster in AWS-Arbeitslasten (GKE on AWS) aktivieren, um ihren Zugriff auf AWS-Ressourcen zu steuern.
Informationen zur Verwendung von Workload Identity mit Google Cloud IAM-Konten (Identity and Access Management) zur Steuerung des Zugriffs auf GCP-Ressourcen finden Sie unter Workload Identity mit Google Cloud verwenden.
Überblick
Workload Identity verwendet AWS-IAM-Berechtigungen, um den Zugriff auf Cloud-Ressourcen zu steuern. Mit Workload Identity können Sie jeder Arbeitslast unterschiedliche IAM-Rollen zuweisen. Eine solche detaillierte Steuerung der Berechtigungen bietet die Möglichkeit, das Prinzip der geringsten Berechtigung anzuwenden. Ohne Workload Identity müssen Sie Ihren Anthos-Clustern auf AWS-Knoten AWS-IAM-Rollen zuweisen. Dadurch erhalten alle Arbeitslasten auf dem Knoten die gleichen Berechtigungen wie der Knoten selbst.
Um Workload Identity für Ihren Cluster zu aktivieren, führen Sie folgende Schritte aus. Die Schritte sind nach den Administratorrollen gruppiert, die sie ausführen.
Clusteradministrator
- Erstellen Sie einen Cloud Storage-Bucket zum Speichern von OIDC-Discovery-Daten.
- Erstellen Sie eine IAM-Rolle (Identity and Access Management), um aus diesem Bucket zu lesen.
- Erstellen Sie einen Nutzercluster mit aktiviertem Workload Identity.
- Erstellen Sie einen Webhook in Ihrem Cluster, der Anmeldedaten zur Arbeitslastidentität bei Pods auf die Erstellung anwendet. Wenn Sie den Webhook nicht verwenden möchten, können Sie Umgebungsvariablen manuell in Ihren Pods festlegen.
- Konfigurieren Sie den AWS-OIDC-Anbieter.
- Erstellen Sie AWS-IAM-Rollen und -Richtlinien.
- Erstellen Sie Kubernetes-Dienstkonten und binden Sie AWS-Richtlinien an diese Konten.
Vorbereitung
Für die Schritte in diesem Dokument ist Folgendes erforderlich:
- Anthos-Cluster im AWS-Verwaltungsdienst
Nutzercluster, auf denen eine Kubernetes-Version ausgeführt wird, die höher als 1.17.9 ist.
Die im Folgenden aufgeführten Berechtigungen und Tools.
Berechtigungen
Zum Erstellen eines Clusters mit aktiviertem Workload Identity benötigen Sie die folgenden Berechtigungen:
Google Cloud
- Erstellen Sie einen öffentlich lesbaren Cloud Storage-Bucket mit aktiviertem einheitlichen Zugriff auf Bucket-Ebene.
- Gewähren Sie Lese-/Schreibberechtigungen vom Typ
management-sa@PROJECT_NAME.iam.gserviceaccount.com
-für den Bucket.
AWS
- Erstellen Sie einen AWS-OIDC-Anbieter.
- Erstellen Sie AWS-IAM-Rollen.
Tools
Auf Ihrem lokalen Computer empfehlen wir, das jq
-Tool zu installieren.
OIDC-Discovery-Bucket erstellen
Dieser Abschnitt richtet sich an Clusteradministratoren.
Ihr Nutzercluster muss die OIDC-Discovery-Daten in einem öffentlich zugänglichen Cloud Storage-Bucket speichern. Der Bucket enthält die OIDC-Discovery-Konfiguration und öffentliche Schlüssel. AWS verwendet den Inhalt, um Anfragen von Ihren Nutzerclustern zu authentifizieren.
Der Bucket muss folgende Eigenschaften haben:
- Er muss öffentlich lesbar sein.
- Für ihn muss ein einheitlicher Zugriff auf Bucket-Ebene aktiviert sein.
Wenn Sie keinen Bucket mit diesen Eigenschaften haben, erstellen Sie ihn mit den folgenden gsutil
-Befehlen:
BUCKET=BUCKET_NAME
gsutil mb -b on gs://${BUCKET}
gsutil iam ch allUsers:objectViewer gs://${BUCKET}
Ersetzen Sie dabei BUCKET_NAME
durch den Namen des neuen Buckets.
Berechtigungen für das Verwaltungsdienstkonto gewähren
Das Identity and Access Management-Dienstkonto für die Anthos-Cluster im AWS-Verwaltungsdienst benötigt Berechtigungen zum Lesen und Schreiben von Objekten in diesen Bucket.
Gewähren Sie Ihrem Verwaltungsdienstkonto die Berechtigungen mit dem folgenden
gsutil
-Befehl:MANAGEMENT_SA=management-sa@PROJECT_NAME.iam.gserviceaccount.com gsutil iam ch serviceAccount:${MANAGEMENT_SA}:admin gs://${BUCKET}
Ersetzen Sie
PROJECT_NAME
durch Ihr Google Cloud-Projekt.Erstellen Sie eine neue IAM-Rolle mit Berechtigungen zum Verwalten dieses Buckets. Um die Rolle zu erstellen, speichern Sie zuerst die Rollendefinition in einer Datei, erstellen Sie dann die Rolle und binden Sie sie an Ihr Verwaltungsdienstkonto.
Führen Sie folgende Befehle aus, um diese Aufgaben abzuschliessen:
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
Ersetzen Sie
PROJECT_NAME
durch Ihr Google Cloud-Projekt.Das Google Cloud CLI bestätigt, dass die Richtlinienbindung erstellt wurde.
Nutzercluster erstellen
Dieser Abschnitt richtet sich an Clusteradministratoren.
Nutzercluster mit aktiviertem Workload Identity erstellen
Erstellen Sie einen Nutzercluster, der Details zu Ihrem OIDC-Discovery-Bucket enthält. Diese Informationen im Feld spec.controlPlane.workloadIdentity.oidcDiscoveryGCSBucket
Ihres AWSCluster
fest.
In diesem Beispiel erstellen Sie manuell einen Cluster aus den CRDs von AWSCluster
und AWSNodePool
.
Wechseln Sie in das Verzeichnis mit Ihrer Anthos Cluster auf AWS-Konfiguration. Sie haben dieses Verzeichnis bei der Installation des Verwaltungsdienstes erstellt.
cd anthos-aws
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Öffnen Sie einen Texteditor und kopieren Sie die folgende
AWSCluster
-Definition in eine Datei mit dem Namencustom-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
Dabei gilt:
- CLUSTER_NAME: Der Name Ihres Clusters.
AWS_REGION: AWS-Region, in der Ihr Cluster ausgeführt wird.
VPC_ID: ID der VPC, in der Ihr Cluster ausgeführt wird.
POD_ADDRESS_CIDR_BLOCKS: Bereich der IPv4-Adressen, der von den Pods des Clusters verwendet wird. Derzeit wird nur ein Bereich unterstützt. Der Bereich darf sich nicht mit Subnetzen überschneiden, die von Ihrem Netzwerk erreichbar sind. Sie können denselben Bereich für mehrere unterschiedliche AWSCluster-Objekte verwenden. Beispiel:
10.2.0.0/16
.SERVICE_ADDRESS_CIDR_BLOCKS: IPv4-Adressbereich, der von den Diensten des Clusters verwendet wird. Derzeit wird nur ein Bereich unterstützt. Der Bereich darf sich nicht mit Subnetzen überschneiden, die von Ihrem Netzwerk erreichbar sind. Sie können denselben Bereich für mehrere unterschiedliche AWSCluster-Objekte verwenden. Beispiel:
10.1.0.0/16
.SERVICE_LOAD_BALANCER_SUBNETS: Die Subnetz-IDs, in denen Anthos-Cluster in AWS öffentliche oder private Load-Balancer erstellen können.
CLUSTER_VERSION: Eine Kubernetes-Version, die von Anthos-Clustern in AWS unterstützt wird. Die neueste Version ist 1.25.5-gke.2100.
AWS_INSTANCE_TYPE: Ein unterstützter EC2-Instanztyp.
SSH_KEY_NAME: Ein AWS-EC2-Schlüsselpaar
CONTROL_PLANE_SUBNET_IDS: Die IDs der Subnetze in den Verfügbarkeitszonen, in denen Ihre Instanzen auf der Steuerungsebene ausgeführt werden.
CONTROL_PLANE_SECURITY_GROUPS: Eine securityGroupID, die während der Installation des Verwaltungsdiensts erstellt wurde. Sie können dies dadurch anpassen, dass Sie alle securityGroupIDs hinzufügen, die für die Verbindung mit der Steuerungsebene erforderlich sind.
CONTROL_PLANE_IAM_PROFILE: Der Name des AWS EC2-Instanzprofils, das den Replikaten der Steuerungsebene zugewiesen ist.
ROOT_VOLUME_SIZE ist die Größe in Gibibyte (GiB) der Root-Volumes auf der Steuerungsebene.
ROOT_VOLUME_TYPE durch den EBS-Volume-Typ. Beispiel:
gp3
ROOT_VOLUME_IOPS durch die Anzahl der bereitgestellten E/A-Vorgänge pro Sekunde (IOPS) für das Volume. Nur gültig, wenn
volumeType
GP3
ist. Weitere Informationen finden Sie unter SSD-Volumes für allgemeine Zwecke (gp3).ROOT_VOLUME_KEY durch den Amazon-Ressourcennamen des AWS-KMS-Schlüssels, der Ihre Root-Volumes auf der Steuerungsebene verschlüsselt.
ETCD_VOLUME_SIZE ist die Größe der von etcd verwendeten Volumes.
ETCD_VOLUME_TYPE durch den EBS-Volume-Typ. Beispiel:
gp3
ETCD_VOLUME_IOPS durch die Anzahl der bereitgestellten E/A-Vorgänge pro Sekunde (IOPS) für das Volume. Nur gültig, wenn
volumeType
gp3
ist. Weitere Informationen finden Sie unter SSD-Volumes für allgemeine Zwecke (gp3).ETCD_VOLUME_KEY durch den Amazon-Ressourcennamen des AWS-KMS-Schlüssels, mit dem die etcd-Daten-Volumes der Steuerungsebene verschlüsselt werden.
ARN_OF_KMS_KEY ist der AWS KMS-Schlüssel, der zum Verschlüsseln von Cluster-Secrets verwendet wird.
ANTHOS_CONNECT_NAME ist der Name der Connect-Mitgliedschaft, der für die Registrierung Ihres Clusters verwendet wird. Der Name der Mitgliedschaft muss eindeutig sein. Beispiel:
projects/YOUR_PROJECT/locations/global/memberships/CLUSTER_NAME
, wobeiYOUR_PROJECT
Ihr Google Cloud-Projekt undCLUSTER_NAME
ein eindeutiger Name in Ihrem Projekt ist. Dieses Feld ist optional.YOUR_PROJECT ist Ihre Projekt-ID.
GCP_REGION: Die Google Cloud-Region, in der Sie Logs speichern möchten. Wählen Sie eine Region in der Nähe der AWS-Region aus. Weitere Informationen finden Sie unter Globale Standorte: Regionen und Zonen, z. B.
us-central1
.ENABLE_LOGGING:
true
oderfalse
, abhängig davon, ob Cloud Logging auf Knoten der Steuerungsebene aktiviert ist.ENABLE_MONITORING:
true
oderfalse
, abhängig davon, ob Cloud Monitoring auf Knoten der Steuerungsebene aktiviert ist.WORKLOAD_IDENTITY_BUCKET ist der Name des Cloud Storage-Buckets mit den Workload Identity-Erkennungsinformationen. Dieses Feld ist optional.
Erstellen Sie einen oder mehrere AWSNodePools für Ihren Cluster. Öffnen Sie einen Texteditor und kopieren Sie die folgende AWSCluster-Definition in eine Datei mit dem Namen
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
Dabei gilt:
- NODE_POOL_NAME ist ein eindeutiger Name für Ihren AWSNodePool.
- AWSCLUSTER_NAME ist der Name Ihres AWSClusters. Beispiel:
staging-cluster
- CLUSTER_VERSION ist eine unterstützte Version von Anthos-Clustern auf AWS Kubernetes.
- AWS_REGION ist die gleiche AWS-Region wie für Ihren AWS-Cluster.
- AWS_SUBNET_ID: AWS-Subnetz, das sich in derselben Region wie Ihr AWS-Cluster befindet.
- MINIMUM_NODE_COUNT ist die maximale Anzahl von Knoten im Knotenpool. Weitere Informationen finden Sie unter Nutzercluster skalieren.
- MAXIMUM_NODE_COUNT: Die maximale Anzahl von Knoten im Knotenpool.
- MAXIMUM_PODS_PER_NODE_COUNT: ist die maximale Anzahl von Pods, die Anthos-Cluster in AWS einem Knoten zuweisen können.
- AWS_NODE_TYPE ist ein AWS EC2-Instanztyp.
- KMS_KEY_PAIR_NAME ist das AWS KMS-Schlüsselpaar, das jedem Knotenpool-Worker zugewiesen wurde.
- NODE_IAM_PROFILE ist der Name des AWS EC2-Instanzprofils, das Knoten im Pool zugewiesen wurde.
- ROOT_VOLUME_SIZE ist die Größe in Gibibyte (GiB) der Root-Volumes auf der Steuerungsebene.
- VOLUME_TYPE ist der AWS-EBS-Volume-Typ des Knotens.
Beispiel:
gp3
- IOPS ist die Menge der bereitgestellten E/A-Vorgänge pro Sekunde (IOPS) für Volumes. Nur gültig, wenn
volumeType
gp3
ist. - NODE_VOLUME_KEY ist der ARN des AWS-KMS-Schlüssels, der zum Verschlüsseln des Volumes verwendet wird. Weitere Informationen finden Sie unter Vom Kunden verwalteten CMK zum Verschlüsseln von Volumes verwenden.
Wenden Sie die Manifeste auf Ihren Verwaltungsdienst an.
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 erstellen
Während Ihr Nutzercluster gestartet wird, können Sie einen kubeconfig
-Kontext für Ihren neuen Nutzercluster erstellen. Sie verwenden den Kontext, um sich bei einem Nutzer- oder Verwaltungscluster zu authentifizieren.
Verwenden Sie
anthos-gke aws clusters get-credentials
, um einenkubeconfig
für Ihren Nutzercluster in~/.kube/config
zu generieren.env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Ersetzen Sie dabei CLUSTER_NAME durch den Namen Ihres Clusters. Beispiel:
cluster-0
.Verwenden Sie
kubectl
, um sich beim neuen Nutzercluster zu authentifizieren.env HTTPS_PROXY=http://localhost:8118 \ kubectl cluster-info
Wenn Ihr Cluster bereit ist, enthält die Ausgabe die URLs für Kubernetes-Komponenten in Ihrem Cluster.
Status des Clusters ansehen
Der Verwaltungsdienst stellt AWS-Ressourcen bereit, wenn Sie AWSCluster
oder AWSNodePool
anwenden.
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Verwenden Sie
kubectl get AWSClusters
, um Ihre Cluster aufzulisten.env HTTPS_PROXY=http://localhost:8118 \ kubectl get AWSClusters
Die Ausgabe enthält den Namen, den Status, das Alter, die Version und den Endpunkt jedes Clusters.
Die folgende Ausgabe enthält beispielsweise nur einen
AWSCluster
mit dem Namencluster-0
:NAME STATE AGE VERSION ENDPOINT cluster-0 Provisioning 2m41s 1.25.5-gke.2100 gke-xyz.elb.us-east-1.amazonaws.com
Cluster-Ereignisse abrufen
Verwenden Sie kubectl get events
, um aktuelle Kubernetes-Ereignisse aus Ihrem Nutzercluster aufzurufen.
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Führen Sie
kubectl get events
aus.env HTTPS_PROXY=http://localhost:8118 \ kubectl get events
Die Ausgabe enthält Informationen, Warnungen und Fehler in Verbindung mit Ihrem Verwaltungsdienst.
Workload Identity-Webhook erstellen
Dieser Abschnitt richtet sich an Clusteradministratoren.
Wenn Sie für Ihre Arbeitslasten Workload Identity-Anmeldedaten ohne zusätzliche Konfiguration bereitstellen möchten, können Sie optional einen Webhook für Ihre Nutzercluster erstellen. Dieser Webhook fängt Anfragen zur Pod-Erstellung ab und legt die folgenden AWS-IAM-Informationen als Umgebungsvariablen fest:
AWS_ROLE_ARN
ist der Amazon-Ressourcenname (ARN) der IAM-Rolle.aws-iam-token
ist das Token, das für AWS-IAM-Anmeldedaten ausgetauscht wird.AWS_WEB_IDENTITY_TOKEN_FILE
ist der Pfad, unter dem das Token gespeichert wird.
Mit diesen Variablen können Ihre Arbeitslasten das AWS-Befehlszeilentool aufrufen; weiter kann auch das SDK auf die Ressourcen zugreifen, die der AWS-Rolle zugewiesen sind.
Das Erstellen des Webhooks ist optional. Wenn Sie den Webhook nicht erstellen möchten, müssen Sie die zuvor im Pod aufgelisteten Umgebungsvariablen festlegen. Informationen zur Verwendung von Anmeldedaten ohne Webhook finden Sie unter Anmeldedaten ohne Webhook anwenden.
YAML-Dateien für den Webhook erstellen
Um den Webhook bereitzustellen, führen Sie folgende Schritte aus:
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Rufen Sie den Namen des Nutzerclusters mit
kubectl
ab:env HTTPS_PROXY=http://localhost:8118 \ kubectl get awscluster
kubectl
listet alle Ihre Nutzercluster auf. Wählen Sie den von Ihnen erstellten Nutzercluster mit aktiviertem Workload Identity aus.Geben Sie den Namen des Clusters in einer Umgebungsvariablen an.
CLUSTER_NAME=CLUSTER_NAME
Ersetzen Sie
CLUSTER_NAME
durch den Namen Ihres Clusters. Beispiel:cluster-0
Legen Sie Umgebungsvariablen für das Pod-Image und den Namespace von Workload Identity fest.
IDENTITY_IMAGE=amazon/amazon-eks-pod-identity-webhook:ed8c41f WEBHOOK_NAMESPACE=workload-identity-webhook
Generieren Sie das Webhook-YAML-Manifest in einer Datei mit dem Namen
aws-webhook.yaml
. Führen Sie dazu folgende Schritte aus: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
Der Inhalt von
aws-webhook.yaml
kann jetzt auf Ihren Cluster angewendet werden.
Webhook auf den Nutzercluster anwenden
Um den Webhook auf Ihren Nutzercluster anzuwenden, führen Sie die im Folgenden aufgeführten Schritte aus.
Wenden Sie die Datei
aws-webhook.yaml
auf Ihren Nutzercluster an.env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f aws-webhook.yaml
Wenn Sie das Manifest anwenden, generiert der Webhook-Pod Kubernetes-Anfragen zur Signierung von Zertifikaten (Certificate Signing Requests, CSR). Genehmigen Sie alle Anfragen von
system:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook
mitkubectl certificate approve
.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}")
Prüfen Sie, ob es noch nicht genehmigte CSRs gibt.
Prüfen Sie mit
kubectl get csr
, ob alle CSRs vom Sendersystem:serviceaccount:${WEBHOOK_NAMESPACE}:pod-identity-webhook
der Anfrage genehmigt wurden:env HTTPS_PROXY=http://localhost:8118 \ kubectl get csr
Antwort
NAME AGE REQUESTOR CONDITION csr-mxrt8 10s system:serviceaccount:default:pod-identity-webhook Approved,Issued
AWS-OIDC-Anbieter konfigurieren
Dieser Abschnitt richtet sich an Clusteradministratoren.
Zum Erstellen eines OIDC-Anbieters für AWS benötigt AWS ein Zwischenzertifikat der Zertifizierungsstelle (Certificate Authority, CA) oder den Fingerabdruck eines Serverzertifikats. Ihre OIDC-Discovery-Anmeldedaten werden unter storage.googleapis.com
mit einem Zertifikat gespeichert, das von einer Zwischen-CA mit dem Namen GTS CA 1C3
signiert ist. Der SHA-1-Fingerabdruck des CA-Zwischenzertifikats GTS CA 1C3
ist 08745487E891C19E3078C1F2A07E452950EF36F6
.
Um Ihren OIDC-Discovery-Bucket als OIDC-Anbieter bei AWS zu registrieren, führen Sie die folgenden Schritte aus:
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Speichern Sie die OIDC-Aussteller-URL, den Hostpfad des Ausstellers und den Cloud Storage-Fingerabdruck in Umgebungsvariablen.
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
Verwenden Sie das
aws
-Befehlszeilentool, um einen OIDC-Anbieter in AWS zu erstellen.aws iam create-open-id-connect-provider \ --url ${ISSUER_URL} \ --thumbprint-list ${CA_THUMBPRINT} \ --client-id-list sts.amazonaws.com
Fingerabdruck aktualisieren
Wenn Google die CA für storage.googleapis.com
rotiert, führen Sie die folgenden Befehle aus:
Kopieren Sie den aktualisierten Zertifikat-Fingerabdruck
08745487E891C19E3078C1F2A07E452950EF36F6
.Folgen Sie der Anleitung für den Befehl
aws iam update-open-id-connect-provider-thumbprint
. Verwenden Siestorage.googleapis.com
als Zielhostnamen und08745487E891C19E3078C1F2A07E452950EF36F6
als Fingerabdruck.
AWS-IAM-Rollen und -Richtlinien erstellen
Dieser Abschnitt richtet sich an Clusteradministratoren.
Erstellen Sie eine AWS-IAM-Rolle, um sie an ein Kubernetes-Dienstkonto zu binden. Die IAM-Rolle hat Berechtigungen für sts:AssumeRoleWithWebIdentity
.
Führen Sie zum Erstellen der Rolle die folgenden Schritte aus:
Suchen oder erstellen Sie eine AWS-IAM-Richtlinie, die die erforderlichen Berechtigungen für Ihre Arbeitslasten gewährt.
Sie benötigen den Amazon-Ressourcennamens (ARN) der AWS-IAM-Richtlinie. Beispiel:
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
.Legen Sie Umgebungsvariablen mit Ihren Authentifizierungsinformationen fest.
KSA_NAME=KUBERNETES_SERVICE_ACCOUNT WORKLOAD_NAMESPACE=WORKLOAD_IDENTITY_NAMESPACE AWS_ROLE_NAME=AWS_ROLE_NAME AWS_POLICY=EXISTING_AWS_POLICY
Dabei gilt:
- KUBERNETES_SERVICE_ACCOUNT ist der Name des neuen Kubernetes-Dienstkontos.
- WORKLOAD_IDENTITY_NAMESPACE ist der Name des Namespace, in dem Arbeitslasten ausgeführt werden.
- AWS_ROLE_NAME ist der Name einer neuen AWS-Rolle für Ihre Arbeitslasten
- EXISTING_AWS_POLICY ist der Amazon-Ressourcenname (ARN) einer vorhandenen AWS IAM-Richtlinie, z. B.
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
.
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Erstellen Sie eine AWS IAM-Richtlinie, die es Ihrem Nutzercluster ermöglicht, vorläufige Sicherheitsanmeldedaten mit dem AWS Security Token Service zu akzeptieren:
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
Führen Sie die folgenden Befehle aus, um eine AWS IAM-Rolle mit dieser Richtlinie zu erstellen und Ihre vorhandene Richtlinie an die Rolle anzuhängen:
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}
Das
aws
-Befehlszeilentool bestätigt, dass die Richtlinie mit Ihrer Rolle verknüpft ist.
Kubernetes-Dienstkonten für Arbeitslasten erstellen
Dieser Abschnitt richtet sich an Entwickler oder Clusteradministratoren.
Um Kubernetes-Dienstkonten zu erstellen, die an die zuvor angegebene AWS-IAM-Rolle gebunden werden, führen Sie die folgenden Schritte aus:
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Nutzercluster zu wechseln.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Ersetzen Sie CLUSTER_NAME durch den Nutzerclusternamen.Erstellen Sie das Kubernetes-Dienstkonto durch Ausführen der folgenden Befehle:
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}
Dabei gilt:
AWS_ROLE_NAME
ist der Name der AWS-IAM-Rolle, die auf Arbeitslasten angewendet werden soll.WORKLOAD_IDENTITY_NAMESPACE
ist der Name des Namespace, in dem Arbeitslasten ausgeführt werden.
Anmeldedaten auf Pods anwenden
Dieser Abschnitt richtet sich an Entwickler.
In diesem Abschnitt wird davon ausgegangen, dass Sie den Webhook von Workload Identity bereitgestellt haben. Wenn Sie den Webhook noch nicht bereitgestellt haben, fahren Sie mit Anmeldedaten ohne Webhook anwenden fort.
Anmeldedaten mit dem Webhook anwenden
In diesem Abschnitt wird gezeigt, wie Sie Ihre Pods konfigurieren, damit die vom Webhook verfügbaren Anmeldedaten gelesen werden können.
Dienstkonto zum Pod hinzufügen
Zur Verwendung von Workload Identity mit einer Arbeitslast fügen Sie den folgenden Feldern das Kubernetes-Dienstkonto hinzu:
- Für eine Bereitstellung:
spec.template.spec.serviceAccountName
- Für einen Pod:
spec.serviceAccount
Das folgende Pod-Manifest startet ein Basis-CentOS-Image und enthält das Feld 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
Dabei gilt:
WORKLOAD_IDENTITY_NAMESPACE
ist der Name des Namespace, in dem Arbeitslasten ausgeführt werden.KUBERNETES_SERVICE_ACCOUNT
ist der Name des Kubernetes-Dienstkontos, das Sie zuvor erstellt haben.
Pods auf festgelegte Umgebungsvariablen prüfen
Um zu prüfen, ob für Pods die Umgebungsvariablen festgelegt sind, rufen Sie mit folgendem Befehl die Informationen zum Pod ab:
kubectl get pod --namespace WORKLOAD_IDENTITY_NAMESPACE POD_NAME -o yaml
Dabei gilt:
WORKLOAD_IDENTITY_NAMESPACE
ist der Name des Namespace, in dem Arbeitslasten ausgeführt werden.POD_NAME
ist der Name des Pods, der geprüft werden soll.
Die Ausgabe enthält die Werte der Umgebungsvariablen in spec.containers.command.env
und den Bereitstellungspunkt für das AWS-IAM-Token. Im Folgenden finden Sie ein Beispiel für ein Pod-Manifest.
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:
...
Anmeldedaten ohne Webhook anwenden
Wenn Sie den Webhook von Workload Identity nicht bereitstellen, gehen Sie so vor:
Prüfen Sie, ob die folgenden Umgebungsvariablen festgelegt sind:
AWS_ROLE_ARN
ist der Amazon-Ressourcenname (ARN) der IAM-Rolle.AWS_WEB_IDENTITY_TOKEN_FILE
ist der Pfad, unter dem das Token gespeichert wird.
Erstellen Sie einen Bereitstellungspunkt für das IAM-Token (
aws-iam-token
) und das mit der AWS-IAM-Rolle verknüpfte Dienstkonto.
Pod mit Anmeldedaten für Workload Identity erstellen
Um einen Pod zu erstellen, der die erforderlichen Anmeldedaten für Workload Identity enthält, führen Sie folgende Schritte aus:
Kopieren Sie das unten aufgeführte Pod-Manifest in eine Datei mit dem Namen
sample-pod-no-webhook.yaml
. Die Konfiguration legt fest, dass ein Basis-CentOS-Image mit den erforderlichen Anmeldedaten gestartet wird.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
Dabei gilt:
WORKLOAD_IDENTITY_NAMESPACE
ist der Name des Namespace, in dem Arbeitslasten ausgeführt werden.IAM_ROLE_ARN
ist des ARN der IAM-Rolle, die dem Pod zugewiesen ist. Beispiel:arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
.KUBERNETES_SERVICE_ACCOUNT
ist der Name des Kubernetes-Dienstkontos, das Sie zuvor erstellt haben.
Wenden Sie das Pod-Manifest mithilfe von
kubectl
auf Ihren Cluster an:env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f sample-pod-no-webhook.yaml
Pods auf Zugriff auf AWS-Ressourcen prüfen
Im Folgenden wird gezeigt, wie Sie prüfen, ob der Pod die Anmeldedaten erhalten hat, die für ein funktionsfähiges Workload Identity erforderlich sind.
Um die erforderlichen Schritte auszuführen, benötigen Sie Folgendes:
bash
-Shell-Zugriff auf den Container. Für die meisten Produktions-Images ist keine Shell verfügbar. Das folgende Beispiel zeigt, wie Sie mit dem im vorherigen Abschnitt angegebenen Pod auf AWS S3 zugreifen.Der Pod muss ausgehenden Internetzugriff haben, damit die AWS-Befehlszeile heruntergeladen werden kann.
Um zu prüfen, ob der Pod auf einen S3-Bucket zugreifen kann, führen Sie die folgenden Schritte aus:
Starten Sie mit
kubectl exec
eine interaktive Bash-Shell auf dem Podsample-centos-pod-no-webhook
:env HTTPS_PROXY=http://localhost:8118 \ kubectl exec -it --namespace ${WORKLOAD_NAMESPACE} sample-centos-pod-no-webhook -- bash
Ihr Terminal öffnet die Bash-Shell auf dem Pod.
Prüfen Sie die AWS-IAM-Berechtigungen und Anmeldedaten mit dem
aws
-Tool: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
Das
aws
-Tool gibt dann Anmeldedaten ähnlich der folgenden aus:{ "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" } }
Wenn die folgende Meldung angezeigt wird, prüfen Sie, ob der Bucket öffentlich zugänglich ist:
An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements
Webhook aktualisieren
Wenn Sie einen Kubernetes Cluster der Version 1.18 oder niedriger erstellt haben, bei dem Workload Identity aktiviert und der Workload Identity-Webhook der Version release-0.2.2-gke.0
installiert ist, müssen Sie den Webhook vor dem Upgrade auf Kubernetes 1.19 aktualisieren.
Um den Webhook zu aktualisieren, führen Sie folgende Schritte aus:
Prüfen Sie mit den folgenden Befehlen, ob der Webhook installiert ist:
env HTTPS_PROXY=http://localhost:8118 \ kubectl get MutatingWebhookConfiguration
Wenn der Webhook im Cluster bereitgestellt ist, enthält die Ausgabe Folgendes:
NAME WEBHOOKS AGE pod-identity-webhook 1 11m
Wenn der Webhook nicht im Cluster bereitgestellt ist, können Sie die folgenden Schritte überspringen.
Wenn Sie die Datei
aws-webhook.yaml
gespeichert haben, können Sie das Manifest löschen. Wenn Sie diese Datei nicht zur Verfügung haben, können Sie die Komponenten des Webhooks manuell löschen. Wählen Sie unten eine Datei oder eine Komponente aus.Datei
Wenn Sie noch die Datei
aws-webhook.yaml
haben, führen Sie den folgenden Befehl aus, um den Webhook zu löschen:env HTTPS_PROXY=http://localhost:8118 \ kubectl delete -f aws-webhook.yaml
Komponenten
Führen Sie die folgenden Befehle aus, um die Komponenten des Webhooks manuell zu löschen:
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
Ersetzen Sie WEBHOOK_NAMESPACE durch den Namespace, in dem Sie den Workload Identity-Webhook installiert haben. Beispiel:
workload-identity-webhook
.Prüfen Sie mit dem folgenden Befehl, ob noch CSR-Anfragen (Certificate Signing Requests) vorhanden sind:
env HTTPS_PROXY=http://localhost:8118 \ kubectl get csr |grep pod-identity-webhook
Wenn die Ausgabe leer ist, fahren Sie mit dem nächsten Schritt fort. Wenn noch CSRs vorhanden sind, werden diese mit dem Befehl
kubectl
aufgelistet. Führen Sie den folgenden Befehl aus, um die CSRs zu entfernen: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}")
Ersetzen Sie WEBHOOK_NAMESPACE durch den Namespace, in dem Sie den Workload Identity-Webhook installiert haben. Beispiel:
workload-identity-webhook
.Führen Sie die Schritte unter Webhook erstellen aus, um die neue Webhook-Version bereitzustellen.
Nachdem Sie die neue Webhook-Version bereitgestellt haben, müssen Sie die Pods, die den Webhook verwenden neu starten. Sie können die Pods neu starten, indem Sie einen Nutzercluster upgraden.
Bereinigen
In diesem Abschnitt erfahren Sie, wie Sie Ressourcen entfernen, die Sie zuvor in diesem Dokument erstellt haben.
Dienstkonto und zugehörige IAM-Rolle bereinigen
Um das Dienstkonto und die zugehörige IAM-Rolle zu löschen, führen Sie die folgenden Schritte aus:
Bereinigen Sie das Dienstkonto:
env HTTPS_PROXY=http://localhost:8118 \ kubectl delete sa KUBERNETES_SERVICE_ACCOUNT --namespace WORKLOAD_IDENTITY_NAMESPACE
Dabei gilt:
KUBERNETES_SERVICE_ACCOUNT
ist der Name des neuen Kubernetes-Dienstkontos.WORKLOAD_IDENTITY_NAMESPACE
ist der Name des Namespace, in dem Arbeitslasten ausgeführt werden.
Bereinigen Sie die AWS-IAM-Rolle. Wählen Sie eine der folgenden Optionen aus:
Löschen Sie die AWS-IAM-Rolle mit der AWS-Konsole.
Löschen Sie die Rolle mit dem AWS-Befehlszeilentool mit den folgenden Befehlen:
aws iam detach-role-policy \ --role-name=${AWS_ROLE_NAME} \ --policy-arn=${AWS_POLICY} aws iam delete-role --role-name=${AWS_ROLE_NAME}
Nutzercluster löschen
Führen Sie die Schritte unter Anthos-Cluster in AWS deinstallieren aus, um Ihren Nutzercluster zu löschen.
AWS-OIDC-Anbieter bereinigen
Nachdem der Nutzercluster gelöscht wurde, heben Sie die Registrierung des OIDC-Anbieters in AWS auf und löschen ihn mit dem folgenden bash
-Shell-Befehl oder der AWS-Konsole.
Verwenden Sie
anthos-gke
im Verzeichnisanthos-aws
, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln.cd anthos-aws anthos-gke aws management get-credentials
Löschen Sie die Rolle mit dem AWS-Befehlszeilentool mit den folgenden Befehlen:
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}
Sie erhalten dann eine Bestätigung, dass der AWS-OIDC-Anbieter gelöscht wurde.
Nächste Schritte
- Mehr über AWS-IAM-Rollen für Dienstkonten (IRSA) erfahren, die Anthos-Cluster in AWS für die Arbeitslastidentität verwenden
- Informationen zur Verwendung von Workload Identity mit Google Cloud.