Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Identity and Access Management

Identity and Access Management (IAM) es un servicio de AWS que realiza dos funciones esenciales: autenticación y autorización. La autenticación implica la verificación de una identidad, mientras que la autorización regula las acciones que pueden realizar los recursos de AWS. Dentro de AWS, un recurso puede ser otro servicio de AWS, por ejemplo EC2, o un director de AWS, como un usuario o rol de IAM. Las normas que rigen las acciones que un recurso puede realizar se expresan como políticas de IAM.

Control del acceso a los clústeres de EKS

El proyecto Kubernetes admite una variedad de estrategias diferentes para autenticar las solicitudes del servicio kube-apiserver, por ejemplo, los tokens Bearer, los certificados X.509, el OIDC, etc. Actualmente, EKS cuenta con soporte nativo para la autenticación mediante token webhook, para los tokens de cuentas de servicio y, a partir del 21 de febrero de 2021, para la autenticación OIDC.

La estrategia de autenticación de webhook denomina webhook a un webhook que verifica los tokens portadores. En EKS, estos tokens portadores los genera la AWS CLI o el aws-iam-authenticatorcliente cuando se ejecutan kubectl comandos. A medida que ejecuta los comandos, el token se pasa al kube-apiserver, que lo reenvía al webhook de autenticación. Si la solicitud está bien formada, el webhook llama a una URL prefirmada incrustada en el cuerpo del token. Esta URL valida la firma de la solicitud y devuelve información sobre el usuario, por ejemplo, la cuenta del usuario, Arn, y al kube-apiserver. UserId

Para generar manualmente un token de autenticación, escribe el siguiente comando en una ventana de terminal:

aws eks get-token --cluster-name <cluster_name>

También puedes obtener un token mediante programación. A continuación se muestra un ejemplo escrito en Go:

package main

import (
  "fmt"
  "log"
  "sigs.k8s.io/aws-iam-authenticator/pkg/token"
)

func main()  {
  g, _ := token.NewGenerator(false, false)
  tk, err := g.Get("<cluster_name>")
  if err != nil {
    log.Fatal(err)
  }
  fmt.Println(tk)
}

El resultado debería ser similar al siguiente:

{
  "kind": "ExecCredential",
  "apiVersion": "client.authentication.k8s.io/v1alpha1",
  "spec": {},
  "status": {
    "expirationTimestamp": "2020-02-19T16:08:27Z",
    "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFKTkdSSUxLTlNSQzJXNVFBJTJGMjAyMDAyMTklMkZ1cy1lYXN0LTElMkZzdHMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIwMDIxOVQxNTU0MjdaJlgtQW16LUV4cGlyZXM9NjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JTNCeC1rOHMtYXdzLWlkJlgtQW16LVNpZ25hdHVyZT0yMjBmOGYzNTg1ZTMyMGRkYjVlNjgzYTVjOWE0MDUzMDFhZDc2NTQ2ZjI0ZjI4MTExZmRhZDA5Y2Y2NDhhMzkz"
  }
}

Cada token comienza k8s-aws-v1. seguido de una cadena codificada en base64. La cadena, una vez decodificada, debería parecerse a algo parecido a esto:

https://sts.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXJPFRILKNSRC2W5QA%2F20200219%2Fus-xxxx-1%2Fsts%2Faws4_request&X-Amz-Date=20200219T155427Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&X-Amz-Signature=XXXf8f3285e320ddb5e683a5c9a405301ad76546f24f28111fdad09cf648a393

El token consiste en una URL prefirmada que incluye una credencial y una firma de Amazon. Para obtener más información, consulta https://docs.aws.amazon.com/STS/latest/APIReference/API_ GetCallerIdentity .html.

El token tiene un tiempo de vida (TTL) de 15 minutos, tras lo cual será necesario generar un nuevo token. Esto se gestiona automáticamente cuando utilizas un cliente, por ejemplokubectl, si utilizas el panel de control de Kubernetes, tendrás que generar un nuevo token y volver a autenticarte cada vez que el token caduque.

Una vez que el servicio IAM de AWS haya autenticado la identidad del usuario, el kube-apiserver la lee aws-auth ConfigMap en el espacio de kube-system nombres para determinar el grupo RBAC que se va a asociar al usuario. aws-auth ConfigMap Se utiliza para crear un mapeo estático entre los principales de IAM, es decir, los usuarios y roles de IAM, y los grupos RBAC de Kubernetes. Se puede hacer referencia a los grupos RBAC en Kubernetes o. RoleBindings ClusterRoleBindings Son similares a las funciones de IAM en el sentido de que definen un conjunto de acciones (verbos) que se pueden realizar en un conjunto de recursos (objetos) de Kubernetes.

Administrador de acceso a clústeres

Cluster Access Manager, que ahora es la forma preferida de administrar el acceso de los principales de AWS IAM a los clústeres de Amazon EKS, es una funcionalidad de la API de AWS y es una función opcional para los clústeres de EKS v1.23 y versiones posteriores (nuevos o existentes). Simplifica el mapeo de identidades entre AWS IAM y KubernetesRBACs, lo que elimina la necesidad de cambiar entre AWS y Kubernetes APIs o de editarlo aws-auth ConfigMap para la administración del acceso, reduce la sobrecarga operativa y ayuda a corregir los errores de configuración. La herramienta también permite a los administradores de clústeres revocar o restringir cluster-admin los permisos concedidos automáticamente al director de AWS IAM utilizado para crear el clúster.

Esta API se basa en dos conceptos:

En el momento del lanzamiento, Amazon EKS solo admite políticas predefinidas y administradas por AWS. Las políticas de acceso no son entidades de IAM y las define y administra Amazon EKS.

Cluster Access Manager permite combinar el RBAC previo con políticas de acceso que permiten permitir y transferir (pero no denegar) las decisiones de AuthZ de Kubernetes en relación con las solicitudes de servidores de API. Se tomará una decisión de denegación cuando los autorizadores anteriores del RBAC y Amazon EKS no puedan determinar el resultado de la evaluación de una solicitud.

Con esta función, Amazon EKS admite tres modos de autenticación:

Para empezar, los administradores de clústeres pueden crear o actualizar los clústeres de Amazon EKS, configurar el API método de autenticación preferido y definir entradas de acceso para conceder el acceso a los principales de AWS IAM deseados. API_AND_CONFIG_MAP

$ aws eks create-cluster \
    --name <CLUSTER_NAME> \
    --role-arn <CLUSTER_ROLE_ARN> \
    --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \
    --access-config authenticationMode=API_AND_CONFIG_MAP,bootstrapClusterCreatorAdminPermissions=false

El comando anterior es un ejemplo de cómo crear un clúster de Amazon EKS que ya no tiene los permisos de administrador del creador del clúster.

Es posible actualizar la configuración de los clústeres de Amazon EKS para habilitar API AuthenticationMode mediante el update-cluster-config comando. Para hacerlo en los clústeres existentes, primero CONFIG_MAP tendrá que actualizar a API_AND_CONFIG_MAP y luego a. API Estas operaciones no se pueden revertir, lo que significa que no es posible cambiar de API a API_AND_CONFIG_MAP o ni CONFIG_MAP tampoco de a. API_AND_CONFIG_MAP CONFIG_MAP

$ aws eks update-cluster-config \
    --name <CLUSTER_NAME> \
    --access-config authenticationMode=API

La API admite comandos para añadir y revocar el acceso al clúster, así como para validar las políticas de acceso y las entradas de acceso existentes para el clúster especificado. Las políticas predeterminadas se crean para que coincidan con RBACs Kubernetes de la siguiente manera.

$ aws eks list-access-policies
{
    "accessPolicies": [
        {
            "name": "AmazonEKSAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
        },
        {
            "name": "AmazonEKSClusterAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        },
        {
            "name": "AmazonEKSEditPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        },
        {
            "name": "AmazonEKSViewPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
        }
    ]
}

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

No hay entradas de acceso disponibles cuando el clúster se crea sin el permiso de administrador del creador del clúster, que es la única entrada que se crea de forma predeterminada.

El aws-auth ConfigMap (obsoleto)

Una forma de realizar la integración de Kubernetes con la autenticación de AWS es a través del aws-auth ConfigMap, que reside en el espacio de nombres. kube-system Es responsable de asignar la autenticación de las identidades de IAM (usuarios, grupos y roles) de AWS a la autorización del control de acceso basado en roles (RBAC) de Kubernetes. aws-auth ConfigMap Se crea automáticamente en su clúster de Amazon EKS durante la fase de aprovisionamiento. Se creó inicialmente para permitir que los nodos se unieran a su clúster, pero como se ha mencionado, también puede usarlo ConfigMap para añadir RBACs acceso a los principios de IAM.

Para comprobar el clúster aws-auth ConfigMap, puede utilizar el siguiente comando.

kubectl -n kube-system get configmap aws-auth -o yaml

Este es un ejemplo de la configuración predeterminada del aws-authConfigMap.

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      - system:node-proxier
      rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/kube-system-<SELF_GENERATED_UUID>
      username: system:node:{{SessionName}}
kind: ConfigMap
metadata:
  creationTimestamp: "2023-10-22T18:19:30Z"
  name: aws-auth
  namespace: kube-system

La sesión principal de esta ConfigMap, se encuentra debajo data del mapRoles bloque, que está compuesto básicamente por 3 parámetros.

También es posible mapear los permisos para los usuarios de AWS IAM, definiendo un nuevo bloque de configuración paramapUsers, data en el aws-authConfigMap, reemplazar el parámetro rolearn por userarn. Sin embargo, como práctica recomendada, siempre se recomienda al usuario en su lugar. mapRoles

Para administrar los permisos, puede editar el acceso para aws-auth ConfigMap añadir o eliminar el acceso a su clúster de Amazon EKS. Si bien es posible editarlo aws-auth ConfigMap manualmente, se recomienda utilizar herramientas como estaseksctl, ya que se trata de una configuración muy delicada y una configuración imprecisa puede bloquearlo fuera de su Amazon EKS Cluster. Consulte la subsección Uso de herramientas para realizar cambios en el ConfigMap aws-auth que aparece a continuación para obtener más información.

Recomendaciones de acceso a clústeres

Haga que el punto final del clúster EKS sea privado

De forma predeterminada, al aprovisionar un clúster de EKS, el punto final del clúster de API está configurado como público, es decir, se puede acceder a él desde Internet. A pesar de ser accesible desde Internet, el punto final sigue considerándose seguro porque requiere que todas las solicitudes de API sean autenticadas por IAM y luego autorizadas por el RBAC de Kubernetes. Dicho esto, si su política de seguridad corporativa exige que restrinja el acceso a la API desde Internet o le impide enrutar el tráfico fuera de la VPC del clúster, puede:

No utilices un token de cuenta de servicio para la autenticación

Un token de cuenta de servicio es una credencial estática de larga duración. Si se ve comprometida, se pierde o es robada, es posible que un atacante pueda realizar todas las acciones asociadas a ese token hasta que se elimine la cuenta de servicio. En ocasiones, es posible que tengas que conceder una excepción a las aplicaciones que tienen que consumir la API de Kubernetes desde fuera del clúster, por ejemplo, una aplicación de canalización de CI/CD. Si dichas aplicaciones se ejecutan en la infraestructura de AWS, como EC2 instancias, considere la posibilidad de usar un perfil de instancia y asignarlo a una función de RBAC de Kubernetes.

Emplee el acceso menos privilegiado a los recursos de AWS

No es necesario que a un usuario de IAM se le asignen privilegios a los recursos de AWS para acceder a la API de Kubernetes. Si necesita conceder a un usuario de IAM acceso a un clúster de EKS, cree una entrada aws-auth ConfigMap para ese usuario que se asigne a un grupo RBAC de Kubernetes específico.

Elimine los permisos de administrador del clúster del principal creador del clúster

De forma predeterminada, los clústeres de Amazon EKS se crean con un cluster-admin permiso permanente vinculado al creador principal del clúster. Con la API Cluster Access Manager, es posible crear clústeres sin este permiso, configurando el --access-config bootstrapClusterCreatorAdminPermissions modo de API autenticaciónfalse, cuándo se utiliza API_AND_CONFIG_MAP o si se utiliza. Revocar este acceso se considera una práctica recomendada para evitar cambios no deseados en la configuración del clúster. El proceso para revocar este acceso sigue el mismo proceso para revocar cualquier otro acceso al clúster.

La API le brinda la flexibilidad de disociar únicamente un director de IAM de una política de acceso, en este caso, la. AmazonEKSClusterAdminPolicy

$ aws eks list-associated-access-policies \
    --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN>

$ aws eks disassociate-access-policy --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN. \
    --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy

O eliminar por completo la entrada de acceso asociada al cluster-admin permiso.

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

$ aws eks delete-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>

Este acceso se puede volver a conceder si es necesario en caso de incidente, emergencia o rotura de un cristal en el que el clúster quede inaccesible de otro modo.

Si el clúster sigue configurado con el método de CONFIG_MAP autenticación, se debe conceder acceso al clúster a todos los usuarios adicionales a través de la aws-auth ConfigMap función asignada a la entidad que creó el clúster y, una vez aws-auth ConfigMap configurada, se puede eliminar y solo volver a crear en caso de incidente, emergencia o rotura de cristales, o cuando aws-auth ConfigMap esté dañado y el clúster sea inaccesible de otro modo. Esto puede resultar especialmente útil en los clústeres de producción.

Utilice las funciones de IAM cuando varios usuarios necesiten un acceso idéntico al clúster

En lugar de crear una entrada para cada usuario de IAM individual, permita que esos usuarios asuman un rol de IAM y asignen ese rol a un grupo RBAC de Kubernetes. Esto será más fácil de mantener, especialmente a medida que aumente el número de usuarios que requieren acceso.

Si sigue utilizando aws-auth ConfigMap como método de autenticación, al asignar permisos RBAC de K8s a un rol de IAM, debe incluir\ {{}} en su nombre de usuario. SessionName De esta forma, el registro de auditoría registrará el nombre de la sesión para que pueda hacer un seguimiento de quién es el usuario real que asume esta función junto con el registro. CloudTrail

- rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testRole
  username: testRole:{{SessionName}}
  groups:
    - system:masters

Emplee el acceso menos privilegiado al crear y RoleBindings ClusterRoleBindings

Como en el punto anterior sobre la concesión de acceso a los recursos de AWS, RoleBindings y solo ClusterRoleBindings debe incluir el conjunto de permisos necesarios para realizar una función específica. Evite ["*"] utilizarlos en sus funciones y ClusterRoles a menos que sea absolutamente necesario. Si no estás seguro de qué permisos asignar, considera usar una herramienta como audit2rbac para generar automáticamente las funciones y los enlaces en función de las llamadas a la API observadas en el registro de auditoría de Kubernetes.

Crea un clúster mediante un proceso automatizado

Como se ha visto en los pasos anteriores, al crear un clúster de Amazon EKS, si no se utiliza el modo de uso API_AND_CONFIG_MAP o API autenticación y no se opta por no delegar cluster-admin los permisos al creador del clúster, al usuario o rol de la entidad de IAM, como el usuario federado que crea el clúster, se le conceden automáticamente system:masters permisos en la configuración RBAC del clúster. A pesar de ser una buena práctica eliminar este permiso, como se describe aquí, si se utiliza el método de CONFIG_MAP autenticación, se basa en aws-auth ConfigMap él, este acceso no se puede revocar. Por lo tanto, es una buena idea crear el clúster con una canalización de automatización de infraestructuras vinculada a una función específica de IAM, sin permisos que puedan ser asumidos por otros usuarios o entidades, y auditar periódicamente los permisos, las políticas y las personas que tienen acceso a esta función para activar la canalización. Además, esta función no debe usarse para realizar acciones rutinarias en el clúster, sino que debe usarse exclusivamente para acciones a nivel de clúster activadas por la canalización, por ejemplo, mediante cambios en el código de SCM.

Cree el clúster con una función de IAM dedicada

Al crear un clúster de Amazon EKS, al usuario o rol de la entidad de IAM, como un usuario federado que crea el clúster, se le conceden automáticamente system:masters permisos en la configuración RBAC del clúster. Este acceso no se puede eliminar y no se administra a través de. aws-auth ConfigMap Por lo tanto, es una buena idea crear el clúster con una función de IAM dedicada y auditar periódicamente quién puede asumir esta función. Esta función no debe utilizarse para realizar acciones rutinarias en el clúster, sino que se debe conceder acceso al clúster a otros usuarios a través del mismo con este aws-auth ConfigMap fin. Una vez aws-auth ConfigMap configurado, el rol debe estar protegido y solo debe usarse en el modo de privilegios elevados o rotura de cristales temporales en situaciones en las que el clúster sea inaccesible de otro modo. Esto puede resultar particularmente útil en clústeres que no tienen configurado el acceso directo de los usuarios.

Audite periódicamente el acceso al clúster

Es probable que las personas que necesitan el acceso cambien con el tiempo. Planifique auditarlo periódicamente aws-auth ConfigMap para ver a quién se le ha concedido el acceso y los derechos que se le han asignado. También puedes usar herramientas de código abierto kubectl-who-can, como rbac-lookup, para examinar las funciones vinculadas a una cuenta de servicio, usuario o grupo en particular. Exploraremos este tema con más detalle cuando lleguemos a la sección sobre auditoría. Puede encontrar ideas adicionales en este artículo de NCC Group.

Si confía en aws-auth ConfigMap, use herramientas para realizar cambios.

Un aws-auth mal formateado ConfigMap puede provocar que pierda el acceso al clúster. Si necesita realizar cambios en, utilice una herramienta. ConfigMap

eksctl La eksctl CLI incluye un comando para añadir mapeos de identidad a aws-auth. ConfigMap

Ver la ayuda de CLI:

$ eksctl create iamidentitymapping --help
...

Compruebe las identidades asignadas a su clúster de Amazon EKS.

$ eksctl get iamidentitymapping --cluster $CLUSTER_NAME --region $AWS_REGION
ARN                                                                   USERNAME                        GROUPS                                                  ACCOUNT
arn:aws:iam::788355785855:role/kube-system-<SELF_GENERATED_UUID>      system:node:{{SessionName}}     system:bootstrappers,system:nodes,system:node-proxier

Convierta a un rol de IAM en administrador de clústeres:

$ eksctl create iamidentitymapping --cluster  <CLUSTER_NAME> --region=<region> --arn arn:aws:iam::123456:role/testing --group system:masters --username admin
...

Para obtener más información, consulte los documentos eksctl

aws-auth de keikoproj

aws-authde keikoproj incluye una biblioteca cli y una biblioteca go.

Descargue y vea la ayuda de la CLI:

$ go get github.com/keikoproj/aws-auth
...
$ aws-auth help
...

Como alternativa, instálalo aws-auth con el administrador de complementos krew para kubectl.

$ kubectl krew install aws-auth
...
$ kubectl aws-auth
...

Consulta la documentación de aws-auth GitHub para obtener más información, incluida la biblioteca go.

AWS IAM Authenticator CLI

El aws-iam-authenticator proyecto incluye una CLI para actualizar elConfigMap.

Descargue una versión el GitHub.

Añada permisos de clúster a un rol de IAM:

$ ./aws-iam-authenticator add role --rolearn arn:aws:iam::185309785115:role/lil-dev-role-cluster --username lil-dev-user --groups system:masters --kubeconfig ~/.kube/config
...

Enfoques alternativos para la administración de la autenticación y el acceso

Si bien la IAM es la forma preferida de autenticar a los usuarios que necesitan acceder a un clúster de EKS, es posible utilizar un proveedor de identidad OIDC, por ejemplo, GitHub mediante un proxy de autenticación y la suplantación de identidad de Kubernetes. Se han publicado artículos sobre dos de estas soluciones en el blog de código abierto de AWS:

También puede usar AWS SSO para federar AWS con un proveedor de identidad externo, por ejemplo, Azure AD. Si decide usarlo, la AWS CLI v2.0 incluye una opción para crear un perfil con nombre que le permite asociar fácilmente una sesión de SSO a su sesión de CLI actual y asumir una función de IAM. Tenga en cuenta que debe asumir una función antes de correr, kubectl ya que la función de IAM se utiliza para determinar el grupo RBAC de Kubernetes del usuario.

Identidades y credenciales para los pods de EKS

Algunas aplicaciones que se ejecutan dentro de un clúster de Kubernetes necesitan permiso para llamar a la API de Kubernetes para funcionar correctamente. Por ejemplo, el controlador Load Balancer de AWS debe poder enumerar los puntos de enlace de un servicio. El controlador también debe poder invocar a AWS para APIs aprovisionar y configurar un ALB. En esta sección analizaremos las prácticas recomendadas para asignar derechos y privilegios a los pods.

Cuentas de servicio de Kubernetes

Una cuenta de servicio es un tipo especial de objeto que permite asignar una función RBAC de Kubernetes a un pod. Se crea automáticamente una cuenta de servicio predeterminada para cada espacio de nombres de un clúster. Al implementar un pod en un espacio de nombres sin hacer referencia a una cuenta de servicio específica, la cuenta de servicio predeterminada de ese espacio de nombres se asignará automáticamente al pod y el secreto, es decir, el token de la cuenta de servicio (JWT) de esa cuenta de servicio, se montará en el pod como un volumen en. /var/run/secrets/kubernetes.io/serviceaccount Al decodificar el token de la cuenta de servicio en ese directorio, se mostrarán los siguientes metadatos:

{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-5pv4z",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "3b36ddb5-438c-11ea-9438-063a49b60fba",
  "sub": "system:serviceaccount:default:default"
}

La cuenta de servicio predeterminada tiene los siguientes permisos para la API de Kubernetes.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2020-01-30T18:13:25Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "43"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery
  uid: 350d2ab8-438c-11ea-9438-063a49b60fba
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /version
  - /version/
  verbs:
  - get

Esta función autoriza a los usuarios autenticados y no autenticados a leer la información de la API y se considera segura si es de acceso público.

Cuando una aplicación que se ejecuta en un pod llama a Kubernetes APIs, es necesario asignar al pod una cuenta de servicio que le conceda permiso explícito para llamarlos. APIs De forma similar a las directrices para el acceso de los usuarios, el rol ClusterRole o el vínculo a una cuenta de servicio debe restringirse a los recursos y métodos de la API que la aplicación necesita para funcionar, y nada más. Para usar una cuenta de servicio que no sea la predeterminada, simplemente establece en el spec.serviceAccountName campo de un pod el nombre de la cuenta de servicio que deseas usar. Para obtener información adicional sobre la creación de cuentas de servicio, consulta https://kubernetes. io/docs/reference/access-authn-authz/rbac/#. service-account-permissions

Funciones de IAM para cuentas de servicio (IRSA)

El IRSA es una función que permite asignar una función de IAM a una cuenta de servicio de Kubernetes. Funciona aprovechando una función de Kubernetes conocida como proyección del volumen de tokens de cuentas de servicio. Cuando los pods se configuran con una cuenta de servicio que hace referencia a un rol de IAM, el servidor de la API de Kubernetes llamará al punto de conexión público del OIDC para detectar el clúster al iniciarse. El punto final firma criptográficamente el token OIDC emitido por Kubernetes y el token resultante se monta como un volumen. Este token firmado permite al Pod llamar a la función de IAM APIs asociada a AWS. Cuando se invoca una API de AWS, AWS SDKs llamasts:AssumeRoleWithWebIdentity. Tras validar la firma del token, IAM cambia el token emitido por Kubernetes por una credencial de rol de AWS temporal.

Al usar IRSA, es importante reutilizar las sesiones del SDK de AWS para evitar llamadas innecesarias a AWS STS.

Al decodificar el token (JWT) para IRSA, se obtendrá un resultado similar al del ejemplo que se muestra a continuación:

{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1582306514,
  "iat": 1582220114,
  "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "alpine-57b5664646-rf966",
      "uid": "5a20f883-5407-11ea-a85c-0e62b7a4a436"
    },
    "serviceaccount": {
      "name": "s3-read-only",
      "uid": "a720ba5c-5406-11ea-9438-063a49b60fba"
    }
  },
  "nbf": 1582220114,
  "sub": "system:serviceaccount:default:s3-read-only"
}

Este token en concreto otorga al Pod privilegios de solo visualización a S3 al asumir una función de IAM. Cuando la aplicación intenta leer desde S3, el token se cambia por un conjunto temporal de credenciales de IAM similar al siguiente:

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA36C6WWEJULFUYMPB6:abc",
        "Arn": "arn:aws:sts::123456789012:assumed-role/eksctl-winterfell-addon-iamserviceaccount-de-Role1-1D61LT75JH3MB/abc"
    },
    "Audience": "sts.amazonaws.com",
    "Provider": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
    "SubjectFromWebIdentityToken": "system:serviceaccount:default:s3-read-only",
    "Credentials": {
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "FwoGZXIvYXdzEGMaDMLxAZkuLpmSwYXShiL9A1S0X87VBC1mHCrRe/pB2oesl1eXxUYnPJyC9ayOoXMvqXQsomq0xs6OqZ3vaa5Iw1HIyA4Cv1suLaOCoU3hNvOIJ6C94H1vU0siQYk7DIq9Av5RZeuE2FnOctNBvYLd3i0IZo1ajjc00yRK3v24VRq9nQpoPLuqyH2jzlhCEjXuPScPbi5KEVs9fNcOTtgzbVf7IG2gNiwNs5aCpN4Bv/Zv2A6zp5xGz9cWj2f0aD9v66vX4bexOs5t/YYhwuwAvkkJPSIGvxja0xRThnceHyFHKtj0Hbi/PWAtlI8YJcDX69cM30JAHDdQHltm/4scFptW1hlvMaPWReCAaCrsHrATyka7ttw5YlUyvZ8EPogj6fwHlxmrXM9h1BqdikomyJU00gm1FJelfP1zAwcyrxCnbRl3ARFrAt8hIlrT6Vyu8WvWtLxcI8KcLcJQb/LgkWsCTGlYcY8z3zkigJMbYn07ewTL5Ss7LazTJJa758I7PZan/v3xQHd5DEc5WBneiV3iOznDFgup0VAMkIviVjVCkszaPSVEdK2NU7jtrh6Jfm7bU/3P6ZGCkyDLIa8MBn9KPXeJd/yjTk5IifIwO/mDpGNUribg6TPxhzZ8b/XdZO1kS1gVgqjXyVCM+BRBh6C4H21w/eMzjCtDIpoxt5rGKL6Nu/IFMipoC4fgx6LIIHwtGYMG7SWQi7OsMAkiwZRg0n68/RqWgLzBt/4pfjSRYuk=",
        "Expiration": "2020-02-20T18:49:50Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

Un webhook mutante que se ejecuta como parte del plano de control de EKS inyecta el ARN del rol de AWS y la ruta a un archivo de token de identidad web en el pod como variables de entorno. Estos valores también se pueden proporcionar manualmente.

AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

El kubelet rotará automáticamente el token proyectado cuando tenga más del 80% de su TTL total o después de 24 horas. La AWS SDKs es responsable de volver a cargar el token cuando gira. Para obtener más información sobre IRSA, consulte https://docs.aws.amazon.com/eks/ latest/userguide/iam - -technical-overview.html. roles-for-service-accounts

Pod Identities de EKS

EKS Pod Identities es una función lanzada en re:Invent 2023 que le permite asignar una función de IAM a una cuenta de servicio de Kubernetes, sin necesidad de configurar un proveedor de identidades (IDP) de Open Id Connect (OIDC) para cada clúster de su cuenta de AWS. Para utilizar EKS Pod Identity, debe implementar un agente que se ejecute como un pod en todos los nodos de trabajo aptos. DaemonSet Este agente está disponible como complemento de EKS y es un requisito previo para utilizar la función EKS Pod Identity. Sus aplicaciones deben usar una versión compatible del SDK de AWS para usar esta función.

Cuando las identidades de pod de EKS estén configuradas para un pod, EKS montará y actualizará un token de identidad de pod en/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token. El SDK de AWS utilizará este token para comunicarse con el agente de identidad del pod de EKS, que utiliza el token de identidad del pod y la función de IAM del agente para crear credenciales temporales para los pods mediante una llamada a la AssumeRoleForPodIdentityAPI. El token de identidad del pod que se entrega a sus pods es un JWT emitido desde su clúster de EKS y firmado criptográficamente, junto con las declaraciones de JWT correspondientes para su uso con las identidades de los pods de EKS.

Para obtener más información sobre las identidades de los pods de EKS, consulta este blog.

No es necesario realizar ninguna modificación en el código de la aplicación para utilizar EKS Pod Identities. Las versiones de AWS SDK compatibles descubrirán automáticamente las credenciales disponibles con EKS Pod Identities mediante la cadena de proveedores de credenciales. Al igual que IRSA, las identidades de los pods de EKS establecen variables dentro de los pods para indicarles cómo encontrar las credenciales de AWS.

Trabajando con las funciones de IAM para EKS Pod Identities

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceOrgId": "${aws:ResourceOrgId}"
        }
      }
    }
  ]
}

AWS recomienda utilizar claves de condición, por ejemplo, aws:SourceOrgId para ayudar a protegerse contra el problema de los diputados confusos entre servicios. En el ejemplo anterior de política de confianza de roles, ResourceOrgId es una variable igual al ID de organización de AWS Organizations de la organización de AWS a la que pertenece la cuenta de AWS. EKS transferirá un valor aws:SourceOrgId igual a ese valor cuando asuma un rol con EKS Pod Identities.

Identidades de pod ABAC y EKS

Cuando EKS Pod Identities asume una función de IAM, establece las siguientes etiquetas de sesión:

Estas etiquetas de sesión le permiten usar el control de acceso basado en atributos (ABAC) para conceder acceso a sus recursos de AWS únicamente a cuentas de servicio de Kubernetes específicas. Al hacerlo, es muy importante entender que las cuentas de servicio de kubernetes solo son únicas dentro de un espacio de nombres, y los espacios de nombres de kubernetes solo son únicos dentro de un clúster de EKS. Se puede acceder a estas etiquetas de sesión en las políticas de AWS mediante la clave de condición aws:PrincipalTag/<tag-key> global, como aws:PrincipalTag/eks-cluster-arn

Por ejemplo, si quisiera conceder acceso solo a una cuenta de servicio específica para acceder a un recurso de AWS de su cuenta con una política de recursos o de IAM, tendría que comprobar eks-cluster-arn y kubernetes-namespace etiquetar, así como asegurarse de que solo las cuentas de servicio del clúster deseado tengan acceso kubernetes-service-account a ese recurso, ya que otros clústeres podrían tener acceso a ese recurso, ya que otros clústeres podrían tener el mismo kubernetes-service-accounts ykubernetes-namespaces.

Este ejemplo de política de bucket de S3 solo concede acceso a los objetos del bucket de S3 al que está conectado, solo si kubernetes-service-account eks-cluster-arn todos cumplen los valores esperados, donde el clúster de EKS está alojado en la cuenta de AWS111122223333. kubernetes-namespace

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "s3:*",
            "Resource":            [
                "arn:aws:s3:::ExampleBucket/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "s3objectservice",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-west-2:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "s3datanamespace"
                }
            }
        }
    ]
}

Comparación de las identidades de los pods de EKS con las de IRSA

Tanto las identidades de los pods de EKS como las de IRSA son las formas preferidas de entregar credenciales de AWS temporales a sus pods de EKS. A menos que tenga casos de uso específicos para IRSA, le recomendamos que utilice EKS Pod Identities cuando utilice EKS. Esta tabla ayuda a comparar las dos funciones.

Identidades y credenciales para los pods de EKS: recomendaciones

Actualice el daemonset de aws-node para usar IRSA

En la actualidad, el daemonset de aws-node está configurado para usar un rol asignado a las instancias y asignarlo a los pods. EC2 IPs Esta función incluye varias políticas gestionadas por AWS, por ejemplo, EC2 ContainerRegistryReadOnly Amazoneks_CNI_Policy, que permiten a todos los pods que se ejecutan en un nodo acceder a direcciones IP o extraer imágenes del ECR. attach/detach ENIs assign/unassign Dado que esto supone un riesgo para su clúster, se recomienda actualizar el daemonset de aws-node para que utilice IRSA. Encontrará un script para hacerlo en el repositorio de esta guía.

El daemonset de aws-node es compatible con las identidades de EKS Pod en las versiones 1.15.5 y posteriores.

Restrinja el acceso al perfil de instancia asignado al nodo trabajador

Al utilizar las identidades de pod de IRSA o EKS, se actualiza la cadena de credenciales del pod para utilizar primero las identidades de pod de IRSA o EKS. Sin embargo, el pod aún puede heredar los derechos del perfil de instancia asignado al nodo de trabajo. En el caso de los pods que no necesiten estos permisos, puedes bloquear el acceso a los metadatos de la instancia para garantizar que tus aplicaciones solo tengan los permisos que necesitan y no sus nodos.

Puedes bloquear el acceso a los metadatos de la instancia exigiendo que la instancia IMDSv2 solo los use y actualizando el recuento de saltos a 1, como se muestra en el siguiente ejemplo. También puedes incluir estos ajustes en la plantilla de lanzamiento del grupo de nodos. No inhabilites los metadatos de la instancia, ya que esto impedirá que componentes como el controlador de terminación de nodos y otros elementos que dependen de los metadatos de la instancia funcionen correctamente.

$ aws ec2 modify-instance-metadata-options --instance-id <value> --http-tokens required --http-put-response-hop-limit 1
...

Si utilizas Terraform para crear plantillas de lanzamiento para usarlas con grupos de nodos gestionados, añade el bloque de metadatos para configurar el recuento de saltos, tal y como se muestra en este fragmento de código:

tf hl_lines="7" resource "aws_launch_template" "foo" { name = "foo" …​ metadata_options { http_endpoint = "enabled" http_tokens = "required" http_put_response_hop_limit = 1 instance_metadata_tags = "enabled" } …​

También puedes bloquear el acceso de un pod a EC2 los metadatos manipulando las iptables del nodo. Para obtener más información sobre este método, consulta Limitar el acceso al servicio de metadatos de la instancia.

Si tiene una aplicación que utiliza una versión anterior del SDK de AWS que no es compatible con IRSA o EKS Pod Identities, debe actualizar la versión del SDK.

Limite la política de confianza de los roles de IAM para los roles de IRSA al nombre de la cuenta de servicio, al espacio de nombres y al clúster

La política de confianza se puede aplicar a un espacio de nombres o a una cuenta de servicio específica dentro de un espacio de nombres. Al usar IRSA, es mejor hacer que la política de confianza de roles sea lo más explícita posible e incluir el nombre de la cuenta de servicio. Esto evitará de forma efectiva que otros pods del mismo espacio de nombres asuman esa función. La CLI lo eksctl hará automáticamente cuando la utilice para crear accounts/IAM funciones de servicio. Consulte https://eksctl. io/usage/iamserviceaccounts/para obtener más información.

Cuando se trabaja directamente con IAM, se añade una condición a la política de confianza del rol que utiliza condiciones para garantizar que la :sub reclamación sea el espacio de nombres y la cuenta de servicio que esperabas. A modo de ejemplo, antes teníamos un token IRSA con la subafirmación «system:serviceaccount:default:s3-read-only». Este es el s3-read-only espacio de nombres y la cuenta de servicio. default Deberías usar una condición como la siguiente para asegurarte de que solo tu cuenta de servicio en un espacio de nombres determinado del clúster pueda asumir esa función:

  "Condition": {
      "StringEquals": {
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:aud": "sts.amazonaws.com",
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:sub": "system:serviceaccount:default:s3-read-only"
      }
  }

Utilice un rol de IAM por aplicación

Tanto con IRSA como con EKS Pod Identity, se recomienda asignar a cada aplicación su propia función de IAM. Esto mejora el aislamiento, ya que puede modificar una aplicación sin afectar a la otra, y le permite aplicar el principio de menor privilegio al conceder únicamente a una aplicación los permisos que necesita.

Al utilizar ABAC con EKS Pod Identity, puede utilizar una función de IAM común en varias cuentas de servicio y confiar en sus atributos de sesión para controlar el acceso. Esto resulta especialmente útil cuando se trabaja a gran escala, ya que ABAC le permite operar con menos funciones de IAM.

Cuando su aplicación necesite acceder al IMDS, utilice IMDSv2 y aumente el límite de saltos en EC2 las instancias a 2

IMDSv2requiere que utilices una solicitud PUT para obtener un token de sesión. La solicitud PUT inicial debe incluir un TTL para el token de sesión. Las versiones más recientes de AWS SDKs se encargarán de esto y de la renovación de dicho token automáticamente. También es importante tener en cuenta que el límite de saltos predeterminado en las EC2 instancias se establece intencionadamente en 1 para evitar el reenvío de IP. Como consecuencia, los pods que soliciten un token de sesión que se ejecuten en EC2 instancias pueden agotar el tiempo de espera y volver a utilizar el flujo de IMDSv1 datos. EKS añade compatibilidad IMDSv2 al habilitar tanto la versión 1 como la versión 2 y cambiar el límite de saltos a 2 en los nodos aprovisionados por eksctl o con las plantillas oficiales. CloudFormation

Desactivar el montaje automático de los tokens de las cuentas de servicio

Si tu aplicación no necesita llamar a la API de Kubernetes, establece el automountServiceAccountToken atributo false en el de tu aplicación o parchea la cuenta de servicio predeterminada en cada espacio de nombres PodSpec para que deje de montarse automáticamente en los pods. Por ejemplo:

kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'

Usa cuentas de servicio dedicadas para cada aplicación

Cada aplicación debe tener su propia cuenta de servicio dedicada. Esto se aplica a las cuentas de servicio de la API de Kubernetes, así como a las de IRSA y EKS Pod Identity.

Ejecute la aplicación como usuario no root

Los contenedores se ejecutan como root de forma predeterminada. Si bien esto les permite leer el archivo del token de identidad web, ejecutar un contenedor como root no se considera una práctica recomendada. Como alternativa, considere la posibilidad de añadir el spec.securityContext.runAsUser atributo a PodSpec. El valor de runAsUser es un valor arbitrario.

En el siguiente ejemplo, todos los procesos del pod se ejecutarán con el ID de usuario especificado en el runAsUser campo.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]

Cuando ejecutas un contenedor como usuario no root, se impide que el contenedor lea el token de la cuenta de servicio de IRSA, ya que al token se le asignan los permisos 0600 [root] de forma predeterminada. Si actualizas el SecurityContext de tu contenedor para que incluya fsgroup=65534 [Nobody], el contenedor podrá leer el token.

spec:
  securityContext:
    fsGroup: 65534

En Kubernetes 1.19 y versiones posteriores, este cambio ya no es necesario y las aplicaciones pueden leer el token de la cuenta de servicio de IRSA sin añadirlo al grupo Nobody.

Conceda el acceso menos privilegiado a las aplicaciones

Action Hero es una utilidad que puede ejecutar junto con su aplicación para identificar las llamadas a la API de AWS y los permisos de IAM correspondientes que su aplicación necesita para funcionar correctamente. Es similar a IAM Access Advisor en el sentido de que le ayuda a limitar gradualmente el alcance de las funciones de IAM asignadas a las aplicaciones. Consulte la documentación sobre la concesión del acceso menos privilegiado a los recursos de AWS para obtener más información.

Considere la posibilidad de establecer un límite de permisos para las funciones de IAM utilizadas con las identidades de IRSA y Pod. Puede usar el límite de permisos para garantizar que las funciones utilizadas por IRSA o Pod Identities no superen un nivel máximo de permisos. Para ver una guía de ejemplo sobre cómo empezar con los límites de los permisos con un ejemplo de política de límites de permisos, consulta este repositorio de GitHub.

Revisa y revoca el acceso anónimo innecesario a tu clúster de EKS

Lo ideal sería deshabilitar el acceso anónimo para todas las acciones de la API. El acceso anónimo se concede mediante la creación de RoleBinding o ClusterRoleBinding para el sistema de usuario integrado de Kubernetes: anonymous. Puedes usar la herramienta rbac-lookup para identificar los permisos que el usuario system:anonymous tiene en tu clúster:

./rbac-lookup | grep -P 'system:(anonymous)|(unauthenticated)'
system:anonymous               cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:public-info-viewer

Cualquier rol que no ClusterRole sea system: no public-info-viewer debe estar vinculado a system:anonymous user ni system:unauthenticated group.

Puede haber algunas razones legítimas para habilitar el acceso anónimo en un lugar específico. APIs Si este es el caso de su clúster, asegúrese de que solo un usuario anónimo pueda acceder a esos grupos específicos. Si APIs se exponen los datos APIs sin autenticación, el clúster no será vulnerable.

Antes de la Kubernetes/EKS versión 1.14, el grupo system:unauthenticated estaba asociado a system:discovery y system:basic-user de forma predeterminada. ClusterRoles Tenga en cuenta que, aunque haya actualizado el clúster a la versión 1.14 o superior, es posible que estos permisos sigan habilitados en el clúster, ya que las actualizaciones del clúster no revocan estos permisos. Para comprobar cuáles ClusterRoles tienen «system:unauthenticated» excepto system: public-info-viewer puedes ejecutar el siguiente comando (requiere jq util):

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | .metadata.name'

Además, puedes eliminar «system:unauthenticated» de todos los roles excepto de «system:» usando: public-info-viewer

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | del(.subjects[] | select(.name =="system:unauthenticated"))' | kubectl apply -f -

También puedes verificarlo y eliminarlo manualmente mediante kubectl describe y kubectl edit. Para comprobar si system:unauthenticated group tiene permisos system:discovery en tu clúster, ejecuta el siguiente comando:

kubectl describe clusterrolebindings system:discovery

Name:         system:discovery
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:discovery
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

Para comprobar si system:unauthenticated group tiene el permiso system:basic-user en tu clúster, ejecuta el siguiente comando:

kubectl describe clusterrolebindings system:basic-user

Name:         system:basic-user
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:basic-user
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

Si system:unauthenticated group está enlazado a system:discovery y/o system:basic-user en tu clúster, debes desasociar estas funciones de system:unauthenticated group. ClusterRoles Edita ClusterRoleBinding system:discovery con el siguiente comando:

kubectl edit clusterrolebindings system:discovery

El comando anterior abrirá la definición actual de system:discovery ClusterRoleBinding en un editor como se muestra a continuación:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2021-06-17T20:50:49Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "24502985"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery
  uid: b7936268-5043-431a-a0e1-171a423abeb6
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:discovery
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated

Elimine la entrada del grupo system:unauthenticated de la sección «asuntos» de la pantalla del editor anterior.

Repita los mismos pasos para system:basic-user. ClusterRoleBinding

Reutilice las sesiones del SDK de AWS con IRSA

Cuando utilizas IRSA, las aplicaciones escritas con el SDK de AWS utilizan el token que se entrega en tus pods para llamar sts:AssumeRoleWithWebIdentity a fin de generar credenciales de AWS temporales. Esto es diferente de otros servicios de cómputo de AWS, donde el servicio de cómputo entrega credenciales temporales de AWS directamente al recurso de cómputo de AWS, como una función lambda. Esto significa que cada vez que se inicializa una sesión de AWS SDK, se realiza una llamada a AWS AssumeRoleWithWebIdentity STS for. Si su aplicación escala rápidamente e inicializa muchas sesiones del SDK de AWS, es posible que se produzca una ralentización por parte de AWS STS, ya que su código tendrá que hacer muchas llamadas. AssumeRoleWithWebIdentity

Para evitar esta situación, le recomendamos reutilizar las sesiones del SDK de AWS en su aplicación para evitar realizar AssumeRoleWithWebIdentity llamadas innecesarias.

En el siguiente código de ejemplo, se crea una sesión con el SDK de python boto3 y esa misma sesión se utiliza para crear clientes e interactuar con Amazon S3 y Amazon SQS. AssumeRoleWithWebIdentitysolo se llama una vez y el SDK de AWS actualizará automáticamente las credenciales my_session cuando caduquen.

import boto3

= Create your own session

my_session = boto3.session.Session()

= Now we can create low-level clients from our session

sqs = my_session.client('`sqs`') s3 = my_session.client('`s3`')

s3response = s3.list_buckets() sqsresponse = sqs.list_queues()

#print the response from the S3 and SQS APIs print("`s3 response:`")
print(s3response) print("`—`") print("`sqs response:`")
print(sqsresponse) ```

Si va a migrar una aplicación de otro servicio informático de AWS, por ejemplo EC2, a EKS con IRSA, este detalle es especialmente importante. En otros servicios informáticos, la inicialización de una sesión del SDK de AWS no llama a AWS STS a menos que usted le indique que lo haga.

Enfoques alternativos

Si bien las identidades de los pods IRSA y EKS son las formas preferidas de asignar una identidad de AWS a un pod, requieren que incluya una versión reciente de AWS SDKs en su aplicación. Para obtener una lista completa de las SDKs que actualmente son compatibles con IRSA, consulte https://docs.aws.amazon.com/eks/latest/userguide/iam- roles-for-service-accounts -minimum-sdk.html; para las identidades de pods de EKS, consulte https://docs.aws.amazon.com/eks/latest/userguide/pod- id-minimum-sdk .html. Si tienes una aplicación que no puedes actualizar inmediatamente con un SDK compatible, hay varias soluciones creadas por la comunidad para asignar funciones de IAM a los pods de Kubernetes, como kube2iam y kiam. Si bien AWS no avala, aprueba ni apoya el uso de estas soluciones, la comunidad en general las utiliza con frecuencia para lograr resultados similares a los de las identidades de pod de IRSA y EKS.

Si necesita utilizar una de estas soluciones que no se proporcionan por ley, actúe con la diligencia debida y asegúrese de entender las implicaciones de seguridad que ello implica.

Herramientas y recursos