View a markdown version of this page

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

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 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.

Rôles IAM pour les comptes de service

Astuce

Inscrivez-vous aux prochains ateliers Amazon EKS.

Les applications contenues 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 autorisations de gestion des AWS identités et des accès (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’instance Amazon EC2 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'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 dotés de 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 un accès IMDS, mais les AWS SDK et la 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 AWS CloudTrail pour 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 le VPC de votre cluster ne dispose d'aucun accès Internet sortant et que vous n'avez pas configuré d'accès privé au point de terminaison OIDC du cluster, les opérations qui atteignent ce point de terminaison depuis le VPC, telles que la création d'un fournisseur OIDC aveceksctl, ne peuvent pas résoudre le nom d'hôte de l'émetteur OIDC. Voici un exemple de message d'erreur :

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

    Pour accéder au point de terminaison OIDC du cluster en privé depuis votre VPC, créez un point de terminaison d'interface VPC pour celui-ci (com.amazonaws.region-code.oidc-eks) avec le DNS privé activé. Pour de plus amples informations, veuillez consulter Accédez à Amazon EKS à l'aide de AWS PrivateLink.

    Vous pouvez également exécuter la commande en dehors du VPC (par exemple, dans AWS CloudShell) ou créer un résolveur conditionnel à horizon partagé. Pour un exemple, 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. Configurez les pods pour qu'ils utilisent un compte de service Kubernetes — Effectuez cette procédure pour chaque pod nécessitant un accès 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 que la charge de travail utilise la chaîne d'informations 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 de fournisseurs d'identité pris en charge et de recevoir un jeton Web OIDC JSON (JWT) valide. Vous pouvez transmettre ce jeton à l'opération d'AssumeRoleWithWebIdentityAPI AWS STS et recevoir des informations d'identification de rôle temporaire 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 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.