Comment résoudre les problèmes liés à un fournisseur OIDC et à un IRSA dans Amazon EKS ?
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 :
-
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
-
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 :
- Ouvrez la console IAM.
- Dans le volet de navigation, choisissez Rôles.
- Sélectionnez le rôle que vous souhaitez examiner.
- Dans l'onglet Autorisations, vérifiez que la politique requise est bien attachée au rôle.
- 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 :
-
Ouvrez la console IAM.
-
Dans le volet de navigation, choisissez Rôles.
-
Sélectionnez le rôle que vous souhaitez vérifier.
-
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 :
- Exécutez la commande suivante pour supprimer le pod :
Remarque : remplacez POD_NAME par le nom de votre pod.$ kubectl delete pod POD_NAME
- Exécutez la commande suivante pour recréer le pod :
Remarque : remplacez SPEC_FILE par le chemin et le nom de votre fichier manifeste Kubernetes.$ kubectl apply -f SPEC_FILE
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" ...
Vidéos associées
Contenus pertinents
- demandé il y a 3 moislg...
- demandé il y a 4 moislg...
- demandé il y a 5 moislg...
- demandé il y a 2 anslg...
- demandé il y a 4 moislg...
- AWS OFFICIELA mis à jour il y a 3 ans
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 9 mois
- AWS OFFICIELA mis à jour il y a 8 mois