kubernetes-sigs/aws-iam-authenticatorUn outil pour utiliser les identifiants IAM AWS afin de s'authentifier à un cluster Kubernetes.
Un outil pour utiliser les identifiants AWS IAM afin de s'authentifier auprès d'un cluster Kubernetes. Le travail initial sur cet outil a été mené par Heptio. Le projet reçoit des contributions de plusieurs ingénieurs de la communauté et est actuellement maintenu par Heptio et les ingénieurs OSS d'Amazon EKS.
Si vous êtes un administrateur exécutant un cluster Kubernetes sur AWS, vous devez déjà gérer les identifiants AWS IAM pour provisionner et mettre à jour le cluster. En utilisant AWS IAM Authenticator for Kubernetes, vous évitez d'avoir à gérer un identifiant séparé 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 for Kubernetes peut simplifier votre processus de bootstrap.
Vous n'aurez pas à faire sortir clandestinement votre identifiant administrateur initial de votre cluster nouvellement installé.
Au lieu de cela, vous pouvez créer un rôle dédié KubernetesAdmin lors du provisionnement du cluster et configurer Authenticator pour autoriser les connexions des administrateurs de cluster.
En supposant que vous ayez un cluster en cours d'exécution sur AWS et que vous souhaitiez ajouter la prise en charge d'AWS IAM Authenticator for Kubernetes, vous devez :
Tout d'abord, vous devez créer un ou plusieurs rôles IAM qui seront mappés à des utilisateurs/groupes dans votre cluster Kubernetes. Le moyen le plus simple de procéder est de vous connecter à la console AWS :
Cela créera un rôle IAM sans autorisations qui peut être assumé par des utilisateurs/rôles autorisés dans votre compte. Notez le nom de ressource Amazon (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 :```sh
ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')
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":{}}]}')
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 (par exemple un rôle d'accès entre 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 fonctionner sur chacun de vos nœuds maîtres en tant que DaemonSet avec le 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`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example.yaml).
Avant de l'appliquer, mettez à jour ces valeurs pour votre cluster :
- Remplacez les ARN IAM factices (`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 du plan de contrôle.
Ensuite, déployez-le :```sh
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 que le pod est exécuté sur un nœud du plan de contrôle, la commande 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).
Si vous créez un installeur 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 exécuter cette commande sur chaque nœud maître avant de démarrer le serveur API. Vous pouvez également les générer avant de provisionner les nœuds maîtres et les installer dans les chemins hôtes 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.
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érera un fichier de configuration du webhook et l'enregistrera sur le système de fichiers de l'hôte.
Vous devrez ajouter une seule option 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/` soit monté dans votre pod serveur API.
Vous devrez peut-être aussi redémarrer le démon kubelet sur votre nœud maître pour prendre en compte la définition de pod statique mise à jour:```
systemctl restart kubelet.service
Le comportement par défaut du serveur est de récupérer les correspondances exclusivement depuis les champs mapUsers et mapRoles de son fichier de configuration. Voir Format complet de configuration ci-dessous pour plus de détails.