Workload Identity mit AWS verwenden

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

  1. Erstellen Sie einen Cloud Storage-Bucket zum Speichern von OIDC-Discovery-Daten.
  2. Erstellen Sie eine IAM-Rolle (Identity and Access Management), um aus diesem Bucket zu lesen.
  3. Erstellen Sie einen Nutzercluster mit aktiviertem Workload Identity.
  4. 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.
  5. Konfigurieren Sie den AWS-OIDC-Anbieter.
  6. Erstellen Sie AWS-IAM-Rollen und -Richtlinien.
Clusteradministrator oder -entwickler
  1. Erstellen Sie Kubernetes-Dienstkonten und binden Sie AWS-Richtlinien an diese Konten.
Entwickler
  1. Wenden Sie Anmeldedaten auf Ihre Pods an.

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:

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.

  1. 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.

  2. 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.

  1. 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

  2. Verwenden Sie anthos-gke im Verzeichnis anthos-aws, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln. 

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

  3. Öffnen Sie einen Texteditor und kopieren Sie die folgende AWSCluster-Definition in eine Datei mit dem Namen 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

    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, wobei YOUR_PROJECT Ihr Google Cloud-Projekt und CLUSTER_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 oder false, abhängig davon, ob Cloud Logging auf Knoten der Steuerungsebene aktiviert ist.

    • ENABLE_MONITORING: true oder false, 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.

  4. 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.

  5. 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.

  1. Verwenden Sie anthos-gke aws clusters get-credentials, um einen kubeconfig 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.

  2. 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.

  1. Verwenden Sie anthos-gke im Verzeichnis anthos-aws, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln. 

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

  2. 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 Namen cluster-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.

  1. Verwenden Sie anthos-gke im Verzeichnis anthos-aws, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln. 

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

  2. 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:

  1. Verwenden Sie anthos-gke im Verzeichnis anthos-aws, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln. 

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

  2. 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.

  3. 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

  4. 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

  5. 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.

  1. Wenden Sie die Datei aws-webhook.yaml auf Ihren Nutzercluster an.

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

  2. 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 mit kubectl 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}")

  3. Prüfen Sie, ob es noch nicht genehmigte CSRs gibt.

    Prüfen Sie mit kubectl get csr, ob alle CSRs vom Sender system: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:

  1. Verwenden Sie anthos-gke im Verzeichnis anthos-aws, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln. 

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

  2. 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

  3. 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:

  1. Kopieren Sie den aktualisierten Zertifikat-Fingerabdruck 08745487E891C19E3078C1F2A07E452950EF36F6.

  2. Folgen Sie der Anleitung für den Befehl aws iam update-open-id-connect-provider-thumbprint. Verwenden Sie storage.googleapis.com als Zielhostnamen und 08745487E891C19E3078C1F2A07E452950EF36F6 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:

  1. 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.

  2. 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.

  3. Verwenden Sie anthos-gke im Verzeichnis anthos-aws, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln. 

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

  4. 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

  5. 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:

  1. Verwenden Sie anthos-gke im Verzeichnis anthos-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.

  2. 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:

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:

  1. 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.

  2. 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:

  1. Starten Sie mit kubectl exec eine interaktive Bash-Shell auf dem Pod sample-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.

  2. 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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:

  1. 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.

  2. 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.

  1. Verwenden Sie anthos-gke im Verzeichnis anthos-aws, um den Kontext zu Ihrem Verwaltungsdienst zu wechseln. 

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

  2. 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