Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

FluxContactConfidentialité© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
aws-iam-authenticator — Un outil pour utiliser les identifiants IAM AWS afin de s'authentifier à un cluster Kubernetes. | Kitploit
Outils/GitHubGitHub/kubernetes-sigs/aws-iam-authenticator
Authentification et AutorisationSécurité de l'Infrastructure CloudSécurité CloudGestion des Identités et des Accès (IAM)
GitHubkubernetes-sigs/aws-iam-authenticator

aws-iam-authenticator

Un outil pour utiliser les identifiants IAM AWS afin de s'authentifier à un cluster Kubernetes.

Voir le dépôt

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
2.3k45046il y a 2 joursVérifié par Kitploit

AWS IAM Authenticator pour Kubernetes

Un outil permettant d'utiliser les identifiants AWS IAM pour s'authentifier auprès d'un cluster Kubernetes. Les travaux initiaux sur cet outil ont été menés par Heptio. Le projet reçoit les contributions de plusieurs ingénieurs de la communauté et est actuellement maintenu par Heptio et les ingénieurs OSS d'Amazon EKS.

Table des matières

  • Pourquoi voudrais-je cela ?
  • Comment l'utiliser ?
  • Utilisation avec Kops
  • Comment cela fonctionne-t-il ?
  • Qu'est-ce qu'un cluster ID ?
  • Spécification des identifiants et utilisation des profils AWS
  • Autorisation de l'API depuis l'extérieur d'un cluster
  • Dépannage
  • Format de configuration complet
  • Développement
  • Communauté, discussions, contributions et support

Pourquoi voudrais-je cela ?

Si vous êtes un administrateur exploitant un cluster Kubernetes sur AWS, vous devez déjà gérer des identifiants AWS IAM pour provisionner et mettre à jour le cluster. En utilisant AWS IAM Authenticator pour Kubernetes, vous évitez d'avoir à gérer un identifiant distinct pour l'accès à Kubernetes. AWS IAM offre également un certain nombre de propriétés intéressantes, telles qu'une piste d'audit hors bande (via CloudTrail) et l'application de la 2FA/MFA.

Si vous construisez un installateur Kubernetes sur AWS, AWS IAM Authenticator pour Kubernetes peut simplifier votre processus d'amorçage. Vous n'aurez pas besoin d'exfiltrer tant bien que mal votre identifiant administrateur initial de manière sécurisée hors de votre cluster nouvellement installé. À la place, vous pouvez créer un rôle dédié KubernetesAdmin au moment du provisionnement du cluster et configurer Authenticator pour autoriser les connexions des administrateurs du cluster.

Comment l'utiliser ?

En supposant que vous disposez d'un cluster en cours d'exécution sur AWS et que vous souhaitez ajouter le support d'AWS IAM Authenticator pour Kubernetes, vous devez :

  1. Créer un rôle IAM que vous utiliserez pour identifier les utilisateurs.
  2. Exécuter le serveur Authenticator en tant que DaemonSet.
  3. Configurer votre serveur API pour qu'il communique avec Authenticator.
  4. Configurer kubectl pour utiliser les jetons d'Authenticator.

1. Créer un rôle IAM

Tout d'abord, vous devez créer un ou plusieurs rôles IAM qui seront associés à des utilisateurs/groupes au sein de votre cluster Kubernetes. La façon la plus simple de procéder est de se connecter à la console AWS :

  • Choisissez l'option « Role for cross-account access » / « Provide access between AWS accounts you own ».
  • Collez votre numéro d'identifiant de compte AWS (disponible en haut à droite dans la console).
  • Votre rôle n'a besoin d'aucune politique supplémentaire attachée.

Cela créera un rôle IAM sans permissions qui peut être assumé par des utilisateurs/rôles autorisés dans votre compte. Notez l'Amazon Resource Name (ARN) de votre rôle, dont vous aurez besoin ci-dessous.

Vous pouvez également effectuer cette opération en une seule étape à l'aide de l'AWS CLI au lieu de la console AWS :

# get your account ID
ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')

# define a role trust policy that opens the role to users in your account (limited by IAM policy)
POLICY=$(echo -n '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::'; echo -n "$ACCOUNT_ID"; echo -n ':root"},"Action":"sts:AssumeRole","Condition":{}}]}')

# create a role named KubernetesAdmin (will print the new role's ARN)
aws iam create-role \
  --role-name KubernetesAdmin \
  --description "Kubernetes administrator role (for AWS IAM Authenticator for Kubernetes)." \
  --assume-role-policy-document "$POLICY" \
  --output text \
  --query 'Role.Arn'

Vous pouvez également ignorer cette étape et utiliser :

  • Un rôle existant (tel qu'un rôle d'accès inter-comptes).
  • Un utilisateur IAM (voir mapUsers ci-dessous).
  • Une instance EC2 ou un rôle fédéré (voir mapRoles ci-dessous).

2. Exécuter le serveur

Le serveur est conçu pour s'exécuter sur chacun de vos nœuds maîtres en tant que DaemonSet avec mise en réseau de l'hôte afin de pouvoir exposer un port localhost.

Pour un exemple de configuration ConfigMap et DaemonSet, voir deploy/example.yaml. Avant de l'appliquer, mettez à jour ces valeurs pour votre cluster :

  • Remplacez les ARN IAM fictifs (arn:aws:iam::000000000000:...) dans config.yaml.
  • Définissez clusterID sur une valeur unique pour votre cluster.
  • Vérifiez que les règles de planification du DaemonSet correspondent aux labels/taints de vos nœuds control-plane.

Déployez-le ensuite :

kubectl apply -f deploy/example.yaml
kubectl -n kube-system rollout status daemonset/aws-iam-authenticator
kubectl -n kube-system get pods -l k8s-app=aws-iam-authenticator

Une fois le pod en cours d'exécution sur un nœud control-plane, le aws-iam-authenticator server créera le kubeconfig du webhook sur l'hôte à l'emplacement /etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml (ou le chemin configuré via --generate-kubeconfig).

(Facultatif) Pré-générer un certificat, une clé et un kubeconfig

Si vous construisez un installateur automatisé, vous pouvez également pré-générer facilement les fichiers de certificat, de clé et de kubeconfig du webhook à l'aide de aws-iam-authenticator init. Cette commande générera les fichiers et les placera dans les répertoires de sortie configurés.

Vous pouvez l'exécuter sur chaque nœud master avant de démarrer le serveur API. Vous pouvez également les générer avant de provisionner les nœuds master et les installer dans les chemins d'hôte appropriés.

Si vous ne pré-générez pas les fichiers, aws-iam-authenticator server les générera à la demande. Cela fonctionne, mais nécessite de redémarrer votre serveur API Kubernetes après l'installation.

3. Configurer votre serveur API pour communiquer avec le serveur

L'API Kubernetes s'intègre à AWS IAM Authenticator for Kubernetes à l'aide d'un webhook d'authentification par jeton. Lorsque vous exécutez aws-iam-authenticator server, il génère un fichier de configuration de webhook et l'enregistre sur le système de fichiers de l'hôte. Vous devrez ajouter un seul indicateur supplémentaire à la configuration de votre serveur API :

--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml

Sur de nombreux clusters, le serveur API s'exécute en tant que pod statique. Vous pouvez ajouter le flag à /etc/kubernetes/manifests/kube-apiserver.yaml. Assurez-vous que le répertoire hôte /etc/kubernetes/aws-iam-authenticator/ est monté dans votre pod de serveur API. Vous devrez peut-être également redémarrer le démon kubelet sur votre nœud maître pour prendre en compte la définition mise à jour du pod statique :

systemctl restart kubelet.service

4. Créer des mappages entre rôles/utilisateurs IAM et utilisateurs/groupes Kubernetes

Le comportement par défaut du serveur est de récupérer les mappages exclusivement à partir des champs mapUsers et mapRoles de son fichier de configuration. Voir Format complet de configuration ci-dessous pour plus de détails.

Télécharger l’outil