Rôles IAM pour les comptes de service

Les applications situées dans les conteneurs d'un Pod peuvent utiliser un kit SDK AWS ou la AWS CLI pour envoyer des requêtes d'API à Services AWS en utilisant des autorisations AWS Identity and Access Management (IAM). Les applications doivent signer leurs requêtes d'API AWS avec les informations d'identification AWS. Les rôles IAM pour les comptes de service offrent une capacité de gestion des informations d'identification à utiliser pour les applications, de la même façon que les profils d'instance Amazon EC2 fournissent des informations d'identification aux instances EC2. Au lieu de créer et de distribuer vos informations d'identification AWS aux conteneurs ou d'utiliser le rôle de l'instance Amazon EC2, vous associez un rôle IAM à un compte de service Kubernetes et configurez vos Pods pour utiliser ce compte de service. Vous ne pouvez pas utiliser les rôles IAM pour les comptes de service avec les clusters locaux pour Amazon EKS sur AWS Outposts.

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

• Moindre privilège – Vous pouvez définir les autorisations IAM sur 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.

• Isolement des informations d'identification : les conteneurs d'un Pod's peuvent uniquement récupérer les informations d'identification du rôle IAM associées au compte de service que le conteneur utilise. Un conteneur n'a jamais accès aux informations d'identification qui sont utilisées par d'autres conteneurs dans d'autres Pods. Lorsque vous utilisez des rôles IAM pour les comptes de service, les conteneurs de Pod's possèdent également les autorisations attribuées au rôle IAM de nœud Amazon EKS, sauf si vous empêchez les Pod d'accéder au service de métadonnées d'instance (IMDS) Amazon EC2. Pour plus d'informations, consultez Restreindre l'accès au profil d'instance affecté au composant master.

• Capacité d'audit – La journalisation des événements et des accès est disponible via AWS CloudTrail afin de permettre les audits rétrospectifs.

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

1. Création d'un fournisseur OIDC IAM pour votre cluster — Vous n'effectuez cette procédure qu'une seule fois pour chaque cluster.

   Note

   Si vous activez le point de terminaison VPC EKS, le point de terminaison du service OIDC EKS ne sera 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 can't 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.

2. Configuration d'un compte de service Kubernetes pour assumer un rôle IAM — Suivez cette procédure pour chaque ensemble unique d'autorisations que vous souhaitez attribuer à une application.

3. Configuration des Pods pour qu'ils utilisent un compte de service Kubernetes : effectuez cette procédure pour chaque Pod qui doit accéder à Services AWS.

4. Utilisation d'un kit SDK AWS pris en charge : confirmez que la charge de travail utilise un kit SDK AWS d’une version prise en charge et que la charge de travail utilise la chaîne d’informations d’identification par défaut.

Informations générales 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'API AWS avec les fournisseurs d'identité pris en charge et de recevoir un jeton web OIDC JSON valide (JWT). Vous pouvez transmettre ce jeton à l'opération d'API AssumeRoleWithWebIdentity AWS STS et recevoir des informations d'identification du rôle IAM temporaire. Vous pouvez utiliser ces informations d'identification pour interagir avec n'importe quel Service AWS, 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. Découvrez comment Récupérez les clés de signature.

Kubernetes utilise depuis longtemps les comptes de service comme son propre système d'identité interne. Pods peut s'authentifier auprès du serveur API Kubernetes utilisant un jeton monté automatiquement (qui était un JWT non-OIDC) que seul le serveur API Kubernetes a pu valider. Ces jetons de compte de service hérités n'expirent pas et la rotation de la clé de signature est un processus difficile. Dans Kubernetes version 1.12, le support a été ajouté pour une nouvelle fonction 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 contenant les clés de signature des jetons web ProjectedServiceAccountToken JSON afin que les systèmes externes, comme IAM, puissent valider et accepter les jetons OIDC émis par Kubernetes.