Utilizza Workload Identity con AWS

L'identità del carico di lavoro consente di assegnare identità e autorizzazioni distinte e granulari per ogni applicazione nel tuo cluster. Workload Identity è il modo consigliato per consentire alle applicazioni eseguite in GKE su AWS di accedere ai servizi AWS e Google Cloud. Per maggiori informazioni, consulta Identità del carico di lavoro.

Questo argomento spiega come creare un provider OIDC, eseguire il provisioning degli account di servizio e testare un carico di lavoro di esempio utilizzando Workload Identity.

Crea un provider AWS IAM OIDC per il cluster

Per utilizzare l'identità del carico di lavoro con il cluster, devi prima creare un provider AWS IAM OIDC che fa riferimento al tuo cluster. Se hai già un provider IAM OIDC per il cluster, puoi saltare questa sezione.

Per creare il provider, segui questi passaggi:

  1. Determina l'URI dell'emittente OIDC per il tuo cluster:

    gcloud container aws clusters describe CLUSTER_NAME \
         --location=GOOGLE_CLOUD_LOCATION \
         --format='value(workloadIdentityConfig.issuerUri)'
    

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster
    • GOOGLE_CLOUD_LOCATION: nome della località Google Cloud da cui verrà gestito questo pool di nodi, come definito nelle regioni di gestione di Google Cloud

    L'output include l'URI dell'emittente OIDC del cluster. Salva questo valore per il passaggio successivo.

  2. Quindi, crea un provider AWS IAM OIDC che faccia riferimento al tuo cluster con il seguente comando:

    aws iam create-open-id-connect-provider \
        --url ISSUER_URI \
        --client-id-list sts.amazonaws.com \
        --thumbprint-list 08745487e891c19e3078c1f2a07e452950ef36f6
    

    Sostituisci ISSUER_URI con l'URI dell'emittente del passaggio precedente.

    L'impronta digitale del servizio Google Cloud che gestisce l'URI dell'emittente è sempre 08745487e891c19e3078c1f2a07e452950ef36f6.

Configurare un ruolo AWS IAM con un criterio IAM associato

Per configurare un ruolo AWS IAM e collegare un criterio, segui questi passaggi:

  1. Determina l'host dell'emittente rimuovendo il prefisso https:// dall'URI dell'emittente. Ad esempio, se il tuo URI è https://oidc-provider.com/v1/projects/pid/locations/us-west1/awsClusters/awscluster, l'host è oidc-provider.com/v1/projects/pid/locations/us-west1/awsClusters/awscluster. Salva questo valore. Ne avrai bisogno successivamente.

  2. Per determinare l'Amazon Resource Name (ARN) del provider, esegui:

    aws iam list-open-id-connect-providers --output=text \
        --query 'OpenIDConnectProviderList[?ends_with(Arn, `ISSUER_HOST`) == `true`].Arn'
    

    Sostituisci ISSUER_HOST con il nome host dell'URI dell'emittente per il cluster.

  3. Quindi, crea un criterio di attendibilità per fornire le credenziali OIDC all'account di servizio Kubernetes. Crea un file denominato trust-policy.json con i seguenti contenuti:

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "PROVIDER_ARN"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "ISSUER_HOST:sub": "system:serviceaccount:NAMESPACE:KSA_NAME"
            }
          }
        }
      ]
    }
    

    Sostituisci quanto segue:

    • PROVIDER_ARN: l'ARN del provider IAM OIDC del cluster
    • ISSUER_HOST: il nome host dell'URI dell'emittente per il cluster.
    • NAMESPACE: lo spazio dei nomi Kubernetes in cui viene eseguita l'applicazione
    • KSA_NAME: l'account di servizio Kubernetes da utilizzare per l'applicazione
  4. Crea un ruolo AWS IAM:

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

    Sostituisci AWS_ROLE_NAME con il nome del ruolo AWS IAM per l'applicazione.

  5. Collega un criterio AWS IAM al ruolo:

    aws iam attach-role-policy --role-name=AWS_ROLE_NAME \
        --policy-arn=AWS_POLICY_ARN
    

    Sostituisci quanto segue:

    • AWS_ROLE_NAME: nome del ruolo AWS IAM per l'applicazione

    Ad esempio, per creare un ruolo denominato ec2-readonly, con il criterio arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess, esegui questo comando:

    aws iam attach-role-policy --role-name=ec2-readonly \
        --policy-arn=arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
    

Deployment di un'applicazione di esempio

Per testare Workload Identity, segui questi passaggi per eseguire il deployment di un'applicazione di esempio:

  1. Determina l'ARN del ruolo:

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

    Sostituisci AWS_ROLE_NAME.

  2. Creare un manifest per uno spazio dei nomi Kubernetes, un Arabia Saudita e un pod. Copia il seguente manifest in un file denominato 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
    

    Sostituisci quanto segue:

    • NAMESPACE
    • KSA_NAME
    • AWS_ROLE_ARN: l'ARN del ruolo AWS IAM per l'applicazione
    • AWS_REGION: la regione AWS del cluster
  3. Applica il manifest:

    kubectl apply -f workload-identity-test.yaml
    

    Attendi alcuni minuti per l'avvio del pod e vai alla sezione successiva.

Verifica che l'applicazione di esempio funzioni

Per verificare che l'applicazione di esempio sia in grado di accedere all'API EC2, esamina i log del pod:

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

Se il pod può accedere all'API EC2, l'output include informazioni sulle zone di disponibilità EC2 e ha un aspetto simile al seguente:

-------------------------------------------------
|           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           ||
|+---------------------+-----------------------+|

Esegui la pulizia

Per rimuovere questa applicazione di esempio:

  1. Elimina il manifest dell'applicazione di esempio dal cluster:

    kubectl delete -f workload-identity-test.yaml
    
  2. Scollega il criterio AWS IAM dal ruolo:

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

    Sostituisci AWS_ROLE_NAME con il nome del ruolo AWS IAM per l'applicazione.

  3. Elimina il ruolo AWS IAM:

    aws iam delete-role --role-name AWS_ROLE_NAME
    

    Sostituisci AWS_ROLE_NAME con il nome del ruolo AWS IAM per l'applicazione.

  4. Elimina il provider AWS IAM OIDC:

    aws iam delete-open-id-connect-provider --open-id-connect-provider-arn PROVIDER_ARN
    

    Sostituisci PROVIDER_ARN con l'ARN del provider IAM OIDC per il cluster.

Passaggi successivi