
Un outil pour utiliser les identifiants IAM AWS afin de s'authentifier à un cluster 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.
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.
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 :
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 :
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 :
mapUsers ci-dessous).mapRoles ci-dessous).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 :
arn:aws:iam::000000000000:...) dans config.yaml.clusterID sur une valeur unique pour votre cluster.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).
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.
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
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.