Rôles IAM pour les comptes de service

Les applications situées dans les conteneurs d'un pod peuvent utiliser un AWS SDK ou la AWS CLI pour envoyer des demandes d'API aux AWS services à l'aide des AWS autorisations Identity and Access Management (IAM). Les applications doivent signer leurs demandes AWS d'API avec des AWS informations d'identification. Les rôles IAM pour les comptes de service (IRSA) permettent de gérer les informations d'identification de vos applications, de la même manière que les profils d' EC2 instance Amazon fournissent des informations d'identification aux instances Amazon EC2 . Au lieu de créer et de distribuer vos AWS informations d'identification aux conteneurs ou d'utiliser le rôle de l' EC2 instance Amazon, vous associez un rôle IAM à un compte de service Kubernetes et configurez vos Pods pour utiliser le compte de service. Vous ne pouvez pas utiliser de rôles IAM pour des comptes de service dotés de clusters locaux pour Amazon EKS on AWS Outposts.

Les rôles IAM pour les comptes de service offrent les bénéfices suivants :

• Privilège minimal : vous pouvez attribuer des autorisations IAM à un compte de service, et seuls les pods qui utilisent ce compte de service ont accès à ces autorisations. Cette fonctionnalité élimine également le besoin de solutions tierces telles que kiam ou kube2iam.

• Isolation des informations d'identification : les conteneurs d'un pod peuvent uniquement récupérer les informations d'identification pour le rôle IAM associé au compte de service utilisé par le conteneur. Un conteneur n'a jamais accès aux informations d'identification utilisées par d'autres conteneurs dans d'autres pods. Lorsque vous utilisez des rôles IAM pour des comptes de service, les conteneurs du Pod disposent également des autorisations attribuées au rôle IAM du nœud Amazon EKS, sauf si vous bloquez l'accès du Pod à l'Amazon EC2 Instance Metadata Service (IMDS). Pour plus d'informations, consultez Restreindre l'accès au profil d'instance affecté au composant master.

• Auditabilité — La journalisation des accès et des événements est disponible AWS CloudTrail pour garantir un audit rétrospectif.

Activez les rôles IAM pour les comptes de service en suivant les procédures suivantes :

1. Créez un fournisseur IAM OIDC pour votre cluster : vous n'effectuez cette procédure qu'une seule fois pour chaque cluster.

   Note

   Si vous avez activé le point de terminaison du VPC EKS, le point de terminaison du service EKS OIDC n'est pas accessible depuis ce VPC. Par conséquent, les opérations telles que la création d'un fournisseur OIDC avec eksctl dans le VPC n'aboutiront pas et entraîneront une expiration lors de la tentative de demande de https://oidc.eks.region.amazonaws.com. Voici un exemple de message d'erreur :

   server cant find oidc.eks.region.amazonaws.com: NXDOMAIN

   Pour terminer cette étape, vous pouvez exécuter la commande en dehors du VPC, par exemple dans AWS CloudShell ou sur un ordinateur connecté à Internet. Vous pouvez également créer un résolveur conditionnel à horizon partagé dans le VPC, tel que Route 53 Resolver, afin d'utiliser un résolveur différent pour l'URL de l'émetteur OIDC et de ne pas utiliser le DNS du VPC pour celle-ci. Pour un exemple de transfert conditionnel dans CoreDNS, consultez la demande de fonctionnalité Amazon EKS sur. GitHub

2. Attribuer des rôles IAM aux comptes de service Kubernetes : effectuez cette procédure pour chaque ensemble unique d'autorisations que vous souhaitez attribuer à une application.

3. Configurer les pods pour utiliser un compte de service Kubernetes : effectuez cette procédure pour chaque pod devant accéder aux services. AWS

4. Utiliser IRSA avec le AWS SDK : vérifiez que la charge de travail utilise un AWS SDK d'une version prise en charge et qu'elle utilise la chaîne d'identification par défaut.

Informations générales sur IAM, Kubernetes et OpenID Connect (OIDC)

En 2014, AWS Identity and Access Management a ajouté la prise en charge des identités fédérées à l'aide d'OpenID Connect (OIDC). Cette fonctionnalité vous permet d'authentifier les appels d' AWS API auprès des fournisseurs d'identité pris en charge et de recevoir un jeton Web OIDC JSON (JWT) valide. Vous pouvez transmettre ce jeton à l'opération de l'AssumeRoleWithWebIdentityAPI AWS STS et recevoir des informations d'identification de rôle temporaires IAM. Vous pouvez utiliser ces informations d'identification pour interagir avec n'importe quel AWS service, y compris Amazon S3 et DynamoDB.

Chaque jeton JWT est signé par une paire de clés de signature. Les clés sont servies sur le fournisseur OIDC géré par Amazon EKS et la clé privée change tous les 7 jours. Amazon EKS conserve les clés publiques jusqu'à leur expiration. Si vous connectez des clients OIDC externes, sachez que vous devez actualiser les clés de signature avant l'expiration de la clé publique. Apprenez à récupérer les clés de signature pour valider les jetons OIDC.

Kubernetes utilise depuis longtemps les comptes de service comme son propre système d'identité interne. Les pods peuvent s'authentifier auprès du serveur d'API Kubernetes à l'aide d'un jeton monté automatiquement (qui était un JWT non OIDC) que seul le serveur d'API Kubernetes a pu valider. Ces anciens jetons de compte de service n'expirent pas, et la rotation de la clé de signature est un processus difficile. Dans la version Kubernetes1.12, la prise en charge d'une nouvelle fonctionnalité a été ajoutée. ProjectedServiceAccountToken Cette fonctionnalité est un jeton Web OIDC JSON qui contient également l'identité du compte de service et prend en charge une audience configurable.

Amazon EKS héberge un point de terminaison de découverte OIDC public pour chaque cluster qui contient les clés de signature des jetons Web ProjectedServiceAccountToken JSON afin que les systèmes externes, tels que IAM, puissent valider et accepter les jetons OIDC émis par Kubernetes.