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

La gestion des identités et des accès (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 https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html IAM.

Contrôle de l'accès aux clusters EKS

Le projet Kubernetes prend en charge différentes stratégies pour authentifier les requêtes adressées au service kube-apiserver, par exemple Bearer Tokens, certificats, OIDC, etc. X.509 EKS dispose actuellement d'un support natif pour l'authentification par jeton Webhook, pour les jetons de compte de service et, depuis le 21 février 2021, pour l'authentification OIDC.

La stratégie d'authentification du webhook appelle un webhook qui vérifie les jetons du porteur. Sur EKS, ces jetons porteurs sont générés par l'AWS CLI ou le client aws-iam-authenticator lorsque vous exécutez des commandes. kubectl 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 son compte, Arn, et UserId au serveur 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> --region <region>

La sortie doit ressembler à ceci :

{
    "kind": "ExecCredential",
    "apiVersion": "client.authentication.k8s.io/v1alpha1",
    "spec": {},
    "status": {
        "expirationTimestamp": "2024-12-20T17:38:48Z",
        "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMudXMtd2VzdC0yLmFtYXpvbmF3cy5jb20vP0FjdGlvbj1HZ...."
    }
}

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. une chaîne codée en base64. Une fois décodée, la chaîne doit ressembler à quelque chose de similaire à 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. Toutefoiskubectl, si vous utilisez le tableau de bord Kubernetes, vous devrez générer un nouveau jeton et vous ré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-systemespace de noms pour déterminer le groupe RBAC à associer à l'utilisateur. Le aws-auth ConfigMap 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 Kubernetes RBAC. Les groupes RBAC peuvent être référencés dans RoleBindings Kubernetes ou. ClusterRoleBindings Ils sont similaires aux rôles IAM en ce sens qu'ils définissent un ensemble d'actions (verbes) qui peuvent être effectuées sur un ensemble de ressources Kubernetes (objets).

CloudWatch requête pour aider les utilisateurs à identifier les clients qui envoient des demandes au point de terminaison STS global

Exécutez CloudWatch la requête ci-dessous pour obtenir le point de terminaison sts. Si stsendpoint est égal à « sts.amazonaws.com », il s'agit d'un point de terminaison STS global. Si stsendpoint est égal à « sts ». <region>.amazonaws.com », il s'agit alors d'un point de terminaison STS régional.

fields @timestamp, @message, @logStream, @log,stsendpoint
| filter @logStream like /authenticator/
| filter @message like /stsendpoint/
| sort @timestamp desc
| limit 10000

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 Kubernetes RBAC, éliminant ainsi le besoin de basculer entre les API AWS et Kubernetes ou de modifier les API 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 automatiquement accordées au principal AWS IAM utilisé pour créer le cluster.

Cette API repose sur deux concepts :

Au lancement, Amazon EKS ne prend en charge que 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 prenant en charge l'autorisation et la transmission (mais pas le refus) des décisions de Kubernetes AuthZ concernant les requêtes du serveur d'API. Une décision de refus est prise lorsque les autorités RBAC et Amazon EKS en amont 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 :

Pour commencer, les administrateurs de clusters peuvent créer ou mettre à jour des clusters Amazon EKS, en définissant l'authentification préférée API_AND_CONFIG_MAP ou la API méthode d'authentification et en définissant des 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 permettant de créer un cluster Amazon EKS 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 la 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 ouCONFIG_MAP, et également de 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 aux RBAC de Kubernetes comme suit.

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

L'aws-auth ConfigMap (obsolète)

L'intégration de Kubernetes à l'authentification AWS peut notamment se faire via le aws-auth ConfigMap, qui se trouve dans l'espace de noms. kube-system Il est chargé de mapper l'authentification AWS IAM Identities (utilisateurs, groupes et rôles) à l'autorisation de contrôle d'accès basé sur les rôles (RBAC) de Kubernetes. Le aws-auth ConfigMap est automatiquement créé dans votre cluster Amazon EKS pendant 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 un accès RBAC aux principaux IAM.

Pour vérifier 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-authConfigMap.

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 sous le mapRoles bloc, qui est essentiellement composé de 3 paramètres. ConfigMap

Il est également possible de mapper les autorisations pour les utilisateurs AWS IAM, en définissant un nouveau bloc de configuration pourmapUsers, data dans le cadre du aws-authConfigMap, le remplacement du paramètre rolearn pour userarn, mais il est toujours recommandé de le remplacer par un 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, car il s'agit d'une configuration très sensible, et une configuration inexacte peut vous empêcher de rejoindre votre cluster Amazon EKS. Consultez la sous-section Utiliser les outils pour apporter des modifications à l'authentification aws-auth ConfigMap ci-dessous pour plus de détails.

Avantages par rapport à la gestion des ConfigMap-based accès

Recommandations relatives à l'accès au cluster

Combinez IAM Identity Center avec l'API CAM

Rendre le point de terminaison du cluster EKS privé

Par défaut, lorsque vous approvisionnez 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 vous impose de restreindre l'accès à l'API depuis Internet ou vous empêche d'acheminer le trafic en dehors du cluster VPC, vous pouvez :

N'utilisez pas de jeton de compte de service pour vous authentifier

Un jeton de compte de service est un identifiant statique à longue durée de vie. 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é. Il se peut que vous deviez parfois accorder une exception pour les applications qui doivent utiliser l'API Kubernetes depuis l'extérieur du cluster, par exemple une CI/CD application de pipeline. Si de telles applications s'exécutent sur une infrastructure AWS, telle que des instances EC2, envisagez d'utiliser un profil d'instance et de le mapper à un rôle Kubernetes RBAC.

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 à un utilisateur IAM 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 nom de cet utilisateur qui correspond aws-auth ConfigMap à un groupe Kubernetes RBAC spécifique.

Supprimez les autorisations cluster-admin du principal créateur du cluster

Par défaut, les clusters Amazon EKS sont créés avec une cluster-admin autorisation permanente liée au principal créateur du cluster. Grâce à l'API Cluster Access Manager, il est possible de créer des clusters sans que cette autorisation soit définie surfalse, lors --access-config bootstrapClusterCreatorAdminPermissions de l'utilisation API_AND_CONFIG_MAP ou en 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 permet 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-adminautorisation.

$ 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 bris de verre où 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 via le 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 scénario de bris de verre, 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 nécessitant un accès augmente.

Si vous utilisez toujours aws-auth ConfigMap comme méthode d'authentification, lorsque vous attribuez des autorisations RBAC K8s à un rôle IAM, vous devez inclure \ {{SessionName}} dans votre nom d'utilisateur. De cette façon, 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 en même temps que le CloudTrail journal.

- rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testRole
  username: testRole:{{SessionName}}
  groups:
    - system:masters

Utiliser 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 et ne ClusterRoleBindings 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 à moins que cela ne soit absolument nécessaire. Si vous ne savez pas quelles autorisations attribuer, pensez à utiliser un outil tel que audit2rbac pour générer automatiquement des rôles et des liaisons en fonction des appels d'API observés dans le journal d'audit Kubernetes.

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, se voit automatiquement accorder des system:masters autorisations dans la configuration RBAC du cluster. Même s'il s'agit d'une bonne pratique de supprimer cette autorisation, comme décrit ici si vous utilisez la méthode CONFIG_MAP d'authentification sur laquelle vous vous basez 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 à attribuer à d'autres utilisateurs ou entités, et d'auditer régulièrement les autorisations, les politiques et les personnes ayant accès à ce rôle pour déclencher le pipeline. En outre, ce rôle ne doit pas être utilisé pour effectuer des actions de routine sur le cluster, mais uniquement pour les 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 être autorisés à accéder 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 privilèges élevés temporaires/en cas de panne de verre pour les scénarios dans lesquels le cluster serait autrement inaccessible. Cela peut être particulièrement utile dans les clusters pour lesquels aucun accès utilisateur direct n'est 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 que kubectl-who-can ou rbac-lookup pour examiner les rôles liés à un compte de service, à un utilisateur ou à un groupe en particulier. Nous aborderons ce sujet plus en détail lorsque nous aborderons la section sur l'audit. Vous trouverez d'autres idées dans cet article de NCC Group.

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 permettant d'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

Faire 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 la eksctl documentation

https://github.com/keikoproj/aws-authaws-auth par keikoproj

aws-authby keikoproj inclut à la fois une bibliothèque CLI et une bibliothèque Go.

Téléchargez et consultez l'aide de l'interface de ligne de commande :

$ go get github.com/keikoproj/aws-auth
...
$ aws-auth help
...

Vous pouvez également l'installer aws-auth avec le gestionnaire de plugins krew pour kubectl.

$ kubectl krew install aws-auth
...
$ kubectl aws-auth
...

Consultez la documentation aws-auth GitHub pour plus d'informations, y compris la bibliothèque Go.

Interface de ligne de commande AWS IAM Authenticator

Le aws-iam-authenticator projet inclut une interface de ligne de commande pour mettre à jour leConfigMap.

Téléchargez un communiqué sur GitHub.

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 de l'authentification et de la 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 une usurpation d'identité Kubernetes. https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation Des articles concernant deux de ces solutions ont été publiés sur le blog AWS Open Source :

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, l'AWS CLI v2.0 inclut une option permettant de créer un profil nommé qui permet d'associer facilement une session SSO à votre session CLI actuelle et d'assumer un rôle IAM. Sachez que vous devez assumer un rôle avant de vous lancer 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 ont besoin d'une autorisation pour appeler l'API Kubernetes afin de fonctionner correctement. Par exemple, le contrôleur AWS Load Balancer doit être en mesure de répertorier les points de terminaison d'un service. Le contrôleur doit également être capable d'invoquer les API AWS pour provisionner et configurer un ALB. Dans cette section, nous explorerons les meilleures pratiques pour attribuer des droits et des privilèges aux Pods.

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 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 de 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 de 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 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 API Kubernetes, un compte de service doit être attribué au Pod qui lui accorde explicitement l'autorisation d'appeler ces API. À l'instar des directives relatives à l'accès des utilisateurs, le rôle ou ClusterRole lié à un compte de service doit être limité aux ressources et méthodes de l'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 spec.serviceAccountName dans le champ d'un Pod 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.

Rôles IAM pour les comptes de service (IRSA)

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 Projection du volume des jetons de compte de service. Lorsque les pods sont configurés avec un compte de service qui fait référence à un rôle IAM, le serveur d'API Kubernetes appelle le point de terminaison public OIDC pour le cluster au démarrage. Le point de terminaison signe cryptographiquement le jeton OIDC émis par Kubernetes et le jeton qui en résulte est monté en tant que volume. Ce jeton signé permet au Pod d'appeler le rôle IAM associé aux API AWS. Lorsqu'une API AWS est invoquée, les kits SDK AWS appellentsts: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 pour é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 qui ressemble à 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 fait automatiquement pivoter le jeton projeté lorsqu'il dépasse 80 % de son TTL total, ou après 24 heures. Les kits SDK AWS 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 qu'EKS Add-on et constitue une condition préalable à l'utilisation de la fonctionnalité 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 à/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é de pod livré à vos pods est un JWT émis par votre cluster EKS et signé cryptographiquement, avec les revendications 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 au sein de vos pods pour leur indiquer comment trouver les informations d'identification AWS.

Utilisation des rôles IAM pour EKS Pod Identities

{
  "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, par exemple, aws:SourceOrgId pour vous protéger contre le problème de confusion entre les administrateurs entre les services. Dans l'exemple de politique de confiance des rôles ci-dessus, la variable ResourceOrgId est égale à l'ID d'organisation AWS Organizations de l'organisation AWS à laquelle appartient le compte AWS. EKS transmettra une valeur aws:SourceOrgId égale à celle-ci lorsqu'il assumera un rôle avec 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 :

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 une politique IAM ou en matière de ressources, vous devez vérifier eks-cluster-arn et kubernetes-namespace baliser kubernetes-service-account pour vous assurer que seuls les comptes de service du cluster concerné ont accès à cette ressource, car d'autres clusters peuvent avoir un accès identique kubernetes-service-accounts etkubernetes-namespaces.

Cet exemple de politique de compartiment S3 n'autorise l'accès aux objets du compartiment S3 auquel il est attaché que si kubernetes-service-account eks-cluster-arn tous répondent aux valeurs attendues, où 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"
                }
            }
        }
    ]
}

Les identités des pods EKS comparées à celles de l'IRSA

Les identités de pod EKS et IRSA sont les méthodes préférées pour fournir des informations d'identification AWS temporaires à vos espaces 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 caractéristiques.

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 instances EC2 afin d'attribuer des adresses IP aux pods. Ce rôle inclut plusieurs politiques gérées par AWS, par exemple Amazoneks_CNI_Policy, EC2ContainerRegistryReadOnly qui autorisent efficacement tous les pods exécutés sur un nœud à accéder à des attach/detach ENI, à des assign/unassign adresses IP ou à extraire des images depuis ECR. Comme cela présente un risque pour votre cluster, il est recommandé de mettre à jour le daemonset aws-node pour utiliser IRSA. Un script pour ce faire se trouve dans le référentiel de ce guide.

Le daemonset aws-node prend en charge les identités de pod EKS 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'informations d'identification du pod pour utiliser d'abord les identités de pod IRSA ou EKS. Toutefois, le pod peut toujours hériter des droits du profil d'instance attribué au nœud de travail. Pour les espaces qui n'ont pas besoin de ces autorisations, vous pouvez bloquer l'accès aux métadonnées de l'instance afin de vous assurer que vos applications ne disposent que des autorisations dont elles ont besoin, et non de leurs nœuds.

Vous pouvez bloquer l'accès aux métadonnées de l'instance en demandant à celle-ci d'utiliser uniquement IMDSv2 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 reposent sur les métadonnées de l'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 métadonnées EC2 en manipulant iptables sur le nœud. Pour plus d'informations sur cette méthode, consultez la section Limitation de 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 de pod IRSA ou EKS, vous devez mettre à jour la version du SDK.

Étendez 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 ce rôle. L'interface de ligne de commande le fait eksctl automatiquement lorsque vous l'utilisez pour créer des accounts/IAM rôles de service. Voir https://eksctl.io/usage/iamserviceaccounts/ pour plus d'informations.

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-revendication « system:serviceaccount:default:s3-read-only ». Il s'agit de l'defaultespace de noms et du compte de service. s3-read-only Vous pouvez 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. Cela vous confère une meilleure isolation car vous pouvez modifier une application sans affecter une autre, et vous permet d'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 à IMDS, utilisez IMDSv2 et augmentez la limite de sauts sur les instances EC2 à 2

IMDSv2 né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 des kits SDK AWS géreront ce problème et le renouvellement de ce jeton automatiquement. Il est également important de savoir que la limite de sauts par défaut sur les instances EC2 est intentionnellement définie sur 1 pour empêcher le transfert IP. Par conséquent, les pods qui demandent un jeton de session qui sont exécutés sur des instances EC2 peuvent éventuellement expirer et revenir à l'utilisation du flux de données IMDSv1. EKS ajoute le support IMDSv2 en activant à la fois la v1 et la v2 et en modifiant la limite de sauts à 2 sur les nœuds provisionné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'automountServiceAccountTokenattribut sur «  PodSpec pour votre application » ou corrigez le compte de service par défaut dans chaque espace de noms afin qu'il ne soit plus monté automatiquement sur les pods. false 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.

Exécutez 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.runAsUserattribut au PodSpec. La valeur de runAsUser est une valeur arbitraire.

Dans l'exemple suivant, tous les processus du Pod seront exécutés 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 celui-ci est doté des autorisations 0600 [root] 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 les ajouter au groupe Nobody.

Accorder l'accès le moins privilégié aux applications

Action Hero est un utilitaire que vous pouvez exécuter parallèlement à votre application pour identifier les appels d'API AWS et les autorisations IAM correspondantes dont votre application a besoin pour fonctionner correctement. Il est similaire à IAM Access Advisor dans la mesure où il vous permet de limiter progressivement l'étendue des rôles IAM attribués aux applications. Consultez la documentation sur l'octroi de l'accès le moins privilégié aux ressources AWS pour plus d'informations.

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 des 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 https://github.com/aws-samples/example-permissions-boundary github.

Vérifiez et révoquez l'accès anonyme inutile à votre cluster EKS

Idéalement, l'accès anonyme devrait être désactivé pour toutes les actions de l'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 pour identifier les autorisations dont dispose system:anonymous user sur votre cluster :

./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 ou ClusterRole autre que system:public-info-viewer ne 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 API spécifiques. Si tel est le cas pour votre cluster, assurez-vous que seules ces API spécifiques sont accessibles par un utilisateur anonyme et le fait d'exposer ces API sans authentification ne rend pas votre cluster vulnérable.

Avant la Kubernetes/EKS version 1.14, le groupe system:unauthenticated était associé à system:discovery et system:basic-user par défaut. 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 révoquent pas ces autorisations. Pour vérifier lesquels ClusterRoles ont « system:unauthenticated » à l'exception de 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:public-info-viewer » en utilisant :

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 à l'aide de kubectl describe et kubectl edit. Pour vérifier si le groupe system:unauthenticated 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 le groupe system:unauthenticated 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 le groupe system:unauthenticated est lié à system:discovery and/or system:basic-user ClusterRoles sur votre cluster, vous devez dissocier ces rôles du groupe system:unauthenticated. Modifiez system:discovery à ClusterRoleBinding l'aide de la commande suivante :

kubectl edit clusterrolebindings system:discovery

La commande ci-dessus ouvre 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 « 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éutiliser 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 les appeler afin de générer des informations sts:AssumeRoleWithWebIdentity d'identification AWS temporaires. Ceci 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 AWS SDK est initialisée, un appel à AWS STS for AssumeRoleWithWebIdentity est effectué. Si votre application évolue rapidement et initialise de nombreuses sessions du SDK AWS, vous risquez de rencontrer des problèmes de limitation de la part d'AWS STS, car votre code sera soumis à de nombreux appels. AssumeRoleWithWebIdentity

Pour éviter ce scénario, nous vous recommandons de réutiliser les sessions du SDK AWS dans votre application afin d'éviter d'effectuer AssumeRoleWithWebIdentity des appels inutiles.

Dans l'exemple de code suivant, une session est créée à l'aide du SDK python boto3, et cette même session est utilisée pour créer des clients et interagir avec Amazon S3 et Amazon SQS. AssumeRoleWithWebIdentityn'est appelé qu'une seule fois, et le SDK AWS actualisera les informations d'identification my_session lorsqu'elles expireront 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 d'un autre service de calcul AWS, tel qu'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 instruction contraire de votre part.

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 espace, elles nécessitent que vous incluiez une version récente des kits SDK AWS dans votre application. Pour une liste complète des SDK qui prennent actuellement en charge l'IRSA, voirhttps://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. https://github.com/jtblin/kube2iam https://github.com/uswitch/kiam Bien qu'AWS n'approuve, ne tolère ni ne soutienne l'utilisation de ces solutions, celles-ci sont fréquemment utilisées par l'ensemble de la communauté pour obtenir des résultats similaires à ceux d'IRSA et d'EKS Pod Identities.

Si vous devez utiliser l'une de ces solutions qui ne sont pas fournies par AWS, faites preuve de diligence raisonnable et assurez-vous de bien comprendre les implications en termes de sécurité.

Outils et ressources