Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Accédez aux AWS ressources à l'aide des rôles IAM EKS Pod Identity Target

Lorsque vous exécutez des applications sur Amazon Elastic Kubernetes Service (Amazon EKS), il se peut que vous deviez accéder AWS à des ressources qui existent dans différents comptes. AWS Ce guide explique comment configurer l'accès entre comptes à l'aide d'EKS Pod Identity, qui permet à vos pods Kubernetes d'accéder à d'autres AWS ressources à l'aide de rôles cibles.

Conditions préalables

Avant de commencer, assurez-vous d’avoir effectué les étapes suivantes :

Comment ça marche

Pod Identity permet aux applications de votre cluster EKS d'accéder aux AWS ressources de différents comptes par le biais d'un processus appelé chaînage des rôles.

Lorsque vous créez une association Pod Identity, vous pouvez fournir deux rôles IAM : un rôle EKS Pod Identity dans le même compte que votre cluster EKS et un rôle IAM cible provenant du compte contenant les AWS ressources auxquelles vous souhaitez accéder (comme les compartiments S3 ou les bases de données RDS). Le rôle EKS Pod Identity doit se trouver dans le compte de votre cluster EKS en raison des PassRole exigences IAM, tandis que le rôle IAM cible peut se trouver dans n'importe quel AWS compte. PassRole permet à une AWS entité de déléguer l'attribution de rôles à un autre service. EKS Pod Identity PassRole permet de connecter un rôle à un compte de service Kubernetes, ce qui nécessite que le rôle et l'identité qui le transmettent se trouvent dans le même AWS compte que le cluster EKS. Lorsque votre pod d'application a besoin d'accéder à AWS des ressources, il demande des informations d'identification à Pod Identity. L’identité du pod effectue alors automatiquement deux prises de rôle consécutives : elle prend d’abord le rôle d’identité du pod EKS, puis utilise ces informations d’identification pour prendre le rôle IAM cible. Ce processus fournit à votre pod des informations d'identification temporaires dotées des autorisations définies dans le rôle cible, ce qui permet un accès sécurisé aux ressources d'autres AWS comptes.

Considérations relatives à la mise en cache

En raison des mécanismes de mise en cache, les mises à jour d’un rôle IAM dans une association identité du pod EKS peuvent ne pas prendre effet immédiatement dans les pods s’exécutant sur votre cluster EKS. L’agent identité du pod met en cache les informations d’identification IAM en fonction de la configuration de l’association au moment où les informations d’identification sont récupérées. Si l’association comprend uniquement un rôle d’identité du pod EKS et aucun rôle IAM cible, les informations d’identification mises en cache sont valables pendant 6 heurs. Si l’association comprend à la fois l’ARN du rôle d’identité du pod EKS et un rôle IAM cible, les informations d’identification mises en cache sont valables pendant 59 minutes. La modification d’une association existante, telle que la mise à jour de l’ARN du rôle d’identité du pod EKS ou l’ajout d’un rôle IAM cible, ne réinitialise pas le cache existant. Par conséquent, l’agent ne reconnaîtra pas les mises à jour tant que les informations d’identification mises en cache n’auront pas été actualisées. Pour appliquer les modifications plus rapidement, vous pouvez recréer les pods existants ; sinon, vous devrez attendre l’expiration du cache.

Étape 1 : créer et associer un rôle IAM cible

Au cours de cette étape, vous allez établir une chaîne de confiance sécurisée en créant et en configurant un rôle IAM cible. À titre de démonstration, nous allons créer un nouveau rôle IAM cible pour établir une chaîne de confiance entre deux AWS comptes : le rôle EKS Pod Identity (par exempleeks-pod-identity-primary-role) du AWS compte du cluster EKS est autorisé à assumer le rôle IAM cible (par exempleeks-pod-identity-aws-resources) sur votre compte cible, ce qui permet d'accéder à des AWS ressources telles que les compartiments Amazon S3.

Créer le rôle IAM cible

Mettre à jour la politique d’approbation du rôle IAM cible

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
          "aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
          "aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
        },
        "ArnEquals": {
          "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
        }
      }
    }
  ]
}

La politique ci-dessus permet au rôle eks-pod-identeity-primary-role du AWS compte 111122223333 doté des tags de session EKS Pod Identity appropriés d'assumer ce rôle.

Si vous avez désactivé les balises de session dans votre identité du pod EKS, l’identité du pod EKS définit également le sts:ExternalId avec des informations sur le cluster, l’espace de noms et le compte de service d’un pod lors de l’assomption d’un rôle cible.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
        },
        "ArnEquals": {
          "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:TagSession"
    }
  ]
}

La politique ci-dessus permet de garantir que seuls le cluster, l’espace de noms et le compte de service attendus peuvent assumer le rôle cible.

Mettre à jour la politique d’autorisation pour le rôle d’identité du pod EKS

Au cours de cette étape, vous allez mettre à jour la politique d’autorisation du rôle d’identité du pod EKS associé à votre cluster Amazon EKS en ajoutant l’ARN du rôle IAM cible en tant que ressource.

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
        }
    ]
}

Étape 2 : associer le rôle IAM cible à un compte de service Kubernetes

Au cours de cette étape, vous allez créer une association entre le rôle IAM cible et le compte de service Kubernetes dans votre cluster EKS.