kubernetes-sigs/aws-iam-authenticatorUma ferramenta para usar credenciais AWS IAM para autenticar em um cluster Kubernetes
# AWS IAM Authenticator para Kubernetes
Uma ferramenta para usar credenciais do AWS IAM para autenticar em um cluster Kubernetes.
O trabalho inicial nesta ferramenta foi conduzido pela Heptio. O projeto recebe contribuições de vários engenheiros da comunidade e atualmente é mantido pela Heptio e pelos Engenheiros de OSS da Amazon EKS.
## Índice
- [Por que eu quero isso?](#por-que-eu-quero-isso)
- [Como eu uso isso?](#como-eu-uso-isso)
- [Uso com Kops](#uso-com-kops)
- [Como funciona?](#como-funciona)
- [O que é um cluster ID?](#o-que-é-um-cluster-id)
- [Especificando Credenciais e Usando Perfis da AWS](#especificando-credenciais-e-usando-perfis-da-aws)
- [Autorização de API de Fora de um Cluster](#autorização-de-api-de-fora-de-um-cluster)
- [Solução de Problemas](#solução-de-problemas)
- [Formato Completo de Configuração](#formato-completo-de-configuração)
- [Desenvolvimento](#desenvolvimento)
- [Comunidade, discussão, contribuição e suporte](#comunidade-discussão-contribuição-e-suporte)
## Por que eu quero isso?
Se você é um administrador executando um cluster Kubernetes na AWS, você já precisa gerenciar credenciais do AWS IAM para provisionar e atualizar o cluster.
Ao usar o AWS IAM Authenticator para Kubernetes, você evita ter que gerenciar uma credencial separada para acesso ao Kubernetes.
O AWS IAM também fornece uma série de propriedades interessantes, como uma trilha de auditoria fora de banda (via CloudTrail) e a aplicação de 2FA/MFA.
Se você está construindo um instalador de Kubernetes na AWS, o AWS IAM Authenticator para Kubernetes pode simplificar seu processo de bootstrap.
Você não precisará de alguma forma contrabandear sua credencial de administrador inicial de forma segura para fora do seu cluster recém-instalado.
Em vez disso, você pode criar uma role dedicada `KubernetesAdmin` no momento do provisionamento do cluster e configurar o Authenticator para permitir logins de administrador do cluster.
## Como eu uso isso?
Assumindo que você tem um cluster em execução na AWS e deseja adicionar suporte ao AWS IAM Authenticator para Kubernetes, você precisa:
1. Criar uma role IAM que você usará para identificar usuários.
2. Executar o servidor Authenticator como um DaemonSet.
3. Configurar seu servidor de API para se comunicar com o Authenticator.
4. Configurar o kubectl para usar tokens do Authenticator.
### 1. Criar uma role IAM
Primeiro, você deve criar uma ou mais roles IAM que serão mapeadas para usuários/grupos dentro do seu cluster Kubernetes.
A maneira mais fácil de fazer isso é fazer login no Console da AWS:
- Escolha a opção "Role for cross-account access" / "Provide access between AWS accounts you own".
- Cole o número do ID da sua conta da AWS (disponível no canto superior direito do console).
- Sua role não precisa de nenhuma política adicional anexada.
Isso criará uma role IAM sem permissões que pode ser assumida por usuários/roles autorizados em sua conta.
Anote o Amazon Resource Name (ARN) da sua role, que você precisará abaixo.
Você também pode fazer isso em uma única etapa usando a AWS CLI em vez do Console da 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'
```
Também pode ignorar este passo e usar:
- Uma função existente (como uma função de acesso entre contas).
- Um usuário IAM (ver `mapUsers` abaixo).
- Uma instância EC2 ou uma função federada (ver `mapRoles` abaixo).
### 2. Executar o servidor
O servidor destina-se a ser executado em cada um dos seus nós master como um DaemonSet com host networking, para que possa expor uma porta localhost.
Para um exemplo de configuração de ConfigMap e DaemonSet, ver [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example.yaml).
Antes de o aplicar, atualize estes valores para o seu cluster:
- Substitua os ARNs IAM de exemplo (`arn:aws:iam::000000000000:...`) em `config.yaml`.
- Defina `clusterID` com um valor único para o seu cluster.
- Verifique se as regras de agendamento do DaemonSet correspondem às labels/taints dos seus nós control-plane.
Depois, implemente-o:
```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
```
Quando o pod estiver em execução num nó de control-plane, o `aws-iam-authenticator server` criará o kubeconfig do webhook no host em `/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml` (ou no caminho configurado através de `--generate-kubeconfig`).
#### (Opcional) Pré-gerar um certificado, chave e kubeconfig
Se estiver a construir um instalador automatizado, também pode pré-gerar facilmente os ficheiros de certificado, chave e kubeconfig do webhook usando `aws-iam-authenticator init`.
Este comando irá gerar ficheiros e colocá-los nos diretórios de saída configurados.
Pode executá-lo em cada nó master antes de iniciar o API server.
Também pode gerá-los antes de provisionar os nós master e instalá-los nos caminhos de host apropriados.
Se não pré-gerar os ficheiros, o `aws-iam-authenticator server` irá gerá-los a pedido.
Isto funciona, mas requer que reinicie o seu Kubernetes API server após a instalação.
### 3. Configurar o seu API server para comunicar com o servidor
A API do Kubernetes integra-se com o AWS IAM Authenticator for Kubernetes usando um [webhook de autenticação por token](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication).
Quando executa `aws-iam-authenticator server`, este irá gerar um ficheiro de configuração de webhook e guardá-lo no sistema de ficheiros do host.
Terá de adicionar um único flag adicional à configuração do seu API server:
```
--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml
```
Em muitos clusters, o servidor de API é executado como um pod estático.
Você pode adicionar a flag a `/etc/kubernetes/manifests/kube-apiserver.yaml`.
Certifique-se de que o diretório do host `/etc/kubernetes/aws-iam-authenticator/` esteja montado no seu pod do servidor de API.
Você também pode precisar reiniciar o daemon kubelet no seu nó master para que ele carregue a definição atualizada do pod estático:
```
systemctl restart kubelet.service
```
### 4. Criar mapeamentos de função/usuário IAM para usuário/grupo do kubernetes
O comportamento padrão do servidor é obter mapeamentos exclusivamente dos
campos `mapUsers` e `mapRoles` do seu arquivo de configuração. Consulte [Formato
Completo de Configuração](#full-configuration-format) abaixo para obter detalhes.
Usando a flag `--backend-mode`, você pode configurar o servidor para obter
mapeamentos de dois backends adicionais: um ConfigMap no estilo EKS
(`--backend-mode=EKSConfigMap`) ou recursos personalizados `IAMIdentityMapping`
(`--backend-mode=CRD`). O backend padrão, o arquivo de configuração do servidor
que é montado pelo pod do servidor, corresponde a `--backend-mode=MountedFile`.
Você pode passar uma lista separada por vírgulas desses backends para que o servidor os pesquise
em ordem. Por exemplo, com `--backend-mode=EKSConfigMap,MountedFile`, o
servidor pesquisará o ConfigMap no estilo EKS em busca de mapeamentos e, em seguida, se não
encontrar um mapeamento para a função/usuário IAM fornecido, o arquivo de configuração do servidor. Se um
mapeamento para a mesma função/usuário IAM existir em vários backends, o servidor
usará o mapeamento no backend que ocorrer primeiro na lista separada por vírgulas.
Neste exemplo, se um mapeamento for encontrado no ConfigMap do EKS, ele será
usado independentemente de existir um mapeamento duplicado ou conflitante no arquivo de
configuração do servidor.
Observe que, ao definir um único backend, o servidor obterá *apenas* desse
backend e ignorará os outros, mesmo que existam. Por exemplo, com
`--backend-mode=CRD`, o servidor obterá *apenas* de `IAMIdentityMappings`
e ignorará o arquivo montado e o ConfigMap do EKS.
#### `MountedFile`
Este é o backend padrão de mapeamentos e é suficiente para a maioria dos usuários. Consulte
[Formato Completo de Configuração](#full-configuration-format) abaixo para obter detalhes.
#### `CRD` (alpha)
Este backend modela cada mapeamento IAM como um [Recurso Personalizado do
Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
`IAMIdentityMapping`. Essa abordagem permite manter mapeamentos de forma nativa do Kubernetes usando
kubectl ou a API. Além disso, erros de sintaxe (como YAML desalinhado) podem ser
detectados mais facilmente e não afetarão todos os mapeamentos.
Para configurar um CRD `IAMIdentityMapping`, primeiro você precisará aplicar (`apply`) o manifesto
do CRD:
```
kubectl apply -f deploy/iamidentitymapping.yaml
```
Com os CRDs implantados, você pode então criar Custom Resources que modelam suas
Identidades IAM. Veja
[`./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`
O ConfigMap `kube-system/aws-auth` no estilo EKS serve como backend. Espera-se que o
ConfigMap esteja exatamente no mesmo formato que nos clusters EKS:
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. Isso é
útil se você estiver migrando de/para EKS e quiser manter seus mapeamentos, ou se
estiver executando EKS além de algum(ns) outro(s) cluster(s) AWS e quiser ter os mesmos
mapeamentos em cada um.
#### `DynamicFile`
Um arquivo local especificado por cfg.dynamicfilepath pode servir como backend. Espera-se que o conteúdo
do arquivo esteja exatamente no mesmo formato que o EKSConfigMap. Sempre que
o conteúdo deste arquivo mudar, o authenticator irá recarregá-lo automaticamente. Isso
proporciona mais flexibilidade no gerenciamento dos mapeamentos de ARN.
Consulte https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
para saber como configurar o modo DynamicFile.
Execute `make e2e RUNNER=kind` para experimentar um cluster kind com o modo DynamicFile habilitado.
### 5. Como configurar reservedPrefixConfig para nomes de usuário do Kubernetes
O aws-iam-authenticator pode suportar prefixo reservado para o nome de usuário do k8s. Se o prefixo reservado for
definido, então o nome de usuário com o prefixo reservado não será autenticado, com o erro
"username must not begin with with the following prefixes:".
Consulte https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
para saber como configurar o prefixo reservado.
### 6. Configurar o kubectl para usar tokens de autenticação fornecidos pelo AWS IAM Authenticator for Kubernetes
Por fim, depois que o servidor estiver configurado, você vai querer se autenticar.
Você ainda precisará de um `kubeconfig` que tenha os dados públicos sobre o seu cluster (certificado CA do cluster, endereço do endpoint).
A seção `users` da sua configuração, no entanto, deve incluir uma seção exec ([consulte a documentação do plugin de credenciais do 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!
```
Isso significa que o `kubeconfig` é inteiramente dado público e pode ser compartilhado entre todos os usuários do Authenticator.
Pode fazer sentido enviá-lo para um local público confiável, como o AWS S3.
Certifique-se de ter o binário `aws-iam-authenticator` instalado.
Você pode instalá-lo com `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest`.
Para autenticar, execute `kubectl --kubeconfig /path/to/kubeconfig" [...]`.
O kubectl irá `exec` o binário `aws-iam-authenticator` com os parâmetros fornecidos no seu kubeconfig, o que gerará um token e o passará para o apiserver.
O token é válido por 15 minutos (o menor valor permitido pela AWS) e pode ser reutilizado várias vezes.
Você também pode especificar o nome da sessão ao gerar o token incluindo o parâmetro `--session-name` ou `-s`. Este parâmetro não pode ser usado junto com `--forward-session-name`.
Você também pode omitir `-r ROLE_ARN` para assinar o token com suas credenciais existentes sem assumir uma função dedicada.
Isso é útil se você quiser autenticar diretamente como um usuário IAM ou se quiser autenticar usando uma função de instância EC2 ou uma função federada.
## Uso com Kops
Clusters gerenciados pelo [Kops](https://github.com/kubernetes/kops) podem ser configurados para usar o Authenticator. Para instruções de uso, consulte a [documentação do Kops](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator).
## Como funciona?
Funciona usando o endpoint da API [`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html) da AWS.
Este endpoint retorna informações sobre quaisquer credenciais IAM da AWS que você usar para se conectar a ele.
#### Lado do cliente (`aws-iam-authenticator token`)
Usamos esta API de uma forma um tanto incomum, fazendo com que o cliente do Authenticator gere e pré-assine uma requisição para o endpoint.
Serializamos essa requisição em um token que pode passar pelo sistema de autenticação do Kubernetes.
#### Lado do servidor (`aws-iam-authenticator server`)
O token é passado pelo servidor da API do Kubernetes e para o endpoint `/authenticate` do servidor do Authenticator por meio de uma configuração de webhook.
O servidor do Authenticator valida todos os parâmetros da requisição pré-assinada para garantir que nada pareça estranho.
Em seguida, ele envia a requisição para o servidor real `https://sts.amazonaws.com`, que valida a assinatura HMAC do cliente e retorna informações sobre o usuário.
Agora que o servidor conhece a identidade AWS do cliente, ele traduz essa identidade em um usuário e grupos do Kubernetes por meio de um mapeamento estático simples.
Este mecanismo foi emprestado, com algumas alterações, do [Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method).
## O que é um cluster ID?
O cluster ID do Authenticator é um identificador único por cluster que previne certos ataques de replay.
Especificamente, ele impede que um servidor do Authenticator (por exemplo, em um ambiente de desenvolvimento) use o token de um cliente para se autenticar em outro servidor do Authenticator em outro cluster.
O cluster ID precisa ser único por cluster, mas não precisa ser secreto.
Algumas boas escolhas são:
- Um ID aleatório, como o gerado por `openssl rand 16 -hex`
- O nome de domínio do seu servidor da API do Kubernetes
A [documentação do Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) também explica esse ataque (veja `X-Vault-AWS-IAM-Server-ID`).
## Especificando Credenciais e Usando Perfis da AWS
As credenciais podem ser especificadas para uso com o `aws-iam-authenticator` por meio de qualquer um dos métodos disponíveis no
[AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials).
Isso inclui especificar credenciais da AWS com variáveis de ambiente ou utilizando um arquivo de credenciais.
Perfis nomeados da AWS [named profiles](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) são suportados pelo `aws-iam-authenticator`
através da variável de ambiente `AWS_PROFILE`. Por exemplo, para autenticar com credenciais especificadas no perfil _dev_, a variável `AWS_PROFILE` pode
ser exportada ou especificada explicitamente (por exemplo, `AWS_PROFILE=dev kubectl get all`). Se nenhum `AWS_PROFILE` estiver definido, o perfil _default_ é utilizado.
O `AWS_PROFILE` também pode ser especificado diretamente no arquivo kubeconfig
[como parte do fluxo `exec`](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration). Por exemplo, para especificar
que as credenciais do perfil nomeado _dev_ devem sempre ser utilizadas pelo `aws-iam-authenticator`, seu kubeconfig incluiria uma chave `env`
que define o perfil:
```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"
```
Este método permite que o perfil apropriado seja utilizado implicitamente. Observe que quaisquer variáveis de ambiente definidas como parte do fluxo `exec` terão
precedência sobre o que já está definido no seu ambiente.
#### Nota para usuários federados:
Usuários federados da AWS frequentemente terão um atributo "significativo" mapeado em seu role assumido, como um endereço de e-mail, por meio da configuração da AWS da conta.
Essas sessões assumidas têm [algumas partes](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable), o `role id`
e o `caller-specified-role-name`. Por padrão, quando um usuário federado usa a opção `--role` do `aws-iam-authenticator` para assumir um novo role, o
`caller-specified-role-name` será convertido em um token aleatório e o `role id` será propagado para o role recém-assumido.
Usar `aws-iam-authenticator token ... --forward-session-name` mapeará o atributo original `caller-specified-role-name` para a nova sessão assumida do STS.
Isso pode ser útil para tentar rapidamente associar "quem executou a ação X no cluster K8".
Observe, **isto não deve ser considerado definitivo** e precisa ser correlacionado via `role id` (que permanece consistente) com os logs do CloudTrail,
pois um usuário poderia potencialmente alterar isso no lado do cliente.
## Autorização de API a partir de Fora de um Cluster
É possível fazer requisições à API do Kubernetes a partir de um cliente que está fora do cluster, seja usando a
API REST pura do Kubernetes ou um dos clientes Kubernetes específicos de linguagem
(por exemplo, [Python](https://github.com/kubernetes-client/python)). Para isso, você deve criar um bearer token que
seja incluído com a requisição à API. Este bearer token exige que você anexe a string `k8s-aws-v1.` com uma
string codificada em base64 de uma requisição HTTP assinada para a API Query GetCallerIdentity do STS. Isso é então enviado no
cabeçalho `Authorization` da requisição. Algo a se observar, porém, é que o IAM Authenticator omite explicitamente
o preenchimento base64 para evitar quaisquer caracteres `=`, garantindo assim uma string segura para uso em URLs. Abaixo está um exemplo em
Python de como este token seria construído:
```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')}
```
## Solução de problemas
Se o seu cliente falhar com um erro como `could not get token: AccessDenied [...]`, você pode tentar assumir a role diretamente com a 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 isso falhar, há alguns problemas possíveis a verificar:
- Certifique-se de que suas credenciais AWS base estão disponíveis no seu shell (`aws sts get-caller-identity` pode ajudar a solucionar isso).
- Certifique-se de que a role de destino permite o acesso da sua conta de origem (na política de confiança da role).
- Certifique-se de que seu principal de origem (usuário/role/grupo) possui uma política IAM que permite `sts:AssumeRole` para a role de destino.
- Certifique-se de que você não possui políticas de negação explícita anexadas ao seu usuário, grupo ou no AWS Organizations que impediriam o `sts:AssumeRole`.
- Tente simular a chamada `sts:AssumeRole` no [Policy Simulator](https://policysim.aws.amazon.com/home/index.jsp).
## Formato Completo de Configuração
O cliente e o servidor possuem o mesmo formato de configuração.
Eles podem compartilhar exatamente o mesmo arquivo de configuração, já que não há segredos armazenados na configuração.
```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
```
## Desenvolvimento
Consulte a página de [desenvolvimento](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/docs/development.md).
## Comunidade, discussão, contribuição e suporte
Saiba como se envolver com a comunidade Kubernetes na [página da comunidade](http://kubernetes.io/community/).
Você pode entrar em contato com os mantenedores deste projeto em:
- [Slack](https://kubernetes.slack.com/messages/sig-aws)
- [Lista de discussão](https://groups.google.com/forum/#!forum/kubernetes-sig-aws)
### Código de conduta
A participação na comunidade Kubernetes é regida pelo [Código de Conduta do Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/code-of-conduct.md).