kubernetes-sigs/aws-iam-authenticatorUna herramienta para utilizar credenciales de AWS IAM para autenticarse en un clúster de Kubernetes.
# AWS IAM Authenticator para Kubernetes
Una herramienta para usar credenciales de AWS IAM para autenticarse en un clúster de Kubernetes.
El trabajo inicial en esta herramienta fue impulsado por Heptio. El proyecto recibe contribuciones de múltiples ingenieros de la comunidad y actualmente está mantenido por Heptio e ingenieros de OSS de Amazon EKS.
## Tabla de contenidos
- [¿Por qué quiero esto?](#why-do-i-want-this)
- [¿Cómo lo uso?](#how-do-i-use-it)
- [Uso con Kops](#kops-usage)
- [¿Cómo funciona?](#how-does-it-work)
- [¿Qué es un cluster ID?](#what-is-a-cluster-id)
- [Especificación de credenciales y uso de perfiles de AWS](#specifying-credentials--using-aws-profiles)
- [Autorización de API desde fuera de un clúster](#api-authorization-from-outside-a-cluster)
- [Solución de problemas](#troubleshooting)
- [Formato completo de configuración](#full-configuration-format)
- [Desarrollo](#development)
- [Comunidad, discusión, contribución y soporte](#community-discussion-contribution-and-support)
## ¿Por qué quiero esto?
Si eres un administrador que ejecuta un clúster de Kubernetes en AWS, ya necesitas gestionar credenciales de AWS IAM para aprovisionar y actualizar el clúster.
Al usar AWS IAM Authenticator para Kubernetes, evitas tener que gestionar una credencial separada para el acceso a Kubernetes.
AWS IAM también proporciona una serie de propiedades útiles, como un registro de auditoría fuera de banda (a través de CloudTrail) y la aplicación de 2FA/MFA.
Si estás creando un instalador de Kubernetes en AWS, AWS IAM Authenticator para Kubernetes puede simplificar tu proceso de arranque.
No necesitarás pasar de forma encubierta tu credencial de administrador inicial de manera segura fuera de tu clúster recién instalado.
En su lugar, puedes crear un rol dedicado `KubernetesAdmin` en el momento del aprovisionamiento del clúster y configurar Authenticator para permitir inicios de sesión de administrador del clúster.
## ¿Cómo lo uso?
Suponiendo que tienes un clúster ejecutándose en AWS y quieres añadir soporte de AWS IAM Authenticator para Kubernetes, necesitas:
1. Crear un rol de IAM que usarás para identificar a los usuarios.
2. Ejecutar el servidor Authenticator como un DaemonSet.
3. Configurar tu servidor de API para comunicarse con Authenticator.
4. Configurar kubectl para usar tokens de Authenticator.
### 1. Crear un rol de IAM
Primero, debes crear uno o más roles de IAM que se asignarán a usuarios/grupos dentro de tu clúster de Kubernetes.
La forma más sencilla de hacerlo es iniciar sesión en la consola de AWS:
- Elige la opción "Role for cross-account access" / "Provide access between AWS accounts you own".
- Pega tu número de ID de cuenta de AWS (disponible en la esquina superior derecha de la consola).
- Tu rol no necesita que se le adjunte ninguna política adicional.
Esto creará un rol de IAM sin permisos que puede ser asumido por usuarios/roles autorizados en tu cuenta.
Anota el Nombre de recurso de Amazon (ARN) de tu rol, que necesitarás más adelante.
También puedes hacer esto en un solo paso usando la AWS CLI en lugar de la consola de 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'
```
También puedes omitir este paso y usar:
- Un rol existente (como un rol de acceso entre cuentas).
- Un usuario de IAM (consulta `mapUsers` a continuación).
- Una instancia de EC2 o un rol federado (consulta `mapRoles` a continuación).
### 2. Ejecutar el servidor
El servidor está pensado para ejecutarse en cada uno de tus nodos maestros como un DaemonSet con networking de host para que pueda exponer un puerto localhost.
Para ver un ejemplo de configuración de ConfigMap y DaemonSet, consulta [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example.yaml).
Antes de aplicarlo, actualiza estos valores para tu clúster:
- Reemplaza los ARN de IAM de marcador de posición (`arn:aws:iam::000000000000:...`) en `config.yaml`.
- Establece `clusterID` con un valor único para tu clúster.
- Verifica que las reglas de programación del DaemonSet coincidan con las etiquetas/taints de tus nodos del plano de control.
Luego despliégalo:
```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 vez que el pod se esté ejecutando en un nodo del plano de control, el `aws-iam-authenticator server` creará el kubeconfig del webhook en el host en `/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml` (o la ruta configurada mediante `--generate-kubeconfig`).
#### (Opcional) Pre-generar un certificado, una clave y un kubeconfig
Si estás creando un instalador automatizado, también puedes pre-generar fácilmente los archivos de certificado, clave y kubeconfig del webhook usando `aws-iam-authenticator init`.
Este comando generará los archivos y los colocará en los directorios de salida configurados.
Puedes ejecutar esto en cada nodo maestro antes de iniciar el servidor de API.
También podrías generarlos antes de aprovisionar los nodos maestros e instalarlos en las rutas de host adecuadas.
Si no pre-generas los archivos, `aws-iam-authenticator server` los generará bajo demanda.
Esto funciona, pero requiere que reinicies tu servidor de API de Kubernetes después de la instalación.
### 3. Configurar tu servidor de API para que se comunique con el servidor
La API de Kubernetes se integra con AWS IAM Authenticator for Kubernetes mediante un [webhook de autenticación por token](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication).
Cuando ejecutas `aws-iam-authenticator server`, este generará un archivo de configuración de webhook y lo guardará en el sistema de archivos del host.
Deberás añadir un único flag adicional a la configuración de tu servidor de API:
```
--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml
```
En muchos clústeres, el servidor de API se ejecuta como un pod estático.
Puedes añadir el flag a `/etc/kubernetes/manifests/kube-apiserver.yaml`.
Asegúrate de que el directorio del host `/etc/kubernetes/aws-iam-authenticator/` esté montado en tu pod del servidor de API.
También puede que necesites reiniciar el daemon kubelet en tu nodo maestro para que tome la definición actualizada del pod estático:
```
systemctl restart kubelet.service
```
### 4. Crear asignaciones de rol/usuario de IAM a usuario/grupo de kubernetes
El comportamiento predeterminado del servidor es obtener las asignaciones exclusivamente de los
campos `mapUsers` y `mapRoles` de su archivo de configuración. Consulte [Formato de
configuración completo](#full-configuration-format) a continuación para obtener más detalles.
Usando el flag `--backend-mode`, puede configurar el servidor para que obtenga
las asignaciones de dos backends adicionales: un ConfigMap de estilo EKS
(`--backend-mode=EKSConfigMap`) o recursos personalizados `IAMIdentityMapping`
(`--backend-mode=CRD`). El backend predeterminado, el archivo de configuración del servidor
que está montado por el pod del servidor, corresponde a `--backend-mode=MountedFile`.
Puede pasar una lista separada por comas de estos backends para que el servidor los busque
en orden. Por ejemplo, con `--backend-mode=EKSConfigMap,MountedFile`, el
servidor buscará asignaciones en el ConfigMap de estilo EKS y luego, si no
encuentra una asignación para el rol/usuario de IAM dado, en el archivo de configuración del servidor. Si una
asignación para el mismo rol/usuario de IAM existe en múltiples backends, el servidor
usará la asignación del backend que aparezca primero en la lista separada por comas.
En este ejemplo, si se encuentra una asignación en el ConfigMap de EKS, entonces se
usará independientemente de si existe una asignación duplicada o en conflicto en el archivo de
configuración del servidor.
Tenga en cuenta que al establecer un único backend, el servidor obtendrá asignaciones *solo* de
ese backend e ignorará los demás incluso si existen. Por ejemplo, con
`--backend-mode=CRD`, el servidor obtendrá asignaciones *solo* de `IAMIdentityMappings`
e ignorará el archivo montado y el ConfigMap de EKS.
#### `MountedFile`
Este es el backend predeterminado de asignaciones y es suficiente para la mayoría de los usuarios. Consulte
[Formato de configuración completo](#full-configuration-format) a continuación para obtener más detalles.
#### `CRD` (alpha)
Este backend modela cada asignación de IAM como un [Recurso personalizado de
Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) `IAMIdentityMapping`.
Este enfoque le permite mantener las asignaciones de forma nativa en Kubernetes usando
kubectl o la API. Además, los errores de sintaxis (como YAML desalineado) se pueden
detectar más fácilmente y no afectarán a todas las asignaciones.
Para configurar un CRD `IAMIdentityMapping`, primero deberá hacer `apply` del
manifiesto del CRD:
```
kubectl apply -f deploy/iamidentitymapping.yaml
```
Con los CRDs desplegados, puedes crear Custom Resources que modelen tus
Identidades IAM. Consulta
[`./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`
El ConfigMap `kube-system/aws-auth` al estilo de EKS sirve como backend. Se espera que el
ConfigMap tenga exactamente el mismo formato que en los clústeres de EKS:
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. Esto es
útil si estás migrando desde/hacia EKS y quieres conservar tus asignaciones, o si
ejecutas EKS además de algún otro clúster de AWS y quieres tener las mismas
asignaciones en cada uno.
#### `DynamicFile`
Un archivo local especificado por cfg.dynamicfilepath puede servir como backend. Se espera que el contenido
del archivo tenga exactamente el mismo formato que el EKSConfigMap. Cada vez que
cambie el contenido de este archivo, el autenticador lo recargará automáticamente. Esto
proporciona más flexibilidad para gestionar las asignaciones de ARN.
Consulta https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
para saber cómo configurar el modo DynamicFile.
Ejecuta `make e2e RUNNER=kind` para experimentar con un clúster kind con el modo DynamicFile habilitado.
### 5. Cómo configurar reservedPrefixConfig para nombres de usuario de Kubernetes
El aws-iam-authenticator puede admitir un prefijo reservado para el nombre de usuario de k8s. Si se establece el prefijo reservado,
entonces el nombre de usuario con el prefijo reservado no se autenticará con el error
"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
para saber cómo configurar el prefijo reservado.
### 6. Configurar kubectl para usar los tokens de autenticación proporcionados por AWS IAM Authenticator for Kubernetes
Finalmente, una vez que el servidor esté configurado querrás autenticarte.
Todavía necesitarás un `kubeconfig` que tenga los datos públicos sobre tu clúster (certificado CA del clúster, dirección del endpoint).
La sección `users` de tu configuración, sin embargo, debería incluir una sección exec ([consulta la documentación de plugins de credenciales de 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!
```
Esto significa que el `kubeconfig` es completamente datos públicos y puede compartirse entre todos los usuarios de Authenticator.
Puede tener sentido subirlo a una ubicación pública de confianza como AWS S3.
Asegúrate de tener instalado el binario `aws-iam-authenticator`.
Puedes instalarlo con `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest`.
Para autenticarte, ejecuta `kubectl --kubeconfig /path/to/kubeconfig" [...]`.
kubectl hará `exec` del binario `aws-iam-authenticator` con los parámetros proporcionados en tu kubeconfig, lo que generará un token y lo pasará al apiserver.
El token es válido durante 15 minutos (el valor más corto que AWS permite) y puede reutilizarse varias veces.
También puedes especificar el nombre de sesión al generar el token incluyendo el parámetro `--session-name o -s`. Este parámetro no puede usarse junto con `--forward-session-name`.
También puedes omitir `-r ROLE_ARN` para firmar el token con tus credenciales existentes sin asumir un rol dedicado.
Esto es útil si quieres autenticarte directamente como un usuario de IAM o si quieres autenticarte usando un rol de instancia EC2 o un rol federado.
## Uso con Kops
Los clústeres gestionados por [Kops](https://github.com/kubernetes/kops) pueden configurarse para usar Authenticator. Para obtener instrucciones de uso, consulta la [documentación de Kops](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator).
## ¿Cómo funciona?
Funciona utilizando el endpoint de la API [`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html) de AWS.
Este endpoint devuelve información sobre las credenciales de AWS IAM que uses para conectarte a él.
#### Lado del cliente (`aws-iam-authenticator token`)
Usamos esta API de una forma algo inusual, haciendo que el cliente de Authenticator genere y prefirme una solicitud al endpoint.
Serializamos esa solicitud en un token que puede pasar a través del sistema de autenticación de Kubernetes.
#### Lado del servidor (`aws-iam-authenticator server`)
El token pasa a través del servidor de la API de Kubernetes y llega al endpoint `/authenticate` del servidor de Authenticator mediante una configuración de webhook.
El servidor de Authenticator valida todos los parámetros de la solicitud prefirmada para asegurarse de que nada parezca sospechoso.
Luego envía la solicitud al servidor real `https://sts.amazonaws.com`, que valida la firma HMAC del cliente y devuelve información sobre el usuario.
Ahora que el servidor conoce la identidad de AWS del cliente, traduce esta identidad en un usuario y grupos de Kubernetes mediante un mapeo estático simple.
Este mecanismo está tomado, con algunos cambios, de [Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method).
## ¿Qué es un ID de clúster?
El ID de clúster de Authenticator es un identificador único por clúster que previene ciertos ataques de repetición.
Específicamente, evita que un servidor de Authenticator (por ejemplo, en un entorno de desarrollo) use el token de un cliente para autenticarse en otro servidor de Authenticator en otro clúster.
El ID de clúster sí necesita ser único por clúster, pero no necesita ser secreto.
Algunas buenas opciones son:
- Un ID aleatorio, como el generado por `openssl rand 16 -hex`
- El nombre de dominio de tu servidor de la API de Kubernetes
La [documentación de Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) también explica este ataque (ver `X-Vault-AWS-IAM-Server-ID`).
## Especificación de credenciales y uso de perfiles de AWS
Las credenciales pueden especificarse para su uso con `aws-iam-authenticator` mediante cualquiera de los métodos disponibles para el
[AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials).
Esto incluye especificar credenciales de AWS con variables de entorno o utilizando un archivo de credenciales.
Los [perfiles con nombre](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) de AWS son compatibles con `aws-iam-authenticator`
mediante la variable de entorno `AWS_PROFILE`. Por ejemplo, para autenticarse con las credenciales especificadas en el perfil _dev_, se puede exportar `AWS_PROFILE`
o especificarlo explícitamente (p. ej., `AWS_PROFILE=dev kubectl get all`). Si no se establece `AWS_PROFILE`, se utiliza el perfil _default_.
`AWS_PROFILE` también se puede especificar directamente en el archivo kubeconfig
[como parte del flujo `exec`](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration). Por ejemplo, para especificar
que `aws-iam-authenticator` siempre debe usar las credenciales del perfil con nombre _dev_, tu kubeconfig incluiría una clave `env`
que establece el 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 el perfil adecuado se utilice de forma implícita. Tenga en cuenta que cualquier variable de entorno establecida como parte del flujo de `exec` tendrá
precedencia sobre lo que ya está establecido en su entorno.
#### Nota para usuarios federados:
Los usuarios federados de AWS a menudo tendrán un atributo "significativo" mapeado en su rol asumido, como una dirección de correo electrónico, a través de la configuración de AWS de la cuenta.
Estas sesiones asumidas tienen [varias partes](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable), el `role id`
y el `caller-specified-role-name`. De forma predeterminada, cuando un usuario federado utiliza la opción `--role` de `aws-iam-authenticator` para asumir un nuevo rol, el
`caller-specified-role-name` se convertirá en un token aleatorio y el `role id` se mantendrá en el rol recién asumido.
Usar `aws-iam-authenticator token ... --forward-session-name` mapeará el atributo original `caller-specified-role-name` en la nueva sesión asumida de STS.
Esto puede ser útil para intentar rápidamente asociar "quién realizó la acción X en el clúster de K8".
Tenga en cuenta que **esto no debe considerarse definitivo** y debe cotejarse mediante el `role id` (que permanece consistente) con los registros de CloudTrail,
ya que un usuario podría potencialmente cambiar esto en el lado del cliente.
## Autorización de API desde fuera de un clúster
Es posible realizar solicitudes a la API de Kubernetes desde un cliente que esté fuera del clúster, ya sea usando la
API REST de Kubernetes directamente o desde uno de los clientes de Kubernetes específicos de cada lenguaje
(p. ej., [Python](https://github.com/kubernetes-client/python)). Para ello, debe crear un token de portador que
se incluya con la solicitud a la API. Este token de portador requiere que añada la cadena `k8s-aws-v1.` con una
cadena codificada en base64 de una solicitud HTTP firmada a la API de consulta GetCallerIdentity de STS. Luego, esto se envía en el
encabezado `Authorization` de la solicitud. Sin embargo, algo a tener en cuenta es que el Autenticador de IAM omite explícitamente
el relleno de base64 para evitar cualquier carácter `=` y así garantizar una cadena segura para usar en URL. A continuación se muestra un ejemplo en
Python de cómo se construiría este 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')}
```
## Solución de problemas
Si tu cliente falla con un error como `could not get token: AccessDenied [...]`, puedes intentar asumir el rol directamente 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
```
Si eso falla, hay algunos problemas posibles que debes verificar:
- Asegúrate de que tus credenciales base de AWS estén disponibles en tu shell (`aws sts get-caller-identity` puede ayudar a solucionar esto).
- Asegúrate de que el rol de destino permita el acceso de tu cuenta de origen (en la política de confianza del rol).
- Asegúrate de que tu principal de origen (usuario/rol/grupo) tenga una política de IAM que permita `sts:AssumeRole` para el rol de destino.
- Asegúrate de no tener políticas de denegación explícitas adjuntas a tu usuario, grupo o en AWS Organizations que impidan el `sts:AssumeRole`.
- Intenta simular la llamada `sts:AssumeRole` en el [Simulador de políticas](https://policysim.aws.amazon.com/home/index.jsp).
## Formato de configuración completo
El cliente y el servidor tienen el mismo formato de configuración.
Pueden compartir exactamente el mismo archivo de configuración, ya que no se almacenan secretos en la configuración.
```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
```
## Desarrollo
Consulte la página de [desarrollo](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/docs/development.md).
## Comunidad, discusión, contribución y soporte
Aprenda cómo participar en la comunidad de Kubernetes en la [página de la comunidad](http://kubernetes.io/community/).
Puede contactar con los mantenedores de este proyecto en:
- [Slack](https://kubernetes.slack.com/messages/sig-aws)
- [Lista de correo](https://groups.google.com/forum/#!forum/kubernetes-sig-aws)
### Código de conducta
La participación en la comunidad de Kubernetes se rige por el [Código de Conducta de Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/code-of-conduct.md).