kubernetes-sigs/aws-iam-authenticatorUno strumento per utilizzare le credenziali AWS IAM per autenticarsi a un cluster Kubernetes
# AWS IAM Authenticator per Kubernetes
Uno strumento per utilizzare le credenziali AWS IAM per autenticarsi a un cluster Kubernetes.
Il lavoro iniziale su questo strumento è stato guidato da Heptio. Il progetto riceve contributi da diversi ingegneri della community ed è attualmente mantenuto da Heptio e dagli ingegneri OSS di Amazon EKS.
## Indice
- [Perché dovrei volerlo?](#why-do-i-want-this)
- [Come lo uso?](#how-do-i-use-it)
- [Utilizzo con Kops](#kops-usage)
- [Come funziona?](#how-does-it-work)
- [Cos'è un cluster ID?](#what-is-a-cluster-id)
- [Specificare le credenziali e utilizzare i profili AWS](#specifying-credentials--using-aws-profiles)
- [Autorizzazione API dall'esterno di un cluster](#api-authorization-from-outside-a-cluster)
- [Risoluzione dei problemi](#troubleshooting)
- [Formato completo della configurazione](#full-configuration-format)
- [Sviluppo](#development)
- [Community, discussione, contribuzione e supporto](#community-discussion-contribution-and-support)
## Perché dovrei volerlo?
Se sei un amministratore che gestisce un cluster Kubernetes su AWS, devi già gestire le credenziali AWS IAM per effettuare il provisioning e aggiornare il cluster.
Utilizzando AWS IAM Authenticator per Kubernetes, eviti di dover gestire una credenziale separata per l'accesso a Kubernetes.
AWS IAM fornisce inoltre diverse proprietà utili come una traccia di audit fuori banda (tramite CloudTrail) e l'applicazione di 2FA/MFA.
Se stai realizzando un installer Kubernetes su AWS, AWS IAM Authenticator per Kubernetes può semplificare il tuo processo di bootstrap.
Non avrai bisogno di far uscire in modo sicuro e clandestino la tua credenziale amministrativa iniziale dal cluster appena installato.
Invece, puoi creare un ruolo dedicato `KubernetesAdmin` al momento del provisioning del cluster e configurare Authenticator per consentire gli accessi da amministratore del cluster.
## Come lo uso?
Supponendo che tu abbia un cluster in esecuzione su AWS e che tu voglia aggiungere il supporto di AWS IAM Authenticator per Kubernetes, devi:
1. Creare un ruolo IAM che utilizzerai per identificare gli utenti.
2. Eseguire il server Authenticator come DaemonSet.
3. Configurare il tuo API server per comunicare con Authenticator.
4. Configurare kubectl per utilizzare i token di Authenticator.
### 1. Creare un ruolo IAM
Innanzitutto, devi creare uno o più ruoli IAM che saranno mappati a utenti/gruppi all'interno del tuo cluster Kubernetes.
Il modo più semplice per farlo è accedere alla Console AWS:
- Scegli l'opzione "Role for cross-account access" / "Provide access between AWS accounts you own".
- Incolla il numero del tuo ID account AWS (disponibile in alto a destra nella console).
- Il tuo ruolo non necessita di alcuna policy aggiuntiva collegata.
Questo creerà un ruolo IAM senza permessi che può essere assunto da utenti/ruoli autorizzati nel tuo account.
Annota l'Amazon Resource Name (ARN) del tuo ruolo, che ti servirà di seguito.
Puoi anche farlo in un unico passaggio utilizzando la AWS CLI invece della 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'
```
Puoi anche saltare questo passaggio e utilizzare:
- Un ruolo esistente (come un ruolo di accesso cross-account).
- Un utente IAM (vedi `mapUsers` di seguito).
- Un'istanza EC2 o un ruolo federato (vedi `mapRoles` di seguito).
### 2. Avvia il server
Il server è pensato per essere eseguito su ciascuno dei tuoi nodi master come DaemonSet con host networking, in modo da poter esporre una porta localhost.
Per un esempio di configurazione ConfigMap e DaemonSet, vedi [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example.yaml).
Prima di applicarla, aggiorna questi valori per il tuo cluster:
- Sostituisci gli ARN IAM segnaposto (`arn:aws:iam::000000000000:...`) in `config.yaml`.
- Imposta `clusterID` su un valore univoco per il tuo cluster.
- Verifica che le regole di scheduling del DaemonSet corrispondano alle etichette/taint dei tuoi nodi control-plane.
Poi distribuiscilo:
```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
```
Una volta che il pod è in esecuzione su un nodo control-plane, `aws-iam-authenticator server` creerà il kubeconfig del webhook sull'host in `/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml` (o nel percorso configurato tramite `--generate-kubeconfig`).
#### (Opzionale) Pre-generare un certificato, una chiave e un kubeconfig
Se stai realizzando un installer automatizzato, puoi anche pre-generare facilmente i file del certificato, della chiave e del kubeconfig del webhook usando `aws-iam-authenticator init`.
Questo comando genererà i file e li collocherà nelle directory di output configurate.
Puoi eseguirlo su ciascun master node prima di avviare l'API server.
Potresti anche generarli prima del provisioning dei master node e installarli nei percorsi host appropriati.
Se non pre-generi i file, `aws-iam-authenticator server` li genererà su richiesta.
Questo funziona ma richiede il riavvio del tuo Kubernetes API server dopo l'installazione.
### 3. Configura il tuo API server per comunicare con il server
L'API di Kubernetes si integra con AWS IAM Authenticator for Kubernetes tramite un [webhook di autenticazione tramite token](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication).
Quando esegui `aws-iam-authenticator server`, questo genererà un file di configurazione del webhook e lo salverà sul filesystem dell'host.
Dovrai aggiungere un singolo flag aggiuntivo alla configurazione del tuo API server:
```
--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml
```
Su molti cluster, il server API viene eseguito come pod statico.
Puoi aggiungere il flag a `/etc/kubernetes/manifests/kube-apiserver.yaml`.
Assicurati che la directory host `/etc/kubernetes/aws-iam-authenticator/` sia montata nel tuo pod del server API.
Potrebbe anche essere necessario riavviare il demone kubelet sul nodo master per recepire la definizione aggiornata del pod statico:
```
systemctl restart kubelet.service
```
### 4. Creare le mappature tra ruolo/utente IAM e utente/gruppo Kubernetes
Il comportamento predefinito del server è di ottenere le mappature esclusivamente dai
campi `mapUsers` e `mapRoles` del suo file di configurazione. Vedere [Formato completo
della configurazione](#full-configuration-format) di seguito per i dettagli.
Utilizzando il flag `--backend-mode`, è possibile configurare il server per ottenere
le mappature da due backend aggiuntivi: una ConfigMap in stile EKS
(`--backend-mode=EKSConfigMap`) o risorse personalizzate `IAMIdentityMapping`
(`--backend-mode=CRD`). Il backend predefinito, il file di configurazione del server
montato dal pod del server, corrisponde a `--backend-mode=MountedFile`.
È possibile passare un elenco separato da virgole di questi backend per far sì che il server
li cerchi in ordine. Ad esempio, con `--backend-mode=EKSConfigMap,MountedFile`, il
server cercherà le mappature nella ConfigMap in stile EKS e poi, se non trova
una mappatura per il dato ruolo/utente IAM, nel file di configurazione del server. Se una
mappatura per lo stesso ruolo/utente IAM esiste in più backend, il server
utilizzerà la mappatura nel backend che compare per primo nell'elenco separato da virgole.
In questo esempio, se una mappatura viene trovata nella ConfigMap EKS, verrà
utilizzata indipendentemente dall'esistenza di una mappatura duplicata o in conflitto nel file
di configurazione del server.
Si noti che impostando un singolo backend, il server otterrà le mappature *solo* da
quello e ignorerà gli altri anche se esistono. Ad esempio, con
`--backend-mode=CRD`, il server otterrà le mappature *solo* da `IAMIdentityMappings`
e ignorerà il file montato e la ConfigMap EKS.
#### `MountedFile`
Questo è il backend predefinito delle mappature ed è sufficiente per la maggior parte degli utenti. Vedere
[Formato completo della configurazione](#full-configuration-format) di seguito per i dettagli.
#### `CRD` (alpha)
Questo backend modella ogni mappatura IAM come una [risorsa personalizzata
Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
`IAMIdentityMapping`. Questo approccio consente di mantenere le mappature in modo nativo
per Kubernetes usando kubectl o l'API. Inoltre, gli errori di sintassi (come YAML disallineato)
possono essere individuati più facilmente e non influenzeranno tutte le mappature.
Per configurare una CRD `IAMIdentityMapping` sarà prima necessario eseguire `apply` del
manifest della CRD:
```
kubectl apply -f deploy/iamidentitymapping.yaml
```
Con i CRD distribuiti puoi quindi creare Custom Resource che modellano le tue
IAM Identities. Vedi
[`./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` in stile EKS funge da backend. Si prevede che la
ConfigMap sia esattamente nello stesso formato dei cluster EKS:
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. Questo è
utile se stai migrando da/verso EKS e vuoi mantenere le tue mappature, oppure se
esegui EKS in aggiunta a qualche altro cluster AWS e vuoi avere le stesse
mappature in ciascuno.
#### `DynamicFile`
Un file locale specificato da cfg.dynamicfilepath può fungere da backend. Il contenuto
del file deve essere esattamente nello stesso formato della EKSConfigMap. Ogni volta
che il contenuto di questo file cambia, l'authenticator lo ricaricherà automaticamente. Questo
offre maggiore flessibilità nella gestione delle mappature ARN.
Consulta https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
per sapere come configurare la modalità DynamicFile.
Esegui `make e2e RUNNER=kind` per sperimentare con un cluster kind con la modalità DynamicFile abilitata.
### 5. Come configurare reservedPrefixConfig per gli username Kubernetes
aws-iam-authenticator può supportare un prefisso riservato per lo username k8s. Se il prefisso riservato è
impostato, allora lo username con il prefisso riservato non verrà autenticato con l'errore
"username must not begin with with the following prefixes:".
Consulta https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
per sapere come configurare il prefisso riservato.
### 6. Configurare kubectl per usare i token di autenticazione forniti da AWS IAM Authenticator for Kubernetes
Infine, una volta configurato il server, vorrai autenticarti.
Avrai comunque bisogno di un `kubeconfig` che contenga i dati pubblici del tuo cluster (certificato CA del cluster, indirizzo dell'endpoint).
La sezione `users` della tua configurazione, tuttavia, dovrebbe includere una sezione exec ([consulta la documentazione sui plugin di credenziali di 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!
```
Questo significa che il `kubeconfig` è interamente un dato pubblico e può essere condiviso tra tutti gli utenti di Authenticator.
Potrebbe avere senso caricarlo in una posizione pubblica affidabile come AWS S3.
Assicurati di avere installato il binario `aws-iam-authenticator`.
Puoi installarlo con `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest`.
Per autenticarti, esegui `kubectl --kubeconfig /path/to/kubeconfig" [...]`.
kubectl eseguirà (`exec`) il binario `aws-iam-authenticator` con i parametri forniti nel tuo kubeconfig, il quale genererà un token e lo passerà all'apiserver.
Il token è valido per 15 minuti (il valore più breve consentito da AWS) e può essere riutilizzato più volte.
Puoi anche specificare il nome della sessione durante la generazione del token includendo il parametro `--session-name` o `-s`. Questo parametro non può essere utilizzato insieme a `--forward-session-name`.
Puoi anche omettere `-r ROLE_ARN` per firmare il token con le tue credenziali esistenti senza assumere un ruolo dedicato.
Questo è utile se vuoi autenticarti direttamente come utente IAM o se vuoi autenticarti utilizzando un ruolo di istanza EC2 o un ruolo federato.
## Utilizzo con Kops
I cluster gestiti da [Kops](https://github.com/kubernetes/kops) possono essere configurati per utilizzare Authenticator. Per le istruzioni sull'utilizzo consulta la [documentazione di Kops](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator).
## Come funziona?
Funziona utilizzando l'endpoint API AWS [`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html).
Questo endpoint restituisce informazioni sulle credenziali AWS IAM che utilizzi per connetterti ad esso.
#### Lato client (`aws-iam-authenticator token`)
Utilizziamo questa API in modo alquanto inusuale facendo generare e pre-firmare al client di Authenticator una richiesta all'endpoint.
Serializziamo quella richiesta in un token che può attraversare il sistema di autenticazione di Kubernetes.
#### Lato server (`aws-iam-authenticator server`)
Il token viene fatto passare attraverso l'API server di Kubernetes e nell'endpoint `/authenticate` del server Authenticator tramite una configurazione webhook.
Il server Authenticator convalida tutti i parametri della richiesta pre-firmata per assicurarsi che nulla sembri sospetto.
Poi invia la richiesta al vero server `https://sts.amazonaws.com`, che convalida la firma HMAC del client e restituisce informazioni sull'utente.
Ora che il server conosce l'identità AWS del client, traduce questa identità in un utente e gruppi Kubernetes tramite una semplice mappatura statica.
Questo meccanismo è preso in prestito, con alcune modifiche, da [Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method).
## Cos'è un cluster ID?
Il cluster ID di Authenticator è un identificatore univoco per cluster che previene alcuni attacchi di replay.
Nello specifico, impedisce a un server Authenticator (ad esempio, in un ambiente di sviluppo) di utilizzare il token di un client per autenticarsi a un altro server Authenticator in un altro cluster.
Il cluster ID deve essere univoco per cluster, ma non deve necessariamente essere segreto.
Alcune buone scelte sono:
- Un ID casuale, ad esempio da `openssl rand 16 -hex`
- Il nome di dominio del tuo API server Kubernetes
La [documentazione di Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) spiega anche questo attacco (vedi `X-Vault-AWS-IAM-Server-ID`).
## Specificare le credenziali e utilizzare i profili AWS
Le credenziali possono essere specificate per l'uso con `aws-iam-authenticator` tramite uno qualsiasi dei metodi disponibili per
l'[AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials).
Ciò include la specifica delle credenziali AWS tramite variabili d'ambiente o l'utilizzo di un file delle credenziali.
I [profili denominati](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) di AWS sono supportati da `aws-iam-authenticator`
tramite la variabile d'ambiente `AWS_PROFILE`. Ad esempio, per autenticarsi con le credenziali specificate nel profilo _dev_, è possibile esportare `AWS_PROFILE`
oppure specificarlo esplicitamente (ad es., `AWS_PROFILE=dev kubectl get all`). Se `AWS_PROFILE` non è impostato, viene utilizzato il profilo _default_.
`AWS_PROFILE` può anche essere specificato direttamente nel file kubeconfig
[come parte del flusso `exec`](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration). Ad esempio, per specificare
che le credenziali del profilo denominato _dev_ debbano essere sempre utilizzate da `aws-iam-authenticator`, il tuo kubeconfig includerebbe una chiave `env`
che imposta il profilo:
```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"
```
Questo metodo consente di utilizzare implicitamente il profilo appropriato. Nota che qualsiasi variabile d'ambiente impostata come parte del flusso `exec` avrà
la precedenza su ciò che è già impostato nel tuo ambiente.
#### Nota per gli utenti federati:
Gli utenti AWS federati spesso hanno un attributo "significativo" mappato sul loro ruolo assunto, come un indirizzo email, tramite la configurazione AWS dell'account.
Queste sessioni assunte hanno [alcune parti](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable), il `role id`
e il `caller-specified-role-name`. Per impostazione predefinita, quando un utente federato utilizza l'opzione `--role` di `aws-iam-authenticator` per assumere un nuovo ruolo, il
`caller-specified-role-name` verrà convertito in un token casuale e il `role id` viene trasferito al ruolo appena assunto.
Utilizzando `aws-iam-authenticator token ... --forward-session-name` si mapperà l'attributo originale `caller-specified-role-name` sulla nuova sessione assunta da STS.
Questo può essere utile per tentare rapidamente di associare "chi ha eseguito l'azione X sul cluster K8".
Tieni presente che **questo non deve essere considerato definitivo** e deve essere verificato in modo incrociato tramite il `role id` (che rimane coerente) con i log di CloudTrail
poiché un utente potrebbe potenzialmente modificarlo lato client.
## Autorizzazione API dall'esterno di un cluster
È possibile effettuare richieste all'API Kubernetes da un client che si trova al di fuori del cluster, sia utilizzando la
API REST Kubernetes nuda sia uno dei client Kubernetes specifici per linguaggio
(ad es., [Python](https://github.com/kubernetes-client/python)). Per farlo, devi creare un bearer token che
sia incluso con la richiesta all'API. Questo bearer token richiede che tu aggiunga la stringa `k8s-aws-v1.` con una
stringa codificata in base64 di una richiesta HTTP firmata alla Query API STS GetCallerIdentity. Questa viene poi inviata nell'
header `Authorization` della richiesta. Una cosa da notare però è che l'IAM Authenticator omette esplicitamente
il padding base64 per evitare qualsiasi carattere `=`, garantendo così una stringa sicura da usare negli URL. Di seguito è riportato un esempio in
Python su come verrebbe costruito questo token:
```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')}
```
## Risoluzione dei problemi
Se il tuo client fallisce con un errore come `could not get token: AccessDenied [...]`, puoi provare ad assumere il ruolo direttamente con la 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
```
Se questo fallisce, ci sono alcuni possibili problemi da verificare:
- Assicurati che le tue credenziali AWS di base siano disponibili nella tua shell (`aws sts get-caller-identity` può aiutare a risolvere questo problema).
- Assicurati che il ruolo di destinazione consenta l'accesso al tuo account di origine (nella policy di fiducia del ruolo).
- Assicurati che il tuo principal di origine (utente/ruolo/gruppo) disponga di una policy IAM che consenta `sts:AssumeRole` per il ruolo di destinazione.
- Assicurati di non avere policy di deny esplicite associate al tuo utente, gruppo o in AWS Organizations che impedirebbero `sts:AssumeRole`.
- Prova a simulare la chiamata `sts:AssumeRole` nel [Policy Simulator](https://policysim.aws.amazon.com/home/index.jsp).
## Formato di configurazione completo
Il client e il server hanno lo stesso formato di configurazione.
Possono condividere esattamente lo stesso file di configurazione, poiché non ci sono segreti memorizzati nella configurazione.
```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
```
## Sviluppo
Consulta la pagina [sviluppo](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/docs/development.md).
## Community, discussione, contribuzione e supporto
Scopri come interagire con la community di Kubernetes nella [pagina della community](http://kubernetes.io/community/).
Puoi contattare i manutentori di questo progetto su:
- [Slack](https://kubernetes.slack.com/messages/sig-aws)
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-aws)
### Codice di condotta
La partecipazione alla community di Kubernetes è regolata dal [Codice di condotta di Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/code-of-conduct.md).