Come posso risolvere i problemi relativi a un provider OIDC e a un IRSA in Amazon EKS?

8 minuti di lettura
0

I miei pod non possono utilizzare le autorizzazioni del ruolo AWS Identity and Access Management (IAM) con il token dell'account Amazon Elastic Kubernetes Service (Amazon EKS).

Breve descrizione

Per risolvere i problemi relativi al provider OpenID Connect (OIDC) e ai ruoli IAM per gli account di servizio (IRSA) in Amazon EKS, completa i passaggi in una delle seguenti sezioni:

  • Controlla se disponi di un provider IAM OIDC esistente per il tuo cluster
  • Controlla se il tuo ruolo IAM ha una policy IAM necessaria allegata alle autorizzazioni richieste
  • Verifica che le relazioni di trust del ruolo IAM siano impostate correttamente
  • Controlla se hai creato un account di servizio
  • Verifica che l'account di servizio disponga delle annotazioni del ruolo IAM corrette
  • Verifica di aver specificato correttamente serviceAccountName nel tuo pod
  • Controlla le variabili d'ambiente e le autorizzazioni
  • Verifica che l'applicazione utilizzi un SDK AWS supportato
  • Controlla l'utente e il gruppo del pod
  • Ricrea i pod
  • Verifica che il destinatario sia corretto
  • Verifica di aver configurato l'impronta digitale corretta
  • Per la Regione AWS Cina, controlla la variabile d'ambiente AWS_DEFAULT_REGION

Risoluzione

Controlla se disponi di un provider IAM OIDC esistente per il tuo cluster

Se esiste già un provider, viene visualizzato un messaggio di errore simile al seguente:

"WebIdentityErr: failed to retrieve credentials\ncaused by: InvalidIdentityToken: No OpenIDConnect provider found in your account for https://oidc.eks.eu-west-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E\n\tstatus code: 400"

1.    Controlla l'URL del provider OIDC del tuo cluster:

$ aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text

Vedi il seguente esempio di output:

https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E

2.    Elenca i provider IAM OIDC nel tuo account. Sostituisci EXAMPLED539D4633E53DE1B716D3041E (includi < >) con il valore restituito dal comando precedente:

aws iam list-open-id-connect-providers | grep EXAMPLED539D4633E53DE1B716D3041E

Vedi il seguente esempio di output:

"Arn": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"

Se il comando precedente restituisce un output, allora hai già un provider per il tuo cluster. Se il comando non restituisce un output, devi creare un provider IAM OIDC.

Controlla se il tuo ruolo IAM ha una policy IAM necessaria allegata alle autorizzazioni richieste

1.    Apri la console IAM.

2.    Nel pannello di navigazione, scegli Ruoli.

3.    Scegli il ruolo che vuoi verificare.

4.    Nella scheda Autorizzazioni, verifica se a questo ruolo è allegata la policy necessaria.

Verifica che le relazioni di trust del ruolo IAM siano impostate correttamente

Tramite la Console di gestione AWS:

1.    Apri la console IAM.

2.    Nel pannello di navigazione, scegli Ruoli.

3.    Scegli il ruolo che vuoi controllare.

4.    Scegli la scheda Relazioni di trust per verificare che il formato della policy corrisponda al formato della seguente policy JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME",
          "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

Per verificare le relazioni di fiducia, esegui il seguente comando con il nome del tuo ruolo nell'Interfaccia della linea di comando AWS (AWS CLI):

$ aws iam get-role --role-name EKS-IRSA

Nota: sostituisci EKS-IRSA con il nome del tuo ruolo IAM.

Nell'output JSON, cerca la sezione AssumeRolePolicyDocument.

Vedi il seguente esempio di output:

{
  "Role": {
    "Path": "/",
    "RoleName": "EKS-IRSA",
    "RoleId": "AROAQ55NEXAMPLELOEISVX",
    "Arn": "arn:aws:iam::ACCOUNT_ID:role/EKS-IRSA",
    "CreateDate": "2021-04-22T06:39:21+00:00",
    "AssumeRolePolicyDocument": {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com",
              "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME"
            }
          }
        }
      ]
    },
    "MaxSessionDuration": 3600,
    "RoleLastUsed": {
      "LastUsedDate": "2021-04-22T07:01:15+00:00",
      "Region": "AWS_REGION"
    }
  }
}

Nota: controlla di aver specificato la Regione AWS, il nome dell'account di servizio Kubernetes e lo spazio dei nomi Kubernetes corretti.

Controlla se hai creato un account di servizio

Usa il seguente comando:

$ kubectl get sa -n YOUR_NAMESPACE

Nota: sostituisci YOUR_NAMESPACE con il tuo spazio dei nomi Kubernetes.

Vedi il seguente esempio di output:

NAME      SECRETS   AGE
default   1         28d
irsa      1         66m

Se non disponi di un account di servizio, consulta Configure service accounts for pods (dal sito Web Kubernetes).

Verifica che l'account di servizio disponga delle annotazioni del ruolo IAM corrette

Usa il seguente comando:

$ kubectl describe sa irsa -n YOUR_NAMESPACE

Nota: sostituisci irsa con il nome dell'account di servizio Kubernetes. Sostituisci YOUR_NAMESPACE con il tuo spazio dei nomi Kubernetes.

Vedi il seguente esempio di output:

Name:                irsa
Namespace:           default
Labels:              none
Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME
Image pull secrets:  none
Mountable secrets:   irsa-token-v5rtc
Tokens:              irsa-token-v5rtc
Events:              none

Verifica di aver specificato correttamente serviceAccountName nel tuo pod

Usa il seguente comando:

$ kubectl get pod POD_NAME  -o yaml -n YOUR_NAMESPACE| grep -i serviceAccountName:

Nota: sostituisci POD_NAME e YOUR_NAMESPACE con il pod e lo spazio dei nomi Kubernetes.

Vedi il seguente esempio di output:

serviceAccountName: irsa

Controlla le variabili d'ambiente e le autorizzazioni

Cerca AWS_ROLE_ARN e AWS_WEB_IDENTITY_TOKEN_FILE nelle variabili d'ambiente del pod:

$ kubectl -n YOUR_NAMESPACE exec -it POD_NAME -- env | grep AWS

Vedi il seguente esempio di output:

AWS_REGION=ap-southeast-2
AWS_ROLE_ARN=arn:aws:iam::111122223333:role/EKS-IRSA
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
AWS_DEFAULT_REGION=ap-southeast-2

Verifica che l'applicazione utilizzi un SDK AWS supportato

La versione SDK deve essere maggiore o uguale ai seguenti valori:

Java (Version 2) — 2.10.11
Java — 1.11.704
Go — 1.23.13
Python (Boto3) — 1.9.220
Python (botocore) — 1.12.200
AWS CLI — 1.16.232
Node — 3.15.0
Ruby — 2.11.345
C++ — 1.7.174
.NET — 3.3.659.1
PHP — 3.110.7

Per controllare la versione più recente dell'SDK supportata, consulta Utilizzo di un SDK AWS supportato.

Controlla l'utente e il gruppo del pod

Usa il seguente comando:

$ kubectl exec -it POD_NAME -- id
uid=0(root) gid=0(root) groups=0(root)

Nota: di default, solo i container che vengono eseguiti come root dispongono delle autorizzazioni del file system appropriate per leggere il file del token di identità Web.

Se i tuoi container non sono in esecuzione come root, puoi ricevere i seguenti errori:

Error: PermissionError: [Errno 13] Permission denied: '/var/run/secrets/eks.amazonaws.com/serviceaccount/token

-oppure-

WebIdentityErr: failed fetching WebIdentity token: \ncaused by: WebIdentityErr: unable to read file at /var/run/secrets/eks.amazonaws.com/serviceaccount/token\ncaused by: open /var/run/secrets/eks.amazonaws.com/serviceaccount/token: permission denied

Per fornire le autorizzazioni appropriate per il file system, assicurati che i tuoi container vengano eseguiti come root. Per i cluster 1.18 o inferiori, fornisci il seguente contesto di sicurezza per i container nel manifesto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-app
      containers:
      - name: my-app
        image: my-app:latest
      securityContext:
        fsGroup: 1337
...

Nota: l'ID fsGroup è arbitrario. Puoi scegliere qualsiasi ID di gruppo valido. L'impostazione precedente del contesto di sicurezza non è obbligatoria per i cluster 1.19 o versioni successive.

Ricrea i pod

Se hai creato i pod prima di applicare IRSA, ricrea i pod.

Vedi il seguente esempio di comando:

$ kubectl rollout restart deploy nginx

Vedi il seguente esempio di output:

deployment.apps/nginx restarted

Per le implementazioni daemonsets o statefulsets, puoi utilizzare il seguente comando:

$ kubectl rollout restart deploy DEPLOYMENT_NAME

Se hai creato un solo pod, devi eliminare il pod e ricrearlo.

Vedi il seguente comando di esempio per eliminare il pod:

$ kubectl delete pod POD_NAME

Vedi il seguente comando di esempio per ricreare il pod:

$ kubectl apply -f SPEC_FILE

Nota: sostituisci SPEC_FILE con il percorso e il nome del file manifesto di Kubernetes.

Verifica che il destinatario sia corretto

Se hai creato il provider OIDC con un destinatario errato, ricevi il seguente errore:

Error - An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Incorrect token audience

Controlla il provider di identità IAM per il tuo cluster. Il tuo ClientIDList è sts.amazonaws.com:

$ aws iam get-open-id-connect-provider --open-id-connect-provider-arn arn:aws:iam::ACCOUNT_ID:oidc-provider/oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E

Vedi il seguente esempio di output:

{
  "Url": "oidc.eks.AWS_REGION.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E",
  "ClientIDList": [
    "sts.amazonaws.com"
  ],
  "ThumbprintList": [
    "9e99a48a9960b14926bb7f3b02e22da2b0ab7280"
  ],
  "CreateDate": "2021-01-21T04:29:09.788000+00:00",
  "Tags": []
}

Verifica di aver configurato l'impronta digitale corretta

Se l'identificazione personale configurata in IAM OIDC non è corretta, puoi ricevere il seguente errore:

failed to retrieve credentials caused by: InvalidIdentityToken: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint

Per configurare automaticamente l'identificazione personale corretta, utilizza eksctl o la Console di gestione AWS per creare il provider di identità IAM. Per altri modi di ottenimento dell'identificazione personale, consulta Ottenimento dell'identificazione personale per un provider di identità OpenID Connect.

Per la Regione AWS Cina, controlla la variabile d'ambiente AWS_DEFAULT_REGION

Se usi IRSA per un pod o un daemonset implementato in un cluster nella Regione AWS Cina, imposta la variabile di ambiente AWS_DEFAULT_REGION nella specifica del pod. In caso contrario, il pod o il daemonset possono ricevere il seguente errore:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid

Utilizza l'esempio seguente per aggiungere la variabile d'ambiente AWS_DEFAULT_REGION alla specifica pod o daemonset:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-app
      containers:
      - name: my-app
        image: my-app:latest
        env:
        - name: AWS_DEFAULT_REGION
          value: "AWS_REGION"
...

AWS UFFICIALE
AWS UFFICIALEAggiornata 2 anni fa