Diese Dokumentation bezieht sich auf die aktuelle Version von GKE on AWS, die im November 2021 veröffentlicht wurde. Weitere Informationen finden Sie in den Versionshinweisen.

Diese Seite wurde von der Cloud Translation API übersetzt.

Workload Identity mit AWS verwenden

Mit Workload Identity können Sie jeder Anwendung in Ihrem Cluster separate, detaillierte Identitäten und Autorisierungen zuweisen. Workload Identity ist die empfohlene Methode für Anwendungen, die in GKE on AWS ausgeführt werden, um auf AWS- und Google Cloud-Dienste zuzugreifen. Weitere Informationen finden Sie unter Workload Identity.

In diesem Thema wird erläutert, wie Sie einen OIDC-Anbieter erstellen, Dienstkonten bereitstellen und eine Beispielarbeitslast mit Workload Identity testen.

AWS IAM-OIDC-Anbieter für den Cluster erstellen

Zur Verwendung von Workload Identity mit Ihrem Cluster erstellen Sie zuerst einen AWS IAM-OIDC-Anbieter, der auf Ihren Cluster verweist. Wenn Sie bereits einen IAM-OIDC-Anbieter für Ihren Cluster haben, können Sie diesen Abschnitt überspringen.

So erstellen Sie den Anbieter:

Bestimmen Sie den OIDC-Aussteller-URI für Ihren Cluster:
```
gcloud container aws clusters describe CLUSTER_NAME \
     --location=GOOGLE_CLOUD_LOCATION \
     --format='value(workloadIdentityConfig.issuerUri)'
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name Ihres Clusters
- GOOGLE_CLOUD_LOCATION: der Name des Google Cloud-Standorts, von dem dieser Knotenpool verwaltet werden soll, wie in Google Cloud-Verwaltungsregionen definiert
Die Ausgabe enthält den OIDC-Aussteller-URI Ihres Clusters. Speichern Sie diesen Wert für den folgenden Schritt.
Erstellen Sie als Nächstes einen AWS IAM-OIDC-Anbieter, der mit dem folgenden Befehl auf Ihren Cluster verweist:
```
aws iam create-open-id-connect-provider \
    --url ISSUER_URI \
    --client-id-list sts.amazonaws.com \
    --thumbprint-list 08745487e891c19e3078c1f2a07e452950ef36f6
```
Ersetzen Sie ISSUER_URI durch den Aussteller-URI aus dem vorherigen Schritt.

Der THumbprint des Google Cloud-Dienstes, der den Aussteller-URI bereitstellt, ist immer 08745487e891c19e3078c1f2a07e452950ef36f6.

AWS IAM-Rolle mit einer angehängten IAM-Richtlinie konfigurieren

So konfigurieren Sie eine AWS-IAM-Rolle und fügen eine Richtlinie hinzu:

Bestimmen Sie den Ausstellerhost, indem Sie das Präfix https:// aus dem Aussteller-URI entfernen. Wenn Ihr URI beispielsweise https://oidc-provider.com/v1/projects/pid/locations/us-west1/awsClusters/awscluster lautet, ist der Host oidc-provider.com/v1/projects/pid/locations/us-west1/awsClusters/awscluster. Speichern Sie diesen Wert. Sie benötigen diese Informationen später.
Führen Sie den folgenden Befehl aus, um den Amazon Resource Name (ARN) des Anbieters zu ermitteln:
```
aws iam list-open-id-connect-providers --output=text \
    --query 'OpenIDConnectProviderList[?ends_with(Arn, `ISSUER_HOST`) == `true`].Arn'
```
Ersetzen Sie ISSUER_HOST durch den Hostnamen aus dem Aussteller-URI für den Cluster.
Erstellen Sie als Nächstes eine Vertrauensrichtlinie, um dem Kubernetes-Dienstkonto OIDC-Anmeldedaten bereitzustellen. Erstellen Sie eine Datei mit dem Namen trust-policy.json und folgendem Inhalt:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "PROVIDER_ARN"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "ISSUER_HOST:sub": "system:serviceaccount:NAMESPACE:KSA_NAME"
        }
      }
    }
  ]
}
```
Ersetzen Sie Folgendes:
- PROVIDER_ARN: der ARN des IAM-OIDC-Anbieters des Clusters
- ISSUER_HOST: der Hostname aus dem Aussteller-URI für den Cluster.
- NAMESPACE: der Kubernetes-Namespace, in dem die Anwendung ausgeführt wird.
- KSA_NAME: das für die Anwendung zu verwendende Kubernetes-Dienstkonto (KSA)

Erstellen Sie eine AWS-IAM-Rolle:

aws iam create-role --role-name=AWS_ROLE_NAME \
    --assume-role-policy-document file://trust-policy.json

Ersetzen Sie AWS_ROLE_NAME durch den AWS IAM-Rollennamen für die Anwendung.

Hängen Sie die AWS IAM-Richtlinie an die Rolle an:
```
aws iam attach-role-policy --role-name=AWS_ROLE_NAME \
    --policy-arn=AWS_POLICY_ARN
```
Ersetzen Sie Folgendes:
- AWS_ROLE_NAME: der Name der AWS-IAM-Rolle für die Anwendung
Führen Sie beispielsweise den folgenden Befehl aus, um eine Rolle mit dem Namen ec2-readonly mit der Richtlinie arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess zu erstellen:
```
aws iam attach-role-policy --role-name=ec2-readonly \
    --policy-arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
```

Beispielanwendung bereitstellen

So testen Sie Workload Identity, um eine Beispielanwendung bereitzustellen:

Ermitteln Sie den ARN der Rolle:

aws iam get-role --role-name=AWS_ROLE_NAME --query 'Role.Arn'

Ersetzen Sie AWS_ROLE_NAME.

Erstellen Sie ein Manifest für einen Kubernetes-Namespace, ein KSA und einen Pod. Kopieren Sie das folgende Manifest in eine Datei mit dem Namen workload-identity-test.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: NAMESPACE
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: KSA_NAME
  namespace: NAMESPACE
automountServiceAccountToken: false
---
apiVersion: v1
kind: Pod
metadata:
  name: aws-cli-example
  namespace: NAMESPACE
spec:
  serviceAccount: KSA_NAME
  containers:
  - name: aws-cli
    image: amazon/aws-cli:latest
    command:
    - /bin/bash
    - -c
    - "set -eu -o pipefail; while true; do aws ec2 describe-availability-zones; sleep 5; done"
    env:
    - name: AWS_ROLE_ARN
      value: AWS_ROLE_ARN
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/aws-iam-token/serviceaccount/token
    - name: AWS_REGION
      value: AWS_REGION
    volumeMounts:
    - mountPath: /var/run/secrets/aws-iam-token/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

Ersetzen Sie Folgendes:

NAMESPACE
KSA_NAME
AWS_ROLE_ARN: der ARN der AWS-IAM-Rolle für die Anwendung
AWS_REGION: die AWS-Region des Clusters

Wenden Sie das Manifest an:
```
kubectl apply -f workload-identity-test.yaml
```
Warten Sie einige Minuten, bis der Pod gestartet wurde, und fahren Sie mit dem folgenden Abschnitt fort.

Beispielanwendung prüfen

Sehen Sie sich die Logs des Pods an, um zu prüfen, ob die Beispielanwendung auf die EC2 API zugreifen kann:

kubectl logs -f aws-cli-example -n NAMESPACE

Wenn der Pod auf die EC2 API zugreifen kann, enthält die Ausgabe Informationen zu EC2-Verfügbarkeitszonen und sieht in etwa so aus:

-------------------------------------------------
|           DescribeAvailabilityZones           |
+-----------------------------------------------+
||              AvailabilityZones              ||
|+---------------------+-----------------------+|
||  GroupName          |  us-west-2            ||
||  NetworkBorderGroup |  us-west-2            ||
||  OptInStatus        |  opt-in-not-required  ||
||  RegionName         |  us-west-2            ||
||  State              |  available            ||
||  ZoneId             |  usw2-az1             ||
||  ZoneName           |  us-west-2a           ||
|+---------------------+-----------------------+|
||              AvailabilityZones              ||
|+---------------------+-----------------------+|
||  GroupName          |  us-west-2            ||
||  NetworkBorderGroup |  us-west-2            ||
||  OptInStatus        |  opt-in-not-required  ||
||  RegionName         |  us-west-2            ||
||  State              |  available            ||
||  ZoneId             |  usw2-az2             ||
||  ZoneName           |  us-west-2b           ||
|+---------------------+-----------------------+|
||              AvailabilityZones              ||
|+---------------------+-----------------------+|
||  GroupName          |  us-west-2            ||
||  NetworkBorderGroup |  us-west-2            ||
||  OptInStatus        |  opt-in-not-required  ||
||  RegionName         |  us-west-2            ||
||  State              |  available            ||
||  ZoneId             |  usw2-az3             ||
||  ZoneName           |  us-west-2c           ||
|+---------------------+-----------------------+|
||              AvailabilityZones              ||
|+---------------------+-----------------------+|
||  GroupName          |  us-west-2            ||
||  NetworkBorderGroup |  us-west-2            ||
||  OptInStatus        |  opt-in-not-required  ||
||  RegionName         |  us-west-2            ||
||  State              |  available            ||
||  ZoneId             |  usw2-az4             ||
||  ZoneName           |  us-west-2d           ||
|+---------------------+-----------------------+|

Bereinigen

So entfernen Sie diese Beispielanwendung:

Löschen Sie das Manifest der Beispielanwendung aus Ihrem Cluster:
```
kubectl delete -f workload-identity-test.yaml
```

Trennen Sie die AWS-IAM-Richtlinie von der Rolle:

aws iam detach-role-policy --role-name AWS_ROLE_NAME \
    --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

Ersetzen Sie AWS_ROLE_NAME durch den AWS IAM-Rollennamen für die Anwendung.

Löschen Sie die AWS-IAM-Rolle:
```
aws iam delete-role --role-name AWS_ROLE_NAME
```
Ersetzen Sie AWS_ROLE_NAME durch den AWS IAM-Rollennamen für die Anwendung.
Löschen Sie den AWS IAM-OIDC-Anbieter:
```
aws iam delete-open-id-connect-provider --open-id-connect-provider-arn PROVIDER_ARN
```
Ersetzen Sie PROVIDER_ARN durch den ARN des IAM-OIDC-Anbieters für den Cluster.

Nächste Schritte

Informationen zur Verwendung von Workload Identity mit Google Cloud-Diensten.