kubernetes-sigs/aws-iam-authenticatorUn outil pour utiliser les identifiants IAM AWS afin de s'authentifier à un cluster Kubernetes.
# 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 ?](#why-do-i-want-this)
- [Comment l'utiliser ?](#how-do-i-use-it)
- [Utilisation avec Kops](#kops-usage)
- [Comment cela fonctionne-t-il ?](#how-does-it-work)
- [Qu'est-ce qu'un cluster ID ?](#what-is-a-cluster-id)
- [Spécification des identifiants et utilisation des profils AWS](#specifying-credentials--using-aws-profiles)
- [Autorisation de l'API depuis l'extérieur d'un cluster](#api-authorization-from-outside-a-cluster)
- [Dépannage](#troubleshooting)
- [Format de configuration complet](#full-configuration-format)
- [Développement](#development)
- [Communauté, discussions, contributions et support](#community-discussion-contribution-and-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 :
```sh
# 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`](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 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 :
```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 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](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication).
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](#full-configuration-format) ci-dessous pour plus de détails.
À l'aide du drapeau `--backend-mode`, vous pouvez configurer le serveur pour récupérer
les mappages depuis deux backends supplémentaires : une ConfigMap de style EKS
(`--backend-mode=EKSConfigMap`) ou des ressources personnalisées `IAMIdentityMapping`
(`--backend-mode=CRD`). Le backend par défaut, le fichier de configuration du serveur
monté par le pod du serveur, correspond à `--backend-mode=MountedFile`.
Vous pouvez passer une liste séparée par des virgules de ces backends pour que le serveur les recherche
dans l'ordre. Par exemple, avec `--backend-mode=EKSConfigMap,MountedFile`, le
serveur recherchera dans la ConfigMap de style EKS les mappages puis, s'il ne
trouve pas de mappage pour le rôle/utilisateur IAM donné, dans le fichier de configuration du serveur. Si un
mappage pour le même rôle/utilisateur IAM existe dans plusieurs backends, le serveur
utilisera le mappage du backend qui apparaît en premier dans la liste séparée par des virgules.
Dans cet exemple, si un mappage est trouvé dans la ConfigMap EKS, il sera
utilisé qu'un mappage en doublon ou conflictuel existe ou non dans le fichier de configuration
du serveur.
Notez que lors de la définition d'un seul backend, le serveur récupérera *uniquement* depuis
celui-ci et ignorera les autres même s'ils existent. Par exemple, avec
`--backend-mode=CRD`, le serveur récupérera *uniquement* depuis les `IAMIdentityMappings`
et ignorera le fichier monté et la ConfigMap EKS.
#### `MountedFile`
Il s'agit du backend de mappages par défaut, suffisant pour la plupart des utilisateurs. Voir
[Format complet de configuration](#full-configuration-format) ci-dessous pour plus de détails.
#### `CRD` (alpha)
Ce backend modélise chaque mappage IAM comme une [ressource personnalisée
Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) `IAMIdentityMapping`.
Cette approche vous permet de maintenir les mappages de manière native Kubernetes à l'aide de
kubectl ou de l'API. De plus, les erreurs de syntaxe (comme un YAML mal aligné) peuvent être
plus facilement détectées et n'affecteront pas tous les mappages.
Pour configurer un CRD `IAMIdentityMapping`, vous devrez d'abord `apply` le manifeste
du CRD :
```
kubectl apply -f deploy/iamidentitymapping.yaml
```
Une fois les CRDs déployés, vous pouvez alors créer des ressources personnalisées qui modélisent vos identités IAM. Voir
[`./deploy/example-iamidentitymapping.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example-iamidentitymapping.yaml) :
```
---
apiVersion: iamauthenticator.k8s.aws/v1alpha1
kind: IAMIdentityMapping
metadata:
name: kubernetes-admin
spec:
# Arn of the User or Role to be allowed to authenticate
arn: arn:aws:iam::XXXXXXXXXXXX:user/KubernetesAdmin
# Username that Kubernetes will see the user as, this is useful for setting
# up allowed specific permissions for different users
username: kubernetes-admin
# Groups to be attached to your users/roles. For example `system:masters` to
# create cluster admin, or `system:nodes`, `system:bootstrappers` for nodes to
# access the API server.
groups:
- system:masters
```
#### `EKSConfigMap`
La ConfigMap `kube-system/aws-auth` de style EKS sert de backend. La
ConfigMap doit être exactement au même format que dans les clusters EKS :
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. Cela est
utile si vous migrez depuis/vers EKS et souhaitez conserver vos mappings, ou si
vous exécutez EKS en plus d'un ou plusieurs autres clusters AWS et souhaitez avoir les mêmes
mappings dans chacun d'eux.
#### `DynamicFile`
Un fichier local spécifié par cfg.dynamicfilepath peut servir de backend. Le contenu du fichier
doit être exactement au même format que l'EKSConfigMap. Chaque fois que
ce contenu de fichier change, l'authenticator le rechargera automatiquement. Cela
offre plus de flexibilité pour la gestion des mappings ARN.
Consultez https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
pour savoir comment configurer le mode DynamicFile.
Exécutez `make e2e RUNNER=kind` pour jouer avec un cluster kind avec le mode DynamicFile activé.
### 5. Comment configurer reservedPrefixConfig pour les noms d'utilisateur Kubernetes
L'aws-iam-authenticator peut prendre en charge un préfixe réservé pour le nom d'utilisateur k8s. Si le préfixe réservé est
défini, alors le nom d'utilisateur avec le préfixe réservé ne sera pas authentifié avec l'erreur
"username must not begin with with the following prefixes:".
Consultez https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
pour savoir comment configurer le préfixe réservé.
### 6. Configurer kubectl pour utiliser les jetons d'authentification fournis par AWS IAM Authenticator for Kubernetes
Enfin, une fois le serveur configuré, vous voudrez vous authentifier.
Vous aurez toujours besoin d'un `kubeconfig` contenant les données publiques de votre cluster (certificat CA du cluster, adresse du point de terminaison).
La section `users` de votre configuration, cependant, doit inclure une section exec ([reportez-vous à la documentation des plugins d'identification kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)) :
```yaml
# [...]
users:
- name: kubernetes-admin
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
command: aws-iam-authenticator
args:
- "token"
- "-i"
- "REPLACE_ME_WITH_YOUR_CLUSTER_ID"
- "-r"
- "REPLACE_ME_WITH_YOUR_ROLE_ARN"
# no client certificate/key needed here!
```
Cela signifie que le `kubeconfig` est entièrement constitué de données publiques et peut être partagé entre tous les utilisateurs d'Authenticator.
Il peut être judicieux de le téléverser vers un emplacement public de confiance tel qu'AWS S3.
Assurez-vous que le binaire `aws-iam-authenticator` est installé.
Vous pouvez l'installer avec `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest`.
Pour vous authentifier, exécutez `kubectl --kubeconfig /path/to/kubeconfig" [...]`.
kubectl va `exec` le binaire `aws-iam-authenticator` avec les paramètres fournis dans votre kubeconfig, ce qui générera un jeton et le transmettra à l'apiserver.
Le jeton est valide pendant 15 minutes (la valeur la plus courte autorisée par AWS) et peut être réutilisé plusieurs fois.
Vous pouvez également spécifier un nom de session lors de la génération du jeton en incluant le paramètre `--session-name or -s`. Ce paramètre ne peut pas être utilisé conjointement avec `--forward-session-name`.
Vous pouvez également omettre `-r ROLE_ARN` pour signer le jeton avec vos identifiants existants sans assumer un rôle dédié.
Cela est utile si vous souhaitez vous authentifier directement en tant qu'utilisateur IAM ou si vous souhaitez vous authentifier à l'aide d'un rôle d'instance EC2 ou d'un rôle fédéré.
## Utilisation avec Kops
Les clusters gérés par [Kops](https://github.com/kubernetes/kops) peuvent être configurés pour utiliser Authenticator. Pour les instructions d'utilisation, consultez la [documentation Kops](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator).
## Comment cela fonctionne-t-il ?
Cela fonctionne à l'aide du point de terminaison d'API AWS [`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html).
Ce point de terminaison renvoie des informations sur les identifiants AWS IAM que vous utilisez pour vous y connecter.
#### Côté client (`aws-iam-authenticator token`)
Nous utilisons cette API d'une manière quelque peu inhabituelle en faisant générer et pré-signer par le client Authenticator une requête vers le point de terminaison.
Nous sérialisons cette requête dans un jeton qui peut traverser le système d'authentification Kubernetes.
#### Côté serveur (`aws-iam-authenticator server`)
Le jeton est transmis via le serveur d'API Kubernetes et vers le point de terminaison `/authenticate` du serveur Authenticator via une configuration de webhook.
Le serveur Authenticator valide tous les paramètres de la requête pré-signée pour s'assurer que rien ne semble suspect.
Il soumet ensuite la requête au véritable serveur `https://sts.amazonaws.com`, qui valide la signature HMAC du client et renvoie des informations sur l'utilisateur.
Maintenant que le serveur connaît l'identité AWS du client, il traduit cette identité en un utilisateur et des groupes Kubernetes via un simple mappage statique.
Ce mécanisme est emprunté, avec quelques modifications, à [Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method).
## Qu'est-ce qu'un ID de cluster ?
L'ID de cluster d'Authenticator est un identifiant unique par cluster qui empêche certaines attaques par rejeu.
Plus précisément, il empêche un serveur Authenticator (par exemple, dans un environnement de développement) d'utiliser le jeton d'un client pour s'authentifier auprès d'un autre serveur Authenticator dans un autre cluster.
L'ID de cluster doit être unique par cluster, mais il n'a pas besoin d'être secret.
De bons choix sont :
- Un ID aléatoire tel que celui généré par `openssl rand 16 -hex`
- Le nom de domaine de votre serveur d'API Kubernetes
La [documentation Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) explique également cette attaque (voir `X-Vault-AWS-IAM-Server-ID`).
## Spécification des identifiants et utilisation des profils AWS
Les identifiants peuvent être spécifiés pour être utilisés avec `aws-iam-authenticator` via l'une des méthodes disponibles pour le
[AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials).
Cela inclut la spécification des identifiants AWS avec des variables d'environnement ou en utilisant un fichier d'identifiants.
Les [profils nommés](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) AWS sont pris en charge par `aws-iam-authenticator`
via la variable d'environnement `AWS_PROFILE`. Par exemple, pour s'authentifier avec les identifiants spécifiés dans le profil _dev_, la variable `AWS_PROFILE` peut
être exportée ou spécifiée explicitement (par exemple, `AWS_PROFILE=dev kubectl get all`). Si aucun `AWS_PROFILE` n'est défini, le profil _default_ est utilisé.
La variable `AWS_PROFILE` peut également être spécifiée directement dans le fichier kubeconfig
[dans le cadre du flux `exec`](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration). Par exemple, pour spécifier
que les identifiants du profil nommé _dev_ doivent toujours être utilisés par `aws-iam-authenticator`, votre kubeconfig inclurait une clé `env`
qui définit le profil :
```yaml
apiVersion: v1
clusters:
- cluster:
server: ${server}
certificate-authority-data: ${cert}
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: aws
name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
command: aws-iam-authenticator
env:
- name: "AWS_PROFILE"
value: "dev"
args:
- "token"
- "-i"
- "mycluster"
```
Cette méthode permet d'utiliser implicitement le profil approprié. Notez que toute variable d'environnement définie dans le cadre du flux `exec` aura
la priorité sur ce qui est déjà défini dans votre environnement.
#### Note pour les utilisateurs fédérés :
Les utilisateurs AWS fédérés disposent souvent d'un attribut « significatif » mappé sur leur rôle assumé, tel qu'une adresse e-mail, via la configuration AWS du compte.
Ces sessions assumées comportent [plusieurs parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable), le `role id`
et le `caller-specified-role-name`. Par défaut, lorsqu'un utilisateur fédéré utilise l'option `--role` de `aws-iam-authenticator` pour assumer un nouveau rôle, le
`caller-specified-role-name` sera converti en un jeton aléatoire et le `role id` sera reporté sur le rôle nouvellement assumé.
L'utilisation de `aws-iam-authenticator token ... --forward-session-name` mappera l'attribut `caller-specified-role-name` d'origine sur la nouvelle session assumée STS.
Cela peut être utile pour tenter rapidement d'associer « qui a effectué l'action X sur le cluster K8 ».
Veuillez noter que **cela ne doit pas être considéré comme définitif** et doit être recoupé via le `role id` (qui reste cohérent) avec les journaux CloudTrail,
car un utilisateur pourrait potentiellement modifier cela côté client.
## Autorisation API depuis l'extérieur d'un cluster
Il est possible d'effectuer des requêtes vers l'API Kubernetes depuis un client situé en dehors du cluster, que ce soit en utilisant
l'API REST Kubernetes brute ou l'un des clients Kubernetes spécifiques à un langage
(par exemple, [Python](https://github.com/kubernetes-client/python)). Pour ce faire, vous devez créer un jeton bearer qui
est inclus avec la requête vers l'API. Ce jeton bearer nécessite que vous ajoutiez la chaîne `k8s-aws-v1.` à une
chaîne encodée en base64 d'une requête HTTP signée vers l'API STS GetCallerIdentity Query. Celui-ci est ensuite envoyé dans l'en-tête
`Authorization` de la requête. À noter toutefois que l'IAM Authenticator omet explicitement
le remplissage base64 afin d'éviter tout caractère `=`, garantissant ainsi une chaîne utilisable en toute sécurité dans les URL. Voici un exemple en
Python de la façon dont ce jeton serait construit :
```python
import base64
import boto3
import re
from botocore.signers import RequestSigner
def get_bearer_token(cluster_id, region):
STS_TOKEN_EXPIRES_IN = 60
session = boto3.session.Session()
client = session.client('sts', region_name=region)
service_id = client.meta.service_model.service_id
signer = RequestSigner(
service_id,
region,
'sts',
'v4',
session.get_credentials(),
session.events
)
params = {
'method': 'GET',
'url': 'https://sts.{}.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15'.format(region),
'body': {},
'headers': {
'x-k8s-aws-id': cluster_id
},
'context': {}
}
signed_url = signer.generate_presigned_url(
params,
region_name=region,
expires_in=STS_TOKEN_EXPIRES_IN,
operation_name=''
)
base64_url = base64.urlsafe_b64encode(signed_url.encode('utf-8')).decode('utf-8')
# remove any base64 encoding padding:
return 'k8s-aws-v1.' + re.sub(r'=*', '', base64_url)
# If making a HTTP request you would create the authorization headers as follows:
headers = {'Authorization': 'Bearer ' + get_bearer_token('my_cluster', 'us-east-1')}
```
## Dépannage
Si votre client échoue avec une erreur du type `could not get token: AccessDenied [...]`, vous pouvez essayer d'endosser le rôle directement avec l'AWS CLI :
```sh
# AWS CLI version of `aws-iam-authenticator token -r arn:aws:iam::ACCOUNT:role/ROLE`:
$ aws sts assume-role --role-arn arn:aws:iam::ACCOUNT:role/ROLE --role-session-name test
```
Si cela échoue, voici quelques problèmes possibles à vérifier :
- Assurez-vous que vos identifiants AWS de base sont disponibles dans votre shell (`aws sts get-caller-identity` peut aider à diagnostiquer cela).
- Assurez-vous que le rôle cible autorise l'accès à votre compte source (dans la politique de confiance du rôle).
- Assurez-vous que votre principal source (utilisateur/rôle/groupe) dispose d'une politique IAM qui autorise `sts:AssumeRole` pour le rôle cible.
- Assurez-vous que vous n'avez aucune politique de refus explicite attachée à votre utilisateur, groupe, ou dans AWS Organizations qui empêcherait le `sts:AssumeRole`.
- Essayez de simuler l'appel `sts:AssumeRole` dans le [Policy Simulator](https://policysim.aws.amazon.com/home/index.jsp).
## Format de configuration complet
Le client et le serveur ont le même format de configuration.
Ils peuvent partager exactement le même fichier de configuration, puisqu'aucun secret n'est stocké dans la configuration.
```yaml
# a unique-per-cluster identifier to prevent replay attacks (see above)
clusterID: my-dev-cluster.example.com
# default IAM role to assume for `aws-iam-authenticator token`
defaultRole: arn:aws:iam::000000000000:role/KubernetesAdmin
# server listener configuration
server:
# localhost port where the server will serve the /authenticate endpoint
port: 21362 # (default)
# state directory for generated TLS certificate and private keys
stateDir: /var/aws-iam-authenticator # (default)
# output `path` where a generated webhook kubeconfig will be stored.
generateKubeconfig: /etc/kubernetes/aws-iam-authenticator.kubeconfig # (default)
# role to assume before querying EC2 API in order to discover metadata like EC2 private DNS Name
ec2DescribeInstancesRoleARN: arn:aws:iam::000000000000:role/DescribeInstancesRole
# AWS region for EC2 DescribeInstances and token verification. If unset, the region is looked
# up from the EC2 Instance Metadata Service (IMDS) at startup. Also settable with `--region`.
region: us-west-2
# AWS Account IDs to scrub from server logs. (Defaults to empty list)
scrubbedAccounts:
- "111122223333"
- "222233334444"
# each mapRoles entry maps an IAM role to a username and set of groups
# Each username and group can optionally contain template parameters:
# 1) "{{AccountID}}" is the 12 digit AWS ID.
# 2) "{{SessionName}}" is the role session name, with `@` characters
# transliterated to `-` characters.
# 3) "{{SessionNameRaw}}" is the role session name, without character
# transliteration (available in version >= 0.5).
mapRoles:
# statically map arn:aws:iam::000000000000:role/KubernetesAdmin to cluster admin
- rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin
username: kubernetes-admin
groups:
- system:masters
# map EC2 instances in my "KubernetesNode" role to users like
# "aws:000000000000:instance:i-0123456789abcdef0". Only use this if you
# trust that the role can only be assumed by EC2 instances. If an IAM user
# can assume this role directly (with sts:AssumeRole) they can control
# SessionName.
- rolearn: arn:aws:iam::000000000000:role/KubernetesNode
username: aws:{{AccountID}}:instance:{{SessionName}}
groups:
- system:bootstrappers
- aws:instances
# map nodes that should conform to the username "system:node:<private-DNS>". This
# requires the authenticator to query the EC2 API in order to discover the private
# DNS of the EC2 instance originating the authentication request.
# {{EC2PrivateDNSName}} is resolved by using the session name as an EC2 instance
# ID and calling ec2:DescribeInstances. Note that if this role is assumed directly
# by an IAM User (not via federation), the user can set the session name to any
# instance ID, resolving another instance's private DNS and impersonating that node.
# Optionally, you may specify a role that should be assumed before querying the EC2 API with the
# key "server.ec2DescribeInstancesRoleARN" (see above).
- rolearn: arn:aws:iam::000000000000:role/KubernetesNode
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:nodes
- system:bootstrappers
# map federated users in my "KubernetesAdmin" role to users like
# "admin:alice-example.com". The SessionName is an arbitrary role name
# like an e-mail address passed by the identity provider. Note that if this
# role is assumed directly by an IAM User (not via federation), the user
# can control the SessionName.
- rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin
username: admin:{{SessionName}}
groups:
- system:masters
# map federated users in my "KubernetesOtherAdmin" role to users like
# "alice-example.com". The SessionName is an arbitrary role name
# like an e-mail address passed by the identity provider. Note that if this
# role is assumed directly by an IAM User (not via federation), the user
# can control the SessionName. Note that the "{{SessionName}}" macro is
# quoted to ensure it is properly parsed as a string.
- rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin
username: "{{SessionName}}"
groups:
- system:masters
# If unalterable identification of an IAM User is desirable, you can map against
# AccessKeyID.
- rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin
username: "admin:{{AccessKeyID}}"
groups:
- system:masters
# each mapUsers entry maps an IAM user to a static username and set of groups
mapUsers:
# map user IAM user Alice in 000000000000 to user "alice" in group "system:masters"
- userarn: arn:aws:iam::000000000000:user/Alice
username: alice
groups:
- system:masters
# automatically map IAM ARN from these accounts to username.
# NOTE: Always use quotes to avoid the account numbers being recognized as numbers
# instead of strings by the yaml parser.
mapAccounts:
- "012345678901"
- "456789012345"
# source mappings from this file (mapUsers, mapRoles, & mapAccounts)
backendMode:
- MountedFile
```
## Développement
Consultez la page [développement](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/docs/development.md).
## Communauté, discussions, contributions et support
Découvrez comment interagir avec la communauté Kubernetes sur la [page de la communauté](http://kubernetes.io/community/).
Vous pouvez joindre les mainteneurs de ce projet via :
- [Slack](https://kubernetes.slack.com/messages/sig-aws)
- [Liste de diffusion](https://groups.google.com/forum/#!forum/kubernetes-sig-aws)
### Code de conduite
La participation à la communauté Kubernetes est régie par le [Code de conduite Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/code-of-conduct.md).