Rôles IAM pour les comptes de service - Amazon EKS
Informations générales sur IAM, Kubernetes et OpenID Connect (OIDC)

Aidez à améliorer cette page

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

Rôles IAM pour les comptes de service

Les applications dans les conteneurs d’un Pod peuvent utiliser un SDK AWS ou l’interface CLI AWS pour envoyer des requêtes API aux services AWS à l’aide des autorisations de la gestion des identités et des accès AWS (IAM). Les applications doivent signer leurs demandes d’API AWS avec les informations d’identification AWS. 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’instance Amazon EC2 fournissent des informations d’identification aux instances Amazon EC2. Au lieu de créer et 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 vous configurez vos pods pour qu’ils utilisent le 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.

  • Isolation des informations d’identification : lorsque l’accès au service de métadonnées d’instance (IMDS) Amazon EC2 est restreint, les conteneurs d’un pod ne peuvent récupérer que les informations d’identification du rôle IAM associé au compte de service utilisé par le conteneur. Un conteneur n’a jamais accès aux informations d’identification qui sont utilisées par d’autres conteneurs dans d’autres pods. Si IMDS n’est pas restreint, les conteneurs du Pod ont également accès au rôle IAM du nœud Amazon EKS et les conteneurs peuvent être en mesure d’accéder aux informations d’identification des rôles IAM d’autres Pods sur le même nœud. Pour plus d'informations, consultez Restreindre l'accès au profil d'instance affecté au composant master.

Note

Les pods configurés avec hostNetwork: true auront toujours accès à IMDS, mais les SDK AWS et CLI utiliseront les informations d’identification IRSA lorsqu’ils seront activés.

  • Auditabilité : l’accès et la journalisation des événements sont disponibles via CloudTrail AWS afin de garantir un audit rétrospectif.

Important

Les conteneurs ne constituent pas une limite de sécurité, et l’utilisation de rôles IAM pour les comptes de service ne change rien à cela. Les pods attribués au même nœud partageront un noyau et éventuellement d’autres ressources en fonction de la configuration de votre pod. Bien que les pods s’exécutant sur des nœuds distincts soient isolés au niveau de la couche de calcul, certaines applications de nœuds disposent d’autorisations supplémentaires dans l’API Kubernetes qui dépassent le champ d’application d’une instance individuelle. Quelques exemples : kubelet, kube-proxy, les pilotes de stockage CSI ou vos propres applications Kubernetes.

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 ne devez effectuer cette procédure qu’une seule fois pour chaque cluster.

    Note

    Si vous avez activé le point de terminaison d’un VPC EKS, le point de terminaison du service OIDC EKS n’était pas accessible depuis l’intérieur de 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 CloudShell AWS ou sur un ordinateur connecté à Internet. Vous pouvez également créer un résolveur conditionnel à horizon divisé 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 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 : suivez 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. Utilisez IRSA avec le kit SDK AWS : vérifiez que la charge de travail utilise un SDK AWS d’une version prise en charge et qu’elle utilise la chaîne d’informations d’identification par défaut.

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

En 2014, la gestion des identités et des accès AWS 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 JSON (JWT) OIDC valide. Vous pouvez transmettre ce jeton à l’opération d’API AssumeRoleWithWebIdentity AWS STS et recevoir des informations d’identification du rôle temporaire IAM. 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. 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 jetons de compte de service hérités n’expirent pas et la rotation de la clé de signature est un processus difficile. Dans la version Kubernetes 1.12, une nouvelle fonctionnalité ProjectedServiceAccountToken a été ajoutée. Cette fonctionnalité est un jeton Web JSON OIDC 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 JSON ProjectedServiceAccountToken afin que les systèmes externes, tels que IAM, puissent valider et accepter les jetons OIDC émis par Kubernetes.