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.
Gestion de l’identité et des accès
Identity and Access Management (IAM) est un service AWS qui exécute deux fonctions essentielles : l'authentification et l'autorisation. L'authentification implique la vérification d'une identité, tandis que l'autorisation régit les actions qui peuvent être effectuées par les ressources AWS. Au sein d'AWS, une ressource peut être un autre service AWS, par exemple EC2, ou un principal AWS tel qu'un utilisateur ou un rôle IAM. Les règles régissant les actions qu'une ressource est autorisée à effectuer sont exprimées sous forme de politiques IAM.
Contrôle de l'accès aux clusters EKS
Le projet Kubernetes prend en charge différentes stratégies pour authentifier les demandes adressées au service kube-apiserver, par exemple les Bearer Tokens, les certificats X.509, OIDC, etc. EKS prend actuellement en charge de manière native l'authentification par jeton Webhook
La stratégie d'authentification du webhook fait appel à un webhook qui vérifie les jetons porteurs. Sur EKS, ces jetons porteurs sont générés par la CLI AWS ou par le aws-iam-authenticatorkubectl
commandes. Lorsque vous exécutez des commandes, le jeton est transmis au serveur kube-apiserver qui le transmet au webhook d'authentification. Si la demande est bien formée, le webhook appelle une URL pré-signée intégrée dans le corps du jeton. Cette URL valide la signature de la demande et renvoie des informations sur l'utilisateur, par exemple le compte de l'utilisateur, Arn, et UserId au kube-apiserver.
Pour générer manuellement un jeton d'authentification, tapez la commande suivante dans une fenêtre de terminal :
aws eks get-token --cluster-name <cluster_name>
Vous pouvez également obtenir un jeton par programmation. Voici un exemple écrit en Go :
package main import ( "fmt" "log" "sigs.k8s.io/aws-iam-authenticator/pkg/token" ) func main() { g, _ := token.NewGenerator(false, false) tk, err := g.Get("<cluster_name>") if err != nil { log.Fatal(err) } fmt.Println(tk) }
La sortie doit ressembler à ceci :
{ "kind": "ExecCredential", "apiVersion": "client.authentication.k8s.io/v1alpha1", "spec": {}, "status": { "expirationTimestamp": "2020-02-19T16:08:27Z", "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFKTkdSSUxLTlNSQzJXNVFBJTJGMjAyMDAyMTklMkZ1cy1lYXN0LTElMkZzdHMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIwMDIxOVQxNTU0MjdaJlgtQW16LUV4cGlyZXM9NjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JTNCeC1rOHMtYXdzLWlkJlgtQW16LVNpZ25hdHVyZT0yMjBmOGYzNTg1ZTMyMGRkYjVlNjgzYTVjOWE0MDUzMDFhZDc2NTQ2ZjI0ZjI4MTExZmRhZDA5Y2Y2NDhhMzkz" } }
Chaque jeton commence par k8s-aws-v1.
suivi d'une chaîne codée en base64. La chaîne, une fois décodée, doit ressembler à ceci :
https://sts.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXJPFRILKNSRC2W5QA%2F20200219%2Fus-xxxx-1%2Fsts%2Faws4_request&X-Amz-Date=20200219T155427Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&X-Amz-Signature=XXXf8f3285e320ddb5e683a5c9a405301ad76546f24f28111fdad09cf648a393
Le jeton consiste en une URL pré-signée qui inclut un identifiant et une signature Amazon. Pour plus de détails, voir https://docs.aws.amazon.com/STS/latest/APIReference/API_ GetCallerIdentity .html.
Le jeton a une durée de vie (TTL) de 15 minutes, après quoi un nouveau jeton devra être généré. Cela est géré automatiquement lorsque vous utilisez un client, par exemplekubectl
, si vous utilisez le tableau de bord Kubernetes, vous devrez générer un nouveau jeton et vous authentifier à chaque fois que le jeton expire.
Une fois que l'identité de l'utilisateur a été authentifiée par le service AWS IAM, le kube-apiserver la lit aws-auth
ConfigMap dans l'kube-system
espace de noms pour déterminer le groupe RBAC à associer à l'utilisateur. aws-auth
ConfigMap Il est utilisé pour créer un mappage statique entre les principaux IAM, c'est-à-dire les utilisateurs et les rôles IAM, et les groupes RBAC Kubernetes. Les groupes RBAC peuvent être référencés dans RoleBindings Kubernetes ou. ClusterRoleBindings Ils sont similaires aux rôles IAM dans la mesure où ils définissent un ensemble d'actions (verbes) qui peuvent être effectuées sur un ensemble de ressources Kubernetes (objets).
Gestionnaire d'accès au cluster
Cluster Access Manager, désormais la méthode préférée pour gérer l'accès des principaux AWS IAM aux clusters Amazon EKS, est une fonctionnalité de l'API AWS et une fonctionnalité optionnelle pour les clusters EKS v1.23 et versions ultérieures (nouveaux ou existants). Il simplifie le mappage des identités entre AWS IAM et KubernetesRBACs, éliminant ainsi le besoin de passer d'AWS à Kubernetes APIs ou de modifier le code aws-auth
ConfigMap pour la gestion des accès, réduisant ainsi les frais opérationnels et aidant à corriger les erreurs de configuration. L'outil permet également aux administrateurs de cluster de révoquer ou d'affiner cluster-admin
les autorisations accordées automatiquement au principal AWS IAM utilisé pour créer le cluster.
Cette API repose sur deux concepts :
-
Entrées d'accès : une identité de cluster directement liée à un AWS IAM principal (utilisateur ou rôle) autorisé à s'authentifier auprès d'un cluster Amazon EKS.
-
Politiques d'accès : les politiques spécifiques à Amazon EKS autorisent-elles une entrée d'accès à effectuer des actions dans le cluster Amazon EKS.
Au lancement, Amazon EKS prend uniquement en charge les politiques prédéfinies et gérées par AWS. Les politiques d'accès ne sont pas des entités IAM et sont définies et gérées par Amazon EKS.
Cluster Access Manager permet de combiner le RBAC en amont avec des politiques d'accès permettant d'autoriser et de transmettre (mais pas de refuser) les décisions de Kubernetes AuthZ concernant les demandes du serveur d'API. Une décision de refus sera prise lorsque le RBAC en amont et les autorisateurs Amazon EKS ne peuvent pas déterminer le résultat de l'évaluation d'une demande.
Grâce à cette fonctionnalité, Amazon EKS prend en charge trois modes d'authentification :
-
CONFIG_MAP
pour continuer à utiliseraws-auth
ConfigMap exclusivement. -
API_AND_CONFIG_MAP
pour obtenir des principes IAM authentifiés à la fois à partir d'EKS Access Entry et deaws-auth
ConfigMap, en hiérarchisant APIs les entrées d'accès. Idéal pour migrer lesaws-auth
autorisations existantes vers Access Entries. -
API
de s'appuyer exclusivement sur EKS Access Entry APIs. Il s'agit de la nouvelle approche recommandée.
Pour commencer, les administrateurs de clusters peuvent créer ou mettre à jour des clusters Amazon EKS, en définissant l'authentification API_AND_CONFIG_MAP
ou la API
méthode préférée et en définissant les entrées d'accès pour accorder l'accès aux principaux AWS IAM souhaités.
$ aws eks create-cluster \ --name <CLUSTER_NAME> \ --role-arn <CLUSTER_ROLE_ARN> \ --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \ --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \ --access-config authenticationMode=API_AND_CONFIG_MAP,bootstrapClusterCreatorAdminPermissions=false
La commande ci-dessus est un exemple de création d'un cluster Amazon EKS déjà sans les autorisations d'administrateur du créateur du cluster.
Il est possible de mettre à jour la configuration des clusters Amazon EKS pour activer API
AuthenticationMode à l'aide de la update-cluster-config
commande. Pour ce faire, sur les clusters existants, CONFIG_MAP
vous devrez d'abord effectuer une mise à jour vers, API_AND_CONFIG_MAP
puis vers. API
Ces opérations ne peuvent pas être annulées, ce qui signifie qu'il n'est pas possible de passer de « API
à » API_AND_CONFIG_MAP
ou CONFIG_MAP
« API_AND_CONFIG_MAP
à CONFIG_MAP
».
$ aws eks update-cluster-config \ --name <CLUSTER_NAME> \ --access-config authenticationMode=API
L'API prend en charge les commandes permettant d'ajouter et de révoquer l'accès au cluster, ainsi que de valider les politiques d'accès et les entrées d'accès existantes pour le cluster spécifié. Les politiques par défaut sont créées pour correspondre à Kubernetes comme suit. RBACs
Politique d'accès EKS | RBAC Kubernetes |
---|---|
Amazon EKSCluster AdminPolicy |
administrateur du cluster |
EKSAdminPolitique d'Amazon |
admin |
EKSEditPolitique d'Amazon |
modifier |
EKSViewPolitique d'Amazon |
afficher |
$ aws eks list-access-policies { "accessPolicies": [ { "name": "AmazonEKSAdminPolicy", "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy" }, { "name": "AmazonEKSClusterAdminPolicy", "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy" }, { "name": "AmazonEKSEditPolicy", "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy" }, { "name": "AmazonEKSViewPolicy", "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy" } ] } $ aws eks list-access-entries --cluster-name <CLUSTER_NAME> { "accessEntries": [] }
Aucune entrée d'accès n'est disponible lorsque le cluster est créé sans l'autorisation d'administrateur du créateur du cluster, qui est la seule entrée créée par défaut.
Le aws-auth
ConfigMap (obsolète)
L'intégration de Kubernetes à l'authentification AWS peut être effectuée via le aws-auth
ConfigMap, qui réside dans l'espace de noms. kube-system
Il est chargé de mapper l'authentification des identités AWS IAM (utilisateurs, groupes et rôles) à l'autorisation de contrôle d'accès basé sur les rôles (RBAC) de Kubernetes. aws-auth
ConfigMap Il est automatiquement créé dans votre cluster Amazon EKS lors de sa phase de provisionnement. Il a été initialement créé pour permettre aux nœuds de rejoindre votre cluster, mais comme indiqué, vous pouvez également l'utiliser ConfigMap pour ajouter RBACs un accès aux principaux IAM.
Pour vérifier celui de votre cluster aws-auth
ConfigMap, vous pouvez utiliser la commande suivante.
kubectl -n kube-system get configmap aws-auth -o yaml
Il s'agit d'un exemple de configuration par défaut du aws-auth
ConfigMap.
apiVersion: v1 data: mapRoles: | - groups: - system:bootstrappers - system:nodes - system:node-proxier rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/kube-system-<SELF_GENERATED_UUID> username: system:node:{{SessionName}} kind: ConfigMap metadata: creationTimestamp: "2023-10-22T18:19:30Z" name: aws-auth namespace: kube-system
La session principale se trouve data
en dessous du mapRoles
bloc, qui est essentiellement composé de 3 paramètres. ConfigMap
-
groupes : les Kubernetes auxquels group/groups mapper le rôle IAM. Il peut s'agir d'un groupe par défaut ou d'un groupe personnalisé spécifié dans un
clusterrolebinding
ourolebinding
. Dans l'exemple ci-dessus, seuls les groupes de systèmes sont déclarés. -
rolearn : L'ARN du rôle AWS IAM doit être mappé au groupe/aux groupes Kubernetes à ajouter, en utilisant le format suivant.
arn:<PARTITION>:iam::<AWS_ACCOUNT_ID>:role/role-name
-
nom d'utilisateur : nom d'utilisateur dans Kubernetes à associer au rôle AWS IAM. Il peut s'agir de n'importe quel nom personnalisé.
Il est également possible de mapper les autorisations pour les utilisateurs d'AWS IAM, en définissant un nouveau bloc de configuration pourmapUsers
, sous le aws-auth
ConfigMap, data
en remplaçant le paramètre rolearn pour userarn. Toutefois, en tant que bonne pratique, il est toujours recommandé d'utiliser plutôt l'utilisateur. mapRoles
Pour gérer les autorisations, vous pouvez modifier l'aws-auth
ConfigMap ajout ou la suppression de l'accès à votre cluster Amazon EKS. Bien qu'il soit possible de le modifier aws-auth
ConfigMap manuellement, il est recommandé d'utiliser des outils tels queeksctl
, étant donné qu'il s'agit d'une configuration très sensible et qu'une configuration inexacte peut vous empêcher de sortir de votre cluster Amazon EKS. Consultez la sous-section Utiliser des outils pour apporter des modifications à l'aws-auth ConfigMap
Recommandations relatives à l'accès aux clusters
Rendre le point de terminaison du cluster EKS privé
Par défaut, lorsque vous provisionnez un cluster EKS, le point de terminaison du cluster d'API est défini sur public, c'est-à-dire qu'il est accessible depuis Internet. Bien qu'il soit accessible depuis Internet, le point de terminaison est toujours considéré comme sécurisé car il nécessite que toutes les demandes d'API soient authentifiées par IAM puis autorisées par Kubernetes RBAC. Cela dit, si la politique de sécurité de votre entreprise impose de restreindre l'accès à l'API depuis Internet ou vous empêche de router le trafic en dehors du VPC du cluster, vous pouvez :
-
Configurez le point de terminaison du cluster EKS pour qu'il soit privé. Voir Modification de l'accès aux points de terminaison du cluster pour plus d'informations à ce sujet.
-
Laissez le point de terminaison du cluster public et spécifiez quels blocs CIDR peuvent communiquer avec le point de terminaison du cluster. Les blocs sont en fait un ensemble d'adresses IP publiques sur liste blanche autorisées à accéder au point de terminaison du cluster.
-
Configurez l'accès public avec un ensemble de blocs CIDR sur liste blanche et définissez l'accès aux terminaux privés sur Activé. Cela permettra un accès public à partir d'un éventail spécifique de publics IPs tout en forçant tout le trafic réseau entre les kubelets (travailleurs) et l'API Kubernetes via les comptes croisés ENIs qui sont provisionnés dans le VPC du cluster lorsque le plan de contrôle est provisionné.
N'utilisez pas de jeton de compte de service pour l'authentification
Un jeton de compte de service est un identifiant statique de longue durée. S'il est compromis, perdu ou volé, un attaquant peut être en mesure d'effectuer toutes les actions associées à ce jeton jusqu'à ce que le compte de service soit supprimé. Parfois, vous devrez peut-être accorder une exception pour les applications qui doivent utiliser l'API Kubernetes depuis l'extérieur du cluster, par exemple une application de pipeline CI/CD. Si de telles applications s'exécutent sur l'infrastructure AWS, comme EC2 les instances, pensez à utiliser un profil d'instance et à le mapper à un rôle RBAC Kubernetes.
Utilisez l'accès le moins privilégié aux ressources AWS
Il n'est pas nécessaire d'attribuer des privilèges aux ressources AWS pour accéder à l'API Kubernetes. Si vous devez accorder à un utilisateur IAM l'accès à un cluster EKS, créez une entrée dans le aws-auth
ConfigMap pour cet utilisateur qui correspond à un groupe Kubernetes RBAC spécifique.
Supprimer les autorisations d'administrateur du cluster auprès du créateur principal du cluster
Par défaut, les clusters Amazon EKS sont créés avec une cluster-admin
autorisation permanente liée au créateur principal du cluster. Avec l'API Cluster Access Manager, il est possible de créer des clusters sans que cette autorisation ne définisse le mode --access-config bootstrapClusterCreatorAdminPermissions
tofalse
, lors de l'utilisation API_AND_CONFIG_MAP
ou le mode API
d'authentification. Révoquer cet accès est considéré comme une bonne pratique pour éviter toute modification indésirable de la configuration du cluster. Le processus de révocation de cet accès suit le même processus pour révoquer tout autre accès au cluster.
L'API vous donne la flexibilité de dissocier uniquement un principal IAM d'une politique d'accès, dans ce cas le. AmazonEKSClusterAdminPolicy
$ aws eks list-associated-access-policies \ --cluster-name <CLUSTER_NAME> \ --principal-arn <IAM_PRINCIPAL_ARN> $ aws eks disassociate-access-policy --cluster-name <CLUSTER_NAME> \ --principal-arn <IAM_PRINCIPAL_ARN. \ --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
Ou en supprimant complètement l'entrée d'accès associée à l'cluster-admin
autorisation.
$ aws eks list-access-entries --cluster-name <CLUSTER_NAME> { "accessEntries": [] } $ aws eks delete-access-entry --cluster-name <CLUSTER_NAME> \ --principal-arn <IAM_PRINCIPAL_ARN>
Cet accès peut être accordé à nouveau si nécessaire lors d'un incident, d'une urgence ou d'un scénario de rupture de vitre dans lequel le cluster est autrement inaccessible.
Si le cluster aws-auth
ConfigMap est toujours configuré avec la méthode CONFIG_MAP
d'authentification, tous les utilisateurs supplémentaires doivent avoir accès au cluster par le biais du aws-auth
ConfigMap, et une fois configuré, le rôle attribué à l'entité qui a créé le cluster peut être supprimé et recréé uniquement en cas d'incident, d'urgence ou de bris de vitre, ou lorsque le cluster aws-auth
ConfigMap est endommagé et que le cluster est inaccessible pour une autre raison. Cela peut être particulièrement utile dans les clusters de production.
Utiliser les rôles IAM lorsque plusieurs utilisateurs ont besoin d'un accès identique au cluster
Plutôt que de créer une entrée pour chaque utilisateur IAM individuel, autorisez ces utilisateurs à assumer un rôle IAM et à associer ce rôle à un groupe Kubernetes RBAC. Cela sera plus facile à gérer, d'autant plus que le nombre d'utilisateurs ayant besoin d'un accès augmente.
Important
Lorsque vous accédez au cluster EKS avec l'entité IAM mappée par aws-auth
ConfigMap, le nom d'utilisateur décrit est enregistré dans le champ utilisateur du journal d'audit Kubernetes. Si vous utilisez un rôle IAM, les utilisateurs réels qui assument ce rôle ne sont pas enregistrés et ne peuvent pas être audités.
Si vous utilisez toujours le aws-auth
ConfigMap comme méthode d'authentification, lorsque vous attribuez des autorisations RBAC K8s à un rôle IAM, vous devez inclure \ {{}} dans votre nom d'utilisateur. SessionName Ainsi, le journal d'audit enregistrera le nom de la session afin que vous puissiez savoir qui est l'utilisateur réel qui assume ce rôle avec le CloudTrail journal.
- rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testRole username: testRole:{{SessionName}} groups: - system:masters
Utilisez l'accès le moins privilégié lors de la création RoleBindings et ClusterRoleBindings
Comme le point précédent concernant l'octroi de l'accès aux ressources AWS, RoleBindings ClusterRoleBindings il ne devrait inclure que l'ensemble des autorisations nécessaires pour exécuter une fonction spécifique. Évitez de l'utiliser ["*"]
dans vos rôles et ClusterRoles sauf si cela est absolument nécessaire. Si vous ne savez pas quelles autorisations attribuer, pensez à utiliser un outil tel que audit2rbac
Création d'un cluster à l'aide d'un processus automatisé
Comme indiqué dans les étapes précédentes, lors de la création d'un cluster Amazon EKS, si vous n'utilisez pas le mode API
d'utilisation API_AND_CONFIG_MAP
ou d'authentification, et si vous ne choisissez pas de déléguer des cluster-admin
autorisations au créateur du cluster, l'utilisateur ou le rôle de l'entité IAM, tel qu'un utilisateur fédéré qui crée le cluster, reçoit automatiquement des system:masters
autorisations dans la configuration RBAC du cluster. Même s'il s'agit d'une bonne pratique consistant à supprimer cette autorisation, comme décrit ici si vous utilisez la méthode CONFIG_MAP
d'authentification aws-auth
ConfigMap, cet accès ne peut pas être révoqué. Il est donc judicieux de créer le cluster avec un pipeline d'automatisation de l'infrastructure lié à un rôle IAM dédié, sans aucune autorisation à assumer par d'autres utilisateurs ou entités, et de vérifier régulièrement les autorisations et les politiques de ce rôle, ainsi que les personnes habilitées à déclencher le pipeline. De plus, ce rôle ne doit pas être utilisé pour effectuer des actions de routine sur le cluster, et être exclusivement utilisé pour des actions au niveau du cluster déclenchées par le pipeline, via des modifications de code SCM par exemple.
Créez le cluster avec un rôle IAM dédié
Lorsque vous créez un cluster Amazon EKS, l'utilisateur ou le rôle de l'entité IAM, tel qu'un utilisateur fédéré qui crée le cluster, reçoit automatiquement des system:masters
autorisations dans la configuration RBAC du cluster. Cet accès ne peut pas être supprimé et n'est pas géré via le aws-auth
ConfigMap. Il est donc judicieux de créer le cluster avec un rôle IAM dédié et de vérifier régulièrement qui peut assumer ce rôle. Ce rôle ne doit pas être utilisé pour effectuer des actions de routine sur le cluster. À cette fin, des utilisateurs supplémentaires doivent avoir accès au cluster via le aws-auth
ConfigMap . Une fois aws-auth
ConfigMap configuré, le rôle doit être sécurisé et utilisé uniquement en mode temporaire à privilèges élevés/break glass pour les scénarios dans lesquels le cluster est autrement inaccessible. Cela peut être particulièrement utile dans les clusters pour lesquels l'accès direct des utilisateurs n'est pas configuré.
Auditez régulièrement l'accès au cluster
Les personnes qui ont besoin d'un accès sont susceptibles de changer au fil du temps. Prévoyez de vérifier périodiquement aws-auth
ConfigMap les personnes qui ont obtenu l'accès et les droits qui leur ont été attribués. Vous pouvez également utiliser des outils open source tels kubectl-who-can
Si vous vous fiez à aws-auth
ConfigMap, utilisez des outils pour apporter des modifications
Un aws-auth mal formaté ConfigMap peut vous faire perdre l'accès au cluster. Si vous devez apporter des modifications au ConfigMap, utilisez un outil.
eksctl La eksctl
CLI inclut une commande pour ajouter des mappages d'identité à l'aws-auth. ConfigMap
Afficher l'aide de la CLI :
$ eksctl create iamidentitymapping --help ...
Vérifiez les identités mappées à votre cluster Amazon EKS.
$ eksctl get iamidentitymapping --cluster $CLUSTER_NAME --region $AWS_REGION ARN USERNAME GROUPS ACCOUNT arn:aws:iam::788355785855:role/kube-system-<SELF_GENERATED_UUID> system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
Faites d'un rôle IAM un administrateur de cluster :
$ eksctl create iamidentitymapping --cluster <CLUSTER_NAME> --region=<region> --arn arn:aws:iam::123456:role/testing --group system:masters --username admin ...
Pour plus d'informations, consultez les eksctl
documents
aws-auth
aws-auth
by keikoproj inclut à la fois une bibliothèque cli et une bibliothèque go.
Téléchargez et consultez l'aide de la CLI d'aide :
$ go get github.com/keikoproj/aws-auth ... $ aws-auth help ...
Vous pouvez également l'installer aws-auth
avec le gestionnaire de plugins Krew
$ kubectl krew install aws-auth ... $ kubectl aws-auth ...
Consultez la documentation aws-auth GitHub
CLI d'authentification AWS IAM
Le aws-iam-authenticator
projet inclut une CLI pour mettre à jour leConfigMap.
Téléchargez un communiqué
Ajoutez des autorisations de cluster à un rôle IAM :
$ ./aws-iam-authenticator add role --rolearn arn:aws:iam::185309785115:role/lil-dev-role-cluster --username lil-dev-user --groups system:masters --kubeconfig ~/.kube/config ...
Autres approches en matière d'authentification et de gestion des accès
Bien que l'IAM soit le moyen préféré pour authentifier les utilisateurs qui ont besoin d'accéder à un cluster EKS, il est possible d'utiliser un fournisseur d'identité OIDC, par exemple en GitHub utilisant un proxy d'authentification et en se faisant passer pour Kubernetes.
Important
EKS prend en charge nativement l'authentification OIDC sans utiliser de proxy. Pour plus d'informations, consultez le blog de lancement, Présentation de l'authentification du fournisseur d'identité OIDC pour Amazon EKS
Vous pouvez également utiliser AWS SSO pour fédérer AWS avec un fournisseur d'identité externe, par exemple Azure AD. Si vous décidez de l'utiliser, la version 2.0 de l'interface de ligne de commande AWS inclut une option permettant de créer un profil nommé qui permet d'associer facilement une session SSO à votre session d'interface de ligne de commande actuelle et d'assumer un rôle IAM. Sachez que vous devez assumer un rôle avant de lancer l'exécution, kubectl
car le rôle IAM est utilisé pour déterminer le groupe Kubernetes RBAC de l'utilisateur.
Identités et informations d'identification pour les pods EKS
Certaines applications qui s'exécutent au sein d'un cluster Kubernetes doivent être autorisées à appeler l'API Kubernetes pour fonctionner correctement. Par exemple, le contrôleur AWS Load Balancer
Comptes de service Kubernetes
Un compte de service est un type d'objet spécial qui vous permet d'attribuer un rôle Kubernetes RBAC à un pod. Un compte de service par défaut est créé automatiquement pour chaque espace de noms au sein d'un cluster. Lorsque vous déployez un pod dans un espace de noms sans faire référence à un compte de service spécifique, le compte de service par défaut pour cet espace de noms est automatiquement attribué au pod et le secret, c'est-à-dire le jeton de compte de service (JWT) pour ce compte de service, est monté sur le pod en tant que volume à. /var/run/secrets/kubernetes.io/serviceaccount
Le décodage du jeton du compte de service dans ce répertoire révélera les métadonnées suivantes :
{ "iss": "kubernetes/serviceaccount", "kubernetes.io/serviceaccount/namespace": "default", "kubernetes.io/serviceaccount/secret.name": "default-token-5pv4z", "kubernetes.io/serviceaccount/service-account.name": "default", "kubernetes.io/serviceaccount/service-account.uid": "3b36ddb5-438c-11ea-9438-063a49b60fba", "sub": "system:serviceaccount:default:default" }
Le compte de service par défaut dispose des autorisations suivantes pour accéder à l'API Kubernetes.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: "2020-01-30T18:13:25Z" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:discovery resourceVersion: "43" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery uid: 350d2ab8-438c-11ea-9438-063a49b60fba rules: - nonResourceURLs: - /api - /api/* - /apis - /apis/* - /healthz - /openapi - /openapi/* - /version - /version/ verbs: - get
Ce rôle autorise les utilisateurs authentifiés et non authentifiés à lire les informations de l'API et est considéré comme sûr pour être accessible au public.
Lorsqu'une application exécutée dans un Pod appelle les Kubernetes APIs, le Pod doit se voir attribuer un compte de service qui lui accorde explicitement l'autorisation de les appeler. APIs À l'instar des directives relatives à l'accès des utilisateurs, le rôle ou le lien ClusterRole lié à un compte de service doivent être limités aux ressources et méthodes d'API dont l'application a besoin pour fonctionner et rien d'autre. Pour utiliser un compte de service autre que celui par défaut, définissez simplement le spec.serviceAccountName
champ d'un Pod avec le nom du compte de service que vous souhaitez utiliser. Pour plus d'informations sur la création de comptes de service, consultez https://kubernetes. io/docs/reference/access-authn-authz/rbac/#. service-account-permissions
Note
Avant Kubernetes 1.24, Kubernetes créait automatiquement un secret pour chaque compte de service. Ce secret a été monté sur le pod à l'adresse/var/run/secrets/kubernetes.io/serviceaccountet serait utilisé par le pod pour s'authentifier auprès du serveur d'API Kubernetes. Dans Kubernetes 1.24, un jeton de compte de service est généré dynamiquement lorsque le pod fonctionne et n'est valide que pendant une heure par défaut. Aucun secret pour le compte de service ne sera créé. Si vous avez une application qui s'exécute en dehors du cluster et qui doit s'authentifier auprès de l'API Kubernetes, par exemple Jenkins, vous devrez créer un secret de type kubernetes.io/service-account-token
ainsi qu'une annotation faisant référence au compte de service, telle que. metadata.annotations.kubernetes.io/service-account.name: <SERVICE_ACCOUNT_NAME>
Les secrets ainsi créés n'expirent pas.
Rôles IAM pour les comptes de service (IRSA)
L'IRSA est une fonctionnalité qui vous permet d'attribuer un rôle IAM à un compte de service Kubernetes. Il fonctionne en tirant parti d'une fonctionnalité de Kubernetes connue sous le nom de Service Account Tokensts:AssumeRoleWithWebIdentity
. Après avoir validé la signature du jeton, IAM échange le jeton émis par Kubernetes contre un identifiant de rôle AWS temporaire.
Lorsque vous utilisez IRSA, il est important de réutiliser les sessions du SDK AWS afin d'éviter les appels inutiles à AWS STS.
Le décodage du jeton (JWT) pour IRSA produira un résultat similaire à l'exemple ci-dessous :
{ "aud": [ "sts.amazonaws.com" ], "exp": 1582306514, "iat": 1582220114, "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128", "kubernetes.io": { "namespace": "default", "pod": { "name": "alpine-57b5664646-rf966", "uid": "5a20f883-5407-11ea-a85c-0e62b7a4a436" }, "serviceaccount": { "name": "s3-read-only", "uid": "a720ba5c-5406-11ea-9438-063a49b60fba" } }, "nbf": 1582220114, "sub": "system:serviceaccount:default:s3-read-only" }
Ce jeton particulier accorde au Pod des privilèges d'affichage uniquement à S3 en assumant un rôle IAM. Lorsque l'application tente de lire depuis S3, le jeton est échangé contre un ensemble temporaire d'informations d'identification IAM semblable à ceci :
{ "AssumedRoleUser": { "AssumedRoleId": "AROA36C6WWEJULFUYMPB6:abc", "Arn": "arn:aws:sts::123456789012:assumed-role/eksctl-winterfell-addon-iamserviceaccount-de-Role1-1D61LT75JH3MB/abc" }, "Audience": "sts.amazonaws.com", "Provider": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128", "SubjectFromWebIdentityToken": "system:serviceaccount:default:s3-read-only", "Credentials": { "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY", "SessionToken": "FwoGZXIvYXdzEGMaDMLxAZkuLpmSwYXShiL9A1S0X87VBC1mHCrRe/pB2oesl1eXxUYnPJyC9ayOoXMvqXQsomq0xs6OqZ3vaa5Iw1HIyA4Cv1suLaOCoU3hNvOIJ6C94H1vU0siQYk7DIq9Av5RZeuE2FnOctNBvYLd3i0IZo1ajjc00yRK3v24VRq9nQpoPLuqyH2jzlhCEjXuPScPbi5KEVs9fNcOTtgzbVf7IG2gNiwNs5aCpN4Bv/Zv2A6zp5xGz9cWj2f0aD9v66vX4bexOs5t/YYhwuwAvkkJPSIGvxja0xRThnceHyFHKtj0Hbi/PWAtlI8YJcDX69cM30JAHDdQHltm/4scFptW1hlvMaPWReCAaCrsHrATyka7ttw5YlUyvZ8EPogj6fwHlxmrXM9h1BqdikomyJU00gm1FJelfP1zAwcyrxCnbRl3ARFrAt8hIlrT6Vyu8WvWtLxcI8KcLcJQb/LgkWsCTGlYcY8z3zkigJMbYn07ewTL5Ss7LazTJJa758I7PZan/v3xQHd5DEc5WBneiV3iOznDFgup0VAMkIviVjVCkszaPSVEdK2NU7jtrh6Jfm7bU/3P6ZGCkyDLIa8MBn9KPXeJd/yjTk5IifIwO/mDpGNUribg6TPxhzZ8b/XdZO1kS1gVgqjXyVCM+BRBh6C4H21w/eMzjCtDIpoxt5rGKL6Nu/IFMipoC4fgx6LIIHwtGYMG7SWQi7OsMAkiwZRg0n68/RqWgLzBt/4pfjSRYuk=", "Expiration": "2020-02-20T18:49:50Z", "AccessKeyId": "ASIAIOSFODNN7EXAMPLE" } }
Un webhook mutant qui s'exécute dans le cadre du plan de contrôle EKS injecte l'ARN du rôle AWS et le chemin d'accès à un fichier de jeton d'identité Web dans le Pod en tant que variables d'environnement. Ces valeurs peuvent également être fournies manuellement.
AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
Le kubelet fera automatiquement pivoter le jeton projeté lorsqu'il est supérieur à 80 % de son TTL total, ou après 24 heures. Les AWS SDKs sont chargés de recharger le jeton lors de sa rotation. Pour plus d'informations sur l'IRSA, voir https://docs.aws.amazon.com/eks/latest/userguide/iam- roles-for-service-accounts -technical-overview.html.
Identités du pod EKS
EKS Pod Identities est une fonctionnalité lancée lors de re:Invent 2023 qui vous permet d'attribuer un rôle IAM à un compte de service Kubernetes, sans avoir à configurer un fournisseur d'identité (IDP) Open Id Connect (OIDC) pour chaque cluster de votre compte AWS. Pour utiliser EKS Pod Identity, vous devez déployer un agent qui s'exécute en tant que DaemonSet pod sur chaque nœud de travail éligible. Cet agent est mis à votre disposition en tant que module complémentaire EKS et constitue une condition préalable à l'utilisation de la fonction EKS Pod Identity. Vos applications doivent utiliser une version prise en charge du SDK AWS pour utiliser cette fonctionnalité.
Lorsque les identités de pod EKS sont configurées pour un pod, EKS monte et actualise un jeton d'identité de pod sur/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
. Ce jeton sera utilisé par le SDK AWS pour communiquer avec l'agent EKS Pod Identity, qui utilise le jeton d'identité du pod et le rôle IAM de l'agent pour créer des informations d'identification temporaires pour vos pods en appelant l'AssumeRoleForPodIdentityAPI. Le jeton d'identité du pod livré à vos pods est un JWT émis par votre cluster EKS et signé cryptographiquement, avec les déclarations JWT appropriées à utiliser avec EKS Pod Identities.
Pour en savoir plus sur EKS Pod Identities, consultez ce blog
Il n'est pas nécessaire de modifier le code de votre application pour utiliser EKS Pod Identities. Les versions du SDK AWS prises en charge découvriront automatiquement les informations d'identification mises à disposition avec EKS Pod Identities en utilisant la chaîne de fournisseurs d'informations d'identification. À l'instar de l'IRSA, EKS pod identity définit des variables dans vos pods pour leur indiquer comment trouver les informations d'identification AWS.
Utilisation des rôles IAM pour EKS Pod Identities
-
EKS Pod Identities ne peut assumer directement qu'un rôle IAM appartenant au même compte AWS que le cluster EKS. Pour accéder à un rôle IAM dans un autre compte AWS, vous devez assumer ce rôle en configurant un profil dans la configuration de votre SDK ou dans le code de votre application.
-
Lorsque les identités du module EKS sont configurées pour les comptes de service, la personne ou le processus qui configure l'association d'identité du pod doit avoir les
iam:PassRole
droits requis pour ce rôle. -
Chaque compte de service ne peut être associé qu'à un seul rôle IAM via EKS Pod Identities, mais vous pouvez associer le même rôle IAM à plusieurs comptes de service.
-
Les rôles IAM utilisés avec EKS Pod Identities doivent autoriser le principal de
pods.eks.amazonaws.com
service à les assumer et à définir des balises de session. Voici un exemple de politique de confiance des rôles qui permet à EKS Pod Identities d'utiliser un rôle IAM :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:SourceOrgId": "${aws:ResourceOrgId}" } } } ] }
AWS recommande d'utiliser des clés de condition aws:SourceOrgId
pour se protéger contre le problème de confusion entre les services adjoints. Dans l'exemple de politique de confiance des rôles ci-dessus, ResourceOrgId
il s'agit d'une variable égale à l'ID d'organisation AWS Organizations de l'organisation AWS à laquelle appartient le compte AWS. EKS transmettra une valeur aws:SourceOrgId
égale à cette valeur lorsqu'il assumera un rôle auprès d'EKS Pod Identities.
Identités des pods ABAC et EKS
Lorsque EKS Pod Identities assume un rôle IAM, il définit les balises de session suivantes :
Tag de session EKS Pod Identities | Valeur |
---|---|
espace de noms kubernetes |
L'espace de noms dans lequel s'exécute le pod associé à EKS Pod Identities. |
kubernetes-service-account |
Le nom du compte de service Kubernetes associé à EKS Pod Identities |
eks-cluster-arn |
L'ARN du cluster EKS, par |
eks-cluster-name |
Nom du cluster EKS. Notez que les noms des clusters EKS peuvent être identiques dans votre compte AWS et ceux des clusters EKS dans d'autres comptes AWS. |
kubernetes-pod-name |
Nom du module dans EKS. |
kubernetes-pod-uid |
L'UID du pod dans EKS. |
Ces balises de session vous permettent d'utiliser le contrôle d'accès basé sur les attributs (ABAC) pour accorder l'accès à vos ressources AWS uniquement à des comptes de service Kubernetes spécifiques. Ce faisant, il est très important de comprendre que les comptes de service Kubernetes ne sont uniques qu'au sein d'un espace de noms, et que les espaces de noms Kubernetes ne sont uniques qu'au sein d'un cluster EKS. Ces balises de session sont accessibles dans les politiques AWS à l'aide de la clé de condition aws:PrincipalTag/<tag-key>
globale, telle que aws:PrincipalTag/eks-cluster-arn
Par exemple, si vous souhaitez accorder l'accès à un compte de service spécifique uniquement pour accéder à une ressource AWS de votre compte avec un IAM ou une politique de ressources, vous devez vérifier eks-cluster-arn
et kubernetes-namespace
étiqueter ainsi que kubernetes-service-account
pour vous assurer que seuls les comptes de service du cluster prévu ont accès à cette ressource, car d'autres clusters peuvent avoir un identifiant kubernetes-service-accounts
etkubernetes-namespaces
.
Cet exemple de politique de compartiment S3 accorde uniquement l'accès aux objets du compartiment S3 auquel il est attaché, uniquement si kubernetes-service-account
eks-cluster-arn
tous répondent aux valeurs attendues, lorsque le cluster EKS est hébergé dans le compte AWS111122223333
. kubernetes-namespace
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::ExampleBucket/*" ], "Condition": { "StringEquals": { "aws:PrincipalTag/kubernetes-service-account": "s3objectservice", "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-west-2:111122223333:cluster/ProductionCluster", "aws:PrincipalTag/kubernetes-namespace": "s3datanamespace" } } } ] }
Comparaison entre EKS Pod Identities et IRSA
EKS Pod Identities et IRSA sont les méthodes préférées pour fournir des informations d'identification AWS temporaires à vos pods EKS. À moins que vous n'ayez des cas d'utilisation spécifiques pour IRSA, nous vous recommandons d'utiliser EKS Pod Identities lorsque vous utilisez EKS. Ce tableau permet de comparer les deux fonctionnalités.
# | Identités du pod EKS | IRSA |
---|---|---|
Avez-vous besoin d'une autorisation pour créer un IDP OIDC dans vos comptes AWS ? |
Non |
Oui |
Nécessite une configuration IDP unique par cluster |
Non |
Oui |
Définit les balises de session pertinentes à utiliser avec ABAC |
Oui |
Non |
Nécessite un IAM : PassRole Check ? |
Oui |
Non |
Utilise le quota AWS STS de votre compte AWS ? |
Non |
Oui |
Peut accéder à d'autres comptes AWS |
Indirectement avec le chaînage de rôles |
Directement avec Sts : AssumeRoleWithWebIdentity |
Compatible avec AWS SDKs |
Oui |
Oui |
Nécessite le daemonset de l'agent Pod Identity sur les nœuds ? |
Oui |
Non |
Recommandations relatives aux identités et aux informations d'identification pour les pods EKS
Mettez à jour le daemonset aws-node pour utiliser IRSA
À l'heure actuelle, le daemonset aws-node est configuré pour utiliser un rôle attribué aux EC2 instances à attribuer aux pods. IPs Ce rôle inclut plusieurs politiques gérées par AWS, par exemple Amazoneks_CNI_Policy, qui autorisent effectivement tous les pods exécutés sur un nœud à accéder à des adresses EC2 ContainerRegistryReadOnly IP ou à extraire des images depuis ECR. attach/detach ENIs assign/unassign Comme cela présente un risque pour votre cluster, il est recommandé de mettre à jour le daemonset aws-node pour utiliser IRSA. Un script permettant de le faire se trouve dans le dépôt
Le daemonset aws-node prend en charge EKS Pod Identities dans les versions v1.15.5 et ultérieures.
Restreindre l'accès au profil d'instance attribué au nœud de travail
Lorsque vous utilisez IRSA ou EKS Pod Identities, cela met à jour la chaîne d'identification du pod pour utiliser d'abord IRSA ou EKS Pod Identities. Toutefois, le pod peut toujours hériter des droits du profil d'instance attribué au nœud de travail. Pour les pods qui n'ont pas besoin de ces autorisations, vous pouvez bloquer l'accès aux métadonnées de l'instance afin de garantir que vos applications disposent uniquement des autorisations dont elles ont besoin, et non de leurs nœuds.
Avertissement
Le blocage de l'accès aux métadonnées de l'instance empêchera les pods qui n'utilisent pas IRSA ou EKS Pod Identities d'hériter du rôle attribué au nœud de travail.
Vous pouvez bloquer l'accès aux métadonnées de l'instance en demandant à l'instance de IMDSv2 n'utiliser que celle-ci et en mettant à jour le nombre de sauts à 1, comme dans l'exemple ci-dessous. Vous pouvez également inclure ces paramètres dans le modèle de lancement du groupe de nœuds. Ne désactivez pas les métadonnées d'instance, car cela empêcherait des composants tels que le gestionnaire de terminaison de nœud et d'autres éléments qui dépendent des métadonnées d'instance de fonctionner correctement.
$ aws ec2 modify-instance-metadata-options --instance-id <value> --http-tokens required --http-put-response-hop-limit 1 ...
Si vous utilisez Terraform pour créer des modèles de lancement à utiliser avec des groupes de nœuds gérés, ajoutez le bloc de métadonnées pour configurer le nombre de sauts, comme indiqué dans cet extrait de code :
tf hl_lines="7" resource "aws_launch_template" "foo" { name = "foo" … metadata_options { http_endpoint = "enabled" http_tokens = "required" http_put_response_hop_limit = 1 instance_metadata_tags = "enabled" } …
Vous pouvez également bloquer l'accès d'un pod aux EC2 métadonnées en manipulant iptables sur le nœud. Pour plus d'informations sur cette méthode, consultez Limiter l'accès au service de métadonnées d'instance.
Si votre application utilise une ancienne version du SDK AWS qui ne prend pas en charge les identités IRSA ou EKS Pod, vous devez mettre à jour la version du SDK.
Étendre la politique de confiance des rôles IAM pour les rôles IRSA au nom du compte de service, à l'espace de noms et au cluster
La politique de confiance peut être étendue à un espace de noms ou à un compte de service spécifique au sein d'un espace de noms. Lorsque vous utilisez IRSA, il est préférable de rendre la politique de confiance des rôles aussi explicite que possible en incluant le nom du compte de service. Cela empêchera efficacement d'autres pods du même espace de noms d'assumer le rôle. La CLI le eksctl
fera automatiquement lorsque vous l'utiliserez pour créer des accounts/IAM rôles de service. Voir https://eksctl. io/usage/iamserviceaccounts
Lorsque vous travaillez directement avec IAM, cela ajoute une condition à la politique de confiance du rôle qui utilise des conditions pour garantir que la :sub
réclamation correspond à l'espace de noms et au compte de service que vous attendez. Par exemple, nous avions auparavant un jeton IRSA avec une sous-réclamation « system:serviceaccount:default:s3-read-only ». Il s'agit de l'default
espace de noms et du compte de service. s3-read-only
Vous devez utiliser une condition comme la suivante pour vous assurer que seul votre compte de service dans un espace de noms donné de votre cluster peut assumer ce rôle :
"Condition": { "StringEquals": { "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:aud": "sts.amazonaws.com", "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:sub": "system:serviceaccount:default:s3-read-only" } }
Utiliser un rôle IAM par application
Avec IRSA et EKS Pod Identity, il est recommandé de donner à chaque application son propre rôle IAM. Vous bénéficiez ainsi d'une meilleure isolation, car vous pouvez modifier une application sans en affecter une autre, et vous pouvez appliquer le principe du moindre privilège en n'accordant à une application que les autorisations dont elle a besoin.
Lorsque vous utilisez ABAC avec EKS Pod Identity, vous pouvez utiliser un rôle IAM commun à plusieurs comptes de service et vous fier à leurs attributs de session pour le contrôle d'accès. Cela est particulièrement utile lorsque vous travaillez à grande échelle, car ABAC vous permet de travailler avec moins de rôles IAM.
Lorsque votre application a besoin d'accéder à l'IMDS, utilisez IMDSv2 et augmentez la limite de sauts sur les EC2 instances à 2
IMDSv2nécessite que vous utilisiez une requête PUT pour obtenir un jeton de session. La demande PUT initiale doit inclure un TTL pour le jeton de session. Les nouvelles versions d'AWS SDKs géreront cela et le renouvellement automatique de ce jeton. Il est également important de savoir que la limite de sauts par défaut sur les EC2 instances est intentionnellement définie sur 1 pour empêcher le transfert IP. Par conséquent, les pods qui demandent un jeton de session exécuté sur des EC2 instances peuvent éventuellement expirer et recommencer à utiliser le flux de IMDSv1 données. EKS ajoute du support IMDSv2 en activant les versions v1 et v2 et en modifiant la limite de sauts à 2 sur les nœuds approvisionnés par eksctl ou avec les modèles officiels. CloudFormation
Désactiver le montage automatique des jetons de compte de service
Si votre application n'a pas besoin d'appeler l'API Kubernetes, définissez l'automountServiceAccountToken
attribut sur « false
in » PodSpec pour votre application ou corrigez le compte de service par défaut dans chaque espace de noms afin qu'il ne soit plus automatiquement monté sur les pods. Par exemple :
kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'
Utilisez des comptes de service dédiés pour chaque application
Chaque application doit disposer de son propre compte de service dédié. Cela s'applique aux comptes de service pour l'API Kubernetes ainsi qu'à IRSA et EKS Pod Identity.
Important
Si vous utilisez une blue/green approche de mise à niveau de cluster au lieu d'effectuer une mise à niveau de cluster sur place lorsque vous utilisez IRSA, vous devrez mettre à jour la politique de confiance de chacun des rôles IRSA IAM avec le point de terminaison OIDC du nouveau cluster. Lors d'une mise à niveau de blue/green cluster, vous créez un cluster exécutant une version plus récente de Kubernetes parallèlement à l'ancien cluster et vous utilisez un équilibreur de charge ou un maillage de services pour transférer facilement le trafic des services exécutés sur l'ancien cluster vers le nouveau cluster. Lorsque vous utilisez des mises à niveau de blue/green cluster avec EKS Pod Identity, vous devez créer des associations d'identité d'espace entre les rôles IAM et les comptes de service dans le nouveau cluster. Et mettez à jour la politique de confiance des rôles IAM si vous rencontrez une sourceArn
condition.
Exécuter l'application en tant qu'utilisateur non root
Les conteneurs s'exécutent en tant que root par défaut. Bien que cela leur permette de lire le fichier du jeton d'identité Web, l'exécution d'un conteneur en tant que root n'est pas considérée comme une bonne pratique. Vous pouvez également envisager d'ajouter l'spec.securityContext.runAsUser
attribut au PodSpec. La valeur de runAsUser
est une valeur arbitraire.
Dans l'exemple suivant, tous les processus du Pod s'exécuteront sous l'ID utilisateur spécifié dans le runAsUser
champ.
apiVersion: v1 kind: Pod metadata: name: security-context-demo spec: securityContext: runAsUser: 1000 runAsGroup: 3000 containers: - name: sec-ctx-demo image: busybox command: [ "sh", "-c", "sleep 1h" ]
Lorsque vous exécutez un conteneur en tant qu'utilisateur non root, cela empêche le conteneur de lire le jeton du compte de service IRSA car les autorisations 0600 [root] sont attribuées au jeton par défaut. Si vous mettez à jour le SecurityContext de votre conteneur pour inclure fsgroup=65534 [Nobody], cela permettra au conteneur de lire le jeton.
spec: securityContext: fsGroup: 65534
Dans Kubernetes 1.19 et versions ultérieures, cette modification n'est plus requise et les applications peuvent lire le jeton du compte de service IRSA sans l'ajouter au groupe Nobody.
Accorder l'accès le moins privilégié aux applications
Action Hero
Envisagez de définir une limite d'autorisations pour les rôles IAM utilisés avec IRSA et Pod Identities. Vous pouvez utiliser la limite d'autorisations pour vous assurer que les rôles utilisés par IRSA ou Pod Identities ne peuvent pas dépasser un niveau maximum d'autorisations. Pour un exemple de guide sur la prise en main des limites d'autorisations avec un exemple de politique de limites d'autorisations, veuillez consulter ce dépôt github
Vérifiez et révoquez les accès anonymes inutiles à votre cluster EKS
Idéalement, l'accès anonyme doit être désactivé pour toutes les actions d'API. L'accès anonyme est accordé en créant un RoleBinding ou ClusterRoleBinding pour le système utilisateur intégré de Kubernetes : anonymous. Vous pouvez utiliser l'outil rbac-lookup
./rbac-lookup | grep -P 'system:(anonymous)|(unauthenticated)' system:anonymous cluster-wide ClusterRole/system:discovery system:unauthenticated cluster-wide ClusterRole/system:discovery system:unauthenticated cluster-wide ClusterRole/system:public-info-viewer
Aucun rôle ClusterRole autre que system : ne public-info-viewer doit être lié à system:anonymous user ou system:unauthenticated group.
Il peut y avoir des raisons légitimes d'autoriser l'accès anonyme à des informations spécifiques APIs. Si tel est le cas pour votre cluster, assurez-vous que seules les informations spécifiques APIs sont accessibles aux utilisateurs anonymes et le fait de les exposer APIs sans authentification ne rend pas votre cluster vulnérable.
Avant la Kubernetes/EKS version 1.14, le groupe system:unauthenticated était associé par défaut à system:discovery et system:basic-user. ClusterRoles Notez que même si vous avez mis à jour votre cluster vers la version 1.14 ou supérieure, ces autorisations peuvent toujours être activées sur votre cluster, car les mises à jour du cluster ne les révoquent pas. Pour vérifier ceux qui ClusterRoles ont « system:unauthenticated » sauf system : public-info-viewer vous pouvez exécuter la commande suivante (nécessite jq util) :
kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | .metadata.name'
Et « system:unauthenticated » peut être supprimé de tous les rôles sauf « system : » en utilisant : public-info-viewer
kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | del(.subjects[] | select(.name =="system:unauthenticated"))' | kubectl apply -f -
Vous pouvez également le vérifier et le supprimer manuellement en utilisant kubectl describe et kubectl edit. Pour vérifier si system:unauthenticated group dispose des autorisations system:discovery sur votre cluster, exécutez la commande suivante :
kubectl describe clusterrolebindings system:discovery Name: system:discovery Labels: kubernetes.io/bootstrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate: true Role: Kind: ClusterRole Name: system:discovery Subjects: Kind Name Namespace ---- ---- --------- Group system:authenticated Group system:unauthenticated
Pour vérifier si system:unauthenticated group dispose de l'autorisation system:basic-user sur votre cluster, exécutez la commande suivante :
kubectl describe clusterrolebindings system:basic-user Name: system:basic-user Labels: kubernetes.io/bootstrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate: true Role: Kind: ClusterRole Name: system:basic-user Subjects: Kind Name Namespace ---- ---- --------- Group system:authenticated Group system:unauthenticated
Si system:unauthenticated group est lié à system:discovery et/ou system:basic-user ClusterRoles sur votre cluster, vous devez dissocier ces rôles de system:unauthenticated group. Modifiez system:discovery à ClusterRoleBinding l'aide de la commande suivante :
kubectl edit clusterrolebindings system:discovery
La commande ci-dessus ouvrira la définition actuelle de system:discovery ClusterRoleBinding dans un éditeur, comme indiqué ci-dessous :
# Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: "2021-06-17T20:50:49Z" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:discovery resourceVersion: "24502985" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery uid: b7936268-5043-431a-a0e1-171a423abeb6 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:discovery subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated - apiGroup: rbac.authorization.k8s.io kind: Group name: system:unauthenticated
Supprimez l'entrée pour system:unauthenticated group dans la section « Sujets » de l'écran de l'éditeur ci-dessus.
Répétez les mêmes étapes pour ClusterRoleBinding system:basic-user.
Réutilisez les sessions du SDK AWS avec IRSA
Lorsque vous utilisez IRSA, les applications écrites à l'aide du SDK AWS utilisent le jeton fourni à vos pods pour appeler afin de générer des informations sts:AssumeRoleWithWebIdentity
d'identification AWS temporaires. Cela est différent des autres services de calcul AWS, dans lesquels le service de calcul fournit des informations d'identification AWS temporaires directement à la ressource de calcul AWS, comme une fonction lambda. Cela signifie que chaque fois qu'une session du SDK AWS est initialisée, un appel AssumeRoleWithWebIdentity
est effectué vers AWS STS for. Si votre application évolue rapidement et initialise de nombreuses sessions du SDK AWS, il se peut que vous soyez confronté à une limitation de la part d'AWS STS, car votre code devra faire l'objet de nombreux appels. AssumeRoleWithWebIdentity
Pour éviter ce scénario, nous vous recommandons de réutiliser les sessions du SDK AWS au sein de votre application afin d'éviter AssumeRoleWithWebIdentity
les appels inutiles.
Dans l'exemple de code suivant, une session est créée à l'aide du SDK boto3 python, et cette même session est utilisée pour créer des clients et interagir avec Amazon S3 et Amazon SQS. AssumeRoleWithWebIdentity
n'est appelé qu'une seule fois, et le SDK AWS actualise les informations d'identification my_session
lorsqu'elles expirent automatiquement.
import boto3 = Create your own session my_session = boto3.session.Session() = Now we can create low-level clients from our session sqs = my_session.client('`sqs`') s3 = my_session.client('`s3`') s3response = s3.list_buckets() sqsresponse = sqs.list_queues() #print the response from the S3 and SQS APIs print("`s3 response:`") print(s3response) print("`—`") print("`sqs response:`") print(sqsresponse) ```
Si vous migrez une application depuis un autre service de calcul AWS, par exemple EC2 vers EKS avec IRSA, ce détail est particulièrement important. Sur les autres services de calcul, l'initialisation d'une session du SDK AWS n'appelle pas AWS STS sauf si vous le lui demandez.
Approches alternatives
Bien que les identités de pod IRSA et EKS soient les méthodes préférées pour attribuer une identité AWS à un pod, elles nécessitent que vous incluiez une version récente d'AWS SDKs dans votre application. Pour une liste complète de ceux SDKs qui prennent actuellement en charge l'IRSA, voir https://docs.aws.amazon.com/eks/latest/userguide/iam- roles-for-service-accounts -minimum-sdk.html, pour EKS Pod Identities, voir https://docs.aws.amazon.com/eks/latest/userguide/pod- id-minimum-sdk .html. Si vous avez une application que vous ne pouvez pas mettre à jour immédiatement avec un SDK compatible, plusieurs solutions communautaires sont disponibles pour attribuer des rôles IAM aux pods Kubernetes, notamment kube2iam et kiam.
Si vous devez utiliser l'une de ces solutions non fournies par AWS, veuillez faire preuve de diligence raisonnable et vous assurer que vous comprenez les implications en matière de sécurité.
Outils et ressources
-
Atelier d'immersion sur la sécurité Amazon EKS - Identity and Access Management
-
Modèle de plans Terraform EKS - Cluster Amazon EKS entièrement privé
-
Modèle de plans Terraform EKS - Authentification unique Okta pour Amazon EKS Cluster
-
rbac.dev
Une liste de ressources supplémentaires, notamment des blogs et des outils, pour Kubernetes RBAC