Autorisations IAM entre comptes

Vous pouvez configurer les autorisations IAM entre comptes en créant un fournisseur d'identité à partir du cluster d'un autre compte ou en utilisant les opérations AssumeRole chaînées. Dans les exemples suivants, Account A (compte A) possède un cluster Amazon EKS qui prend en charge les rôles IAM pour les comptes de service. Les Pods exécutés sur ce cluster doivent endosser les autorisations IAM de Account B (compte B).

Exemple Créer un fournisseur d'identité à partir du cluster d'un autre compte

Dans cet exemple, le Compte A fournit au Compte B l'URL de l'émetteur OpenID Connect (OIDC) à partir de son cluster. Le compte B suit les instructions de Créez un OIDC fournisseur IAM pour votre cluster et Configurer un compte Kubernetes de service pour qu'il assume un rôle IAM avec l'URL de l'émetteur OIDC du cluster du compte A. Ensuite, un administrateur de cluster annote le compte de service du cluster du compte A pour utiliser le rôle du compte B (444455556666).

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role

Exemple Utiliser des opérations AssumeRole chaînées

Dans cet exemple, le compte B crée une politique IAM avec les autorisations à accorder aux Pods du cluster du compte A. Le compte B (444455556666) attache cette politique à un rôle IAM avec une relation d'approbation qui offre les autorisations AssumeRole au compte A (111122223333), comme illustré ci-dessous.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

Le compte A crée un rôle avec une politique d'approbation qui récupère les informations d'identification du fournisseur d'identité créé avec l'adresse de l'émetteur OIDC.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity"
    }
  ]
}

Si votre cluster se trouve dans une autre , ou si vous avez copié les images dans votre propre référentiel lors d'une étape précédente, effectuez les étapes suivantes.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::444455556666:role/account-b-role"
        }
    ]
}

Le code d'application pour que les Pods endossent le rôle du compte B utilise deux profils : account_b_role et account_a_role. Le profil account_b_role utilise le profil account_a_role comme source. Pour le AWS CLI, le ~/.aws/config fichier est similaire au suivant.

[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token 
role_arn=arn:aws:iam::111122223333:role/account-a-role

Pour spécifier des profils chaînés pour d'autres AWS SDK, consultez la documentation du SDK que vous utilisez. Pour plus d'informations, consultez la section Outils sur lesquels vous pouvez vous appuyer AWS.