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 sur le même compte ou sur des comptes différents. AWS Ce guide explique comment configurer l'accès entre ces comptes à l'aide d'EKS Pod Identity, qui permet à vos pods Kubernetes d'accéder à d'autres ressources. AWS

Prérequis

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 vos AWS ressources (comme les compartiments S3 ou les tables DynamoDB). Le rôle EKS Pod Identity doit figurer 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. Pod Identity exécute ensuite automatiquement deux hypothèses de rôle en séquence : d'abord en assumant le rôle EKS Pod Identity, puis en utilisant ces informations d'identification pour assumer 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 concernant la mise en cache

En raison des mécanismes de mise en cache, les mises à jour d'un rôle IAM dans une association Pod Identity existante peuvent ne pas prendre effet immédiatement dans les pods exécutés sur votre cluster EKS. L'agent Pod Identity 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 inclut uniquement un ARN de rôle EKS Pod Identity et aucun rôle IAM cible, les informations d'identification mises en cache durent 6 heures. Si l'association inclut à la fois l'ARN du rôle EKS Pod Identity et un rôle Target IAM, les informations d'identification mises en cache durent 59 minutes. La modification d'une association existante, telle que la mise à jour de l'ARN du rôle EKS Pod Identity 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 ne seront pas actualisées. Pour appliquer les modifications plus rapidement, vous pouvez recréer les modules existants ; sinon, vous devrez attendre que le cache expire.

É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éation du rôle IAM cible

Mettre à jour la politique de confiance du rôle IAM cible

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws: iam::111122223333:role/eks-pod-identity-primary-role"
            },
            "Action": "sts:AssumeRole"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws: iam::111122223333:role/eks-pod-identity-primary-role"
            },
            "Action": "sts:TagSession"
        }
    ]
}

Mettre à jour la politique d'autorisation pour le rôle EKS Pod Identity

Au cours de cette étape, vous allez mettre à jour la politique d'autorisation du rôle EKS Pod Identity 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 Target IAM et le compte de service Kubernetes dans votre cluster EKS.

(Facultatif) Étape 3 : ajouter des autorisations externes à un rôle cible IAM

Il peut arriver que vous deviez accorder à un tiers l'accès à vos AWS ressources (accès délégué). Par exemple, vous décidez de faire appel à une société tierce appelée Example Corp pour surveiller votre AWS compte et vous aider à optimiser les coûts. Afin de suivre vos dépenses quotidiennes, Example Corp doit accéder à vos AWS ressources. Dans ce cas, nous vous recommandons d'ajouter un ExternalId à la politique de confiance de votre rôle cible IAM afin d'éviter d'éventuels problèmes de confusion chez les adjoints.

Modifier la politique de confiance

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