Comment résoudre les problèmes liés à un fournisseur OIDC et à un IRSA dans Amazon EKS ?

Lecture de 7 minute(s)
0

Mes pods ne peuvent pas utiliser les autorisations de rôle Gestion des identités et des accès AWS (AWS IAM) avec le jeton de compte Amazon Elastic Kubernetes Service (Amazon EKS).

Résolution

Vérifiez si vous disposez d'un fournisseur OIDC IAM existant pour votre cluster

Si un fournisseur est déjà en place, vous obtiendrez une erreur similaire à cet exemple : « 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 »;

Pour vérifier si vous disposez déjà d'un fournisseur OIDC IAM, procédez comme suit :

  1. Vérifiez l'URL du fournisseur OIDC de votre cluster :

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

    Exemple de sortie :

    https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E
  2. Répertoriez les fournisseurs OIDC IAM de votre compte. Remplacez EXAMPLED539D4633E53DE1B716D3041E par la valeur obtenue grâce à la commande précédente :

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

    Exemple de sortie :

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

Si la commande renvoie une sortie, cela signifie que vous disposez déjà d’un fournisseur pour votre cluster. Si la commande ne renvoie aucune sortie, vous devez créer un fournisseur OIDC IAM.

Vérifiez si votre rôle IAM dispose des autorisations requises et d'une politique IAM attachée

Remarque : si des erreurs surviennent lorsque vous exécutez des commandes de l’interface de la ligne de commande AWS (AWS CLI), consultez la page Résoudre les erreurs liées à AWS CLI. Vérifiez également que vous utilisez la version la plus récente de l'interface AWS CLI.

Pour vérifier que votre rôle IAM dispose des autorisations requises, procédez comme suit :

  1. Ouvrez la console IAM.
  2. Dans le volet de navigation, choisissez Rôles.
  3. Sélectionnez le rôle que vous souhaitez examiner.
  4. Dans l'onglet Autorisations, vérifiez que la politique requise est bien attachée au rôle.
  5. Vérifiez que les relations d'approbation entre les rôles IAM sont correctement définies.

Pour vérifier que votre rôle IAM est attaché à une politique, procédez comme suit :

  1. Ouvrez la console IAM.

  2. Dans le volet de navigation, choisissez Rôles.

  3. Sélectionnez le rôle que vous souhaitez vérifier.

  4. Choisissez l’onglet Relations d'approbation. Vérifiez que le format de votre politique correspond bien au format de la politique JSON suivante :

    {  "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"
            }
          }
        }
      ]
    }

    Pour vérifier les relations d'approbation, exécutez la commande get-role dans l'interface de la ligne de commande AWS (AWS CLI) :

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

    Remarque : remplacez EKS-IRSA par le nom de votre rôle IAM.
    Dans le JSON de sortie, recherchez la section AssumeRolePolicyDocument.
    Exemple de sortie :

    {  "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"
        }
      }
    }

    Remarque : selon votre cas d'utilisation, vous devez mettre à jour la région AWS, le nom du compte de service Kubernetes et l'espace de noms Kubernetes.

Vérifiez que vous avez créé un compte de service

Exécutez la commande suivante :

$ kubectl get sa -n YOUR_NAMESPACE

Remarque : remplacez YOUR_NAMESPACE par votre espace de noms Kubernetes.

Exemple de sortie : 

NAME      SECRETS   AGEdefault   1         28d
irsa      1         66m

Si vous n'avez pas de compte de service, consultez la section Configure Service Accounts for Pods sur le site Web de Kubernetes.

Vérifiez que le compte de service comporte les annotations de rôle IAM correctes

Pour vérifier que les annotations de rôle IAM de votre compte de service sont correctes, exécutez la commande suivante :

$ kubectl describe sa irsa -n YOUR_NAMESPACE

Remarque : remplacez irsa par le nom de votre compte de service Kubernetes et YOUR_NAMESPACE par votre espace de noms Kubernetes.

Exemple de sortie :

Name:                irsaNamespace:           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

Vérifiez que vous avez correctement spécifié la valeur serviceAccountName dans votre pod

Pour vérifier la valeur serviceAccountName, exécutez la commande suivante :

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

Remarque : remplacez POD_NAME et YOUR_NAMESPACE par votre pod Kubernetes et votre espace de noms.

Exemple de sortie : 

serviceAccountName: irsa

Vérifiez les variables d'environnement et les autorisations

Recherchez AWS_ROLE_ARN et AWS_WEB_IDENTITY_TOKEN_FILE dans les variables d'environnement du pod :

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

Exemple de sortie : 

AWS_REGION=ap-southeast-2AWS_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

Vérifiez que l'application utilise un kit SDK AWS prise en charge

La version du kit SDK doit être supérieure ou égale aux valeurs suivantes :

Java (Version 2) — 2.10.11Java — 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

Pour connaître la dernière version de kit SDK prise en charge, consultez la section Utilisation d'un kit SDK AWS pris en charge.

Recréez les pods

Si vous avez créé des pods avant d'appliquer l'IRSA, vous devez exécuter la commande suivante pour les recréer :

$ kubectl rollout restart deploy nginx

Exemple de sortie :

deployment.apps/nginx restarted

Pour les déploiements de daemonsets ou de statefulsets, exécutez la commande suivante :

$ kubectl rollout restart deploy DEPLOYMENT_NAME

Si vous n'avez créé qu'un seul pod, vous devez le supprimer et le recréer :

  1. Exécutez la commande suivante pour supprimer le pod :
    $ kubectl delete pod POD_NAME
    Remarque : remplacez POD_NAME par le nom de votre pod.
  2. Exécutez la commande suivante pour recréer le pod :
    $ kubectl apply -f SPEC_FILE
    Remarque : remplacez SPEC_FILE par le chemin et le nom de votre fichier manifeste Kubernetes.

Vérifiez que l'audience est correcte

Si vous avez créé le fournisseur OIDC avec une audience incorrecte, le message d'erreur suivant s'affiche : « Error - An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: Incorrect token audience ».

Vérifiez le fournisseur d'identité IAM de votre cluster. Votre ClientIDList est 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

Exemple de sortie :

{  "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": []
}

Vérifiez que vous avez configuré une empreinte correcte

Si l'empreinte configurée dans l'OIDC IAM n'est pas correcte, le message d'erreur suivant s'affiche : « failed to retrieve credentials caused by : InvalidIdentityToken: OpenIDConnect provider's HTTPS certificate doesn't match configured thumbprint ».

Pour configurer l'empreinte correcte de façon automatique, utilisez eksctl ou la console de gestion AWS pour créer le fournisseur d'identité IAM. Pour connaître les autres moyens d'obtenir une empreinte, consultez la page Obtention de l'empreinte numérique d’un fournisseur d'identité OpenID Connect.

Pour la région AWS Chine, vérifiez la variable d'environnement AWS_DEFAULT_REGION

Dans le cas d’un pod ou d’un daemonset appliqué à l'IRSA et déployé sur un cluster dans la région AWS Chine, vos devez définir la variable d'environnement AWS_DEFAULT_REGION dans la spécification du pod. Si vous ne définissez pas cette variable, le pod ou le daemonset peut recevoir l'erreur suivante :  « An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid ».

Pour ajouter la variable d'environnement AWS_DEFAULT_REGION à votre spécification de pod ou de daemonset, exécutez une commande similaire à cet exemple :

apiVersion: apps/v1kind: 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 OFFICIEL
AWS OFFICIELA mis à jour il y a 9 mois