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.

Gestión de identidad y acceso

La gestión de identidades y accesos (IAM) es un servicio de AWS que desempeña dos funciones esenciales: la autenticación y la autorización. La autenticación implica la verificación de una identidad, mientras que la autorización rige las acciones que pueden realizar los recursos de AWS. En AWS, un recurso puede ser otro servicio de AWS, por ejemplo, EC2, o un principal de AWS, como un usuario o un rol de IAM. https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_iam-roles Las reglas que rigen las acciones que un recurso puede realizar se expresan en forma de 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 en el servicio kube-apiserver, por ejemplo, los tokens de portador, los certificados, el OIDC, etc. X.509 Actualmente, EKS admite de forma nativa la autenticación mediante tokens de webhook, los tokens de cuentas de servicio y, a partir del 21 de febrero de 2021, la autenticación OIDC.

La estrategia de autenticación de webhooks se denomina webhook a un webhook que verifica los tokens del portador. En EKS, la CLI de AWS o el cliente https://github.com/kubernetes-sigs/aws-iam-authenticator aws-iam-authenticator generan estos tokens portadores cuando se ejecutan los comandos. kubectl 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> --region <region>

La salida debería parecerse a la siguiente:

{
    "kind": "ExecCredential",
    "apiVersion": "client.authentication.k8s.io/v1alpha1",
    "spec": {},
    "status": {
        "expirationTimestamp": "2024-12-20T17:38:48Z",
        "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMudXMtd2VzdC0yLmFtYXpvbmF3cy5jb20vP0FjdGlvbj1HZ...."
    }
}

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 parecerse a esto:

{
  "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 similar 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, consulte 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 usas 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 en el espacio de kube-system nombres para determinar el grupo de RBAC que se va a aws-auth ConfigMap asociar al usuario. aws-auth ConfigMap Se utiliza para crear un mapeo estático entre los grupos 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 los roles 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.

CloudWatch consulta para ayudar a los usuarios a identificar a los clientes que envían solicitudes al punto final global de STS

Ejecute la CloudWatch consulta a continuación para obtener el punto final de STS. Si stsendpoint es igual a «sts.amazonaws.com», se trata de un punto final STS global. Si stsendpoint es igual a «sts». <region>.amazonaws.com», entonces es un punto final STS regional.

fields @timestamp, @message, @logStream, @log,stsendpoint
| filter @logStream like /authenticator/
| filter @message like /stsendpoint/
| sort @timestamp desc
| limit 10000

Gestor de acceso al clúster

El administrador de acceso a clústeres, que ahora es la forma preferida de administrar el acceso de los directores 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 los RBAC de Kubernetes, lo que elimina la necesidad de cambiar entre las API de AWS y Kubernetes o de editarlas aws-auth ConfigMap para la administración del acceso, lo que reduce la sobrecarga operativa y ayuda a solucionar los errores de configuración. La herramienta también permite a los administradores de clústeres revocar o refinar automáticamente los cluster-admin permisos concedidos al principal 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 Amazon EKS las define y administra.

El gestor de acceso al clúster permite combinar el RBAC en fase inicial con políticas de acceso que permiten permitir y transferir (pero no denegar) las decisiones de Kubernetes sobre AuthZ relacionadas con las solicitudes de los servidores de API. Se tomará una decisión de denegación cuando tanto los autorizadores de Amazon EKS como los del RBAC anterior 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 clústeres de Amazon EKS, establecer el API método de autenticación preferido y definir las entradas de acceso para conceder acceso a los principales de IAM de AWS 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 sin los permisos de administrador del creador del clúster.

Es posible actualizar la configuración de los clústeres de Amazon EKS para habilitar el API modo de autenticación mediante el update-cluster-config comando. Para hacerlo en los clústeres existentes, primero tendrá que actualizar a API_AND_CONFIG_MAP y, a continuación, a. CONFIG_MAP API Estas operaciones no se pueden revertir, lo que significa que no es posible cambiar de API a API_AND_CONFIG_MAP o CONFIG_MAP y también 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 agregar 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 los RBAC de 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 (en desuso)

Una forma de integrar Kubernetes con la autenticación de AWS es mediante el aws-auth ConfigMap, que reside en el espacio de nombres. kube-system Es responsable de asignar la autenticación de las identidades (usuarios, grupos y roles) de AWS IAM 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 utilizarla ConfigMap para añadir el acceso de los RBAC a los principales de IAM.

Para comprobar el estado de tu clúster aws-auth ConfigMap, puedes usar 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 este ConfigMap, se encuentra data en la parte inferior del mapRoles bloque, que está compuesto básicamente por 3 parámetros.

También es posible asignar permisos a los usuarios de AWS IAM, definiendo un nuevo bloque de configuración para mapUsers reemplazar el aws-auth ConfigMap parámetro rolearn por userarn. Sin embargo, como práctica recomendada, siempre se recomienda que el usuario lo sustituya. data mapRoles

Para administrar los permisos, puede editar la aws-auth ConfigMap adición o la eliminación del acceso a su clúster de Amazon EKS. Si bien es posible editarlos aws-auth ConfigMap manualmente, se recomienda utilizar herramientas como estaseksctl, ya que se trata de una configuración muy delicada y una configuración inexacta puede impedir que se quede fuera del clúster de Amazon EKS. 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.

Ventajas en comparación con la gestión del acceso ConfigMap-based

Recomendaciones de acceso al clúster

Combine IAM Identity Center con la API CAM

Haga que el EKS Cluster Endpoint sea privado

De forma predeterminada, al aprovisionar un clúster de EKS, el punto final del clúster de API se establece como público, es decir, se puede acceder a él desde Internet. A pesar de que se puede acceder a él desde Internet, el punto final se sigue considerando seguro porque requiere que IAM autentique todas las solicitudes de API y, a continuación, el RBAC de Kubernetes las autorice. Dicho esto, si la política de seguridad de su empresa exige restringir el acceso a la API desde Internet o le impide redirigir el tráfico fuera de la VPC del clúster, puede:

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

El token de una 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 CI/CD aplicación en canalización. Si estas aplicaciones se ejecutan en la infraestructura de AWS, como las instancias EC2, considera la posibilidad de usar un perfil de instancia y asignarlo a un rol de RBAC de Kubernetes.

Utilice el acceso menos privilegiado a los recursos de AWS

No es necesario que a un usuario de IAM se le asignen privilegios sobre 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 principal creador del clúster. Con la API Cluster Access Manager, es posible crear clústeres sin este permiso, configurándolo enfalse, cuando se utiliza API_AND_CONFIG_MAP el --access-config bootstrapClusterCreatorAdminPermissions modo de API autenticación. La revocación de este acceso se considera una práctica recomendada para evitar cualquier cambio no deseado 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 ofrece la flexibilidad de desvincular únicamente un principal 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 sea inaccesible de otro modo.

Si el clúster sigue configurado con el método de CONFIG_MAP autenticación, todos los usuarios adicionales deben tener acceso al clúster a través del rol asignado a la entidad que creó el clúster y aws-auth ConfigMap, una vez aws-auth ConfigMap configurado, 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 por otros motivos. 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 de RBAC de Kubernetes. Será más fácil de mantener, especialmente a medida que aumente la cantidad de usuarios que requieren acceso.

Si sigues utilizando el aws-auth ConfigMap como método de autenticación, al asignar los permisos de RBAC de K8 a un rol de IAM, debes incluir\ {{}} en tu nombre de usuario. SessionName De este modo, el registro de auditoría registrará el nombre de la sesión para que pueda rastrear 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 con los privilegios mínimos al crear y RoleBindings ClusterRoleBindings

Como en el punto anterior sobre la concesión del acceso a los recursos de AWS, RoleBindings 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 los roles 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 delegar cluster-admin los permisos al creador del clúster, se conceden automáticamente los system:masters permisos en la configuración de RBAC del clúster al usuario o rol de la entidad de IAM (por ejemplo, al usuario federado que crea el clúster). Aun siendo una práctica recomendada eliminar este permiso, como se describe aquí, si se utiliza el método de CONFIG_MAP autenticación, confiando en aws-auth ConfigMap que 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 la infraestructura vinculada a una función de IAM dedicada, sin que otros usuarios o entidades asuman los permisos, y auditar periódicamente los permisos, las políticas y quién tiene acceso a esta función para activar la canalización. Además, este rol no debe usarse para realizar acciones rutinarias en el clúster y 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 el usuario federado que crea el clúster, se le conceden automáticamente system:masters los permisos en la configuración de RBAC del clúster. Este acceso no se puede eliminar y no se administra a través del. 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 usarse para realizar acciones rutinarias en el clúster y, en su lugar, se debe conceder acceso al clúster a otros usuarios a través de la función con este aws-auth ConfigMap fin. Una vez aws-auth ConfigMap configurado, el rol debe protegerse y usarse solo en el modo temporal de privilegios elevados o romper el cristal en situaciones en las que el clúster sea inaccesible de otro modo. Esto puede resultar especialmente ú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 la persona que necesite acceder cambie con el tiempo. Planifica auditarlos periódicamente para ver aws-auth ConfigMap 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 como kubectl-who-can o rbac-lookup para examinar las funciones vinculadas a una cuenta de servicio, usuario o grupo en particular. Exploraremos este tema más a fondo cuando lleguemos a la sección sobre auditoría. Auditoría y registro Puede encontrar ideas adicionales en este artículo de NCC Group.

Si confía en aws-auth, ConfigMap, utilice las herramientas para realizar cambios

Un aws-auth con un formato incorrecto puede hacer que pierda el acceso al clúster. ConfigMap Si necesita realizar cambios en el, utilice una herramienta. ConfigMap

eksctl La eksctl CLI incluye un comando para agregar mapeos de identidad al aws-auth. ConfigMap

Ver la ayuda de la 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 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

https://github.com/keikoproj/aws-authaws-auth de keikoproj

aws-authde keikoproj incluye tanto una biblioteca cli como una biblioteca go.

Descargar y ver la ayuda (ayuda de la CLI):

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

También puedes instalarlo 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 en GitHub para obtener más información, incluida la biblioteca go.

CLI de AWS IAM Authenticator

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

Descargue una versión en GitHub.

Agregue 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 autenticación y la administración del acceso

Si bien 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, como un proxy de autenticación y la suplantación de GitHub Kubernetes. https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation 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 utilizarla, la versión 2.0 de la CLI de AWS incluye la opción de crear un perfil con nombre que facilita la asociación de una sesión de SSO a su sesión de CLI actual y la asunción de una función de IAM. Tenga en cuenta que debe asumir un rol antes de correr, kubectl ya que el rol de IAM se usa para determinar el grupo RBAC de Kubernetes del usuario.

Identidades y credenciales para los pods de EKS

Algunas aplicaciones que se ejecutan en un clúster de Kubernetes necesitan permiso para llamar a la API de Kubernetes y funcionar correctamente. Por ejemplo, el controlador de equilibrio de carga de AWS debe poder enumerar los puntos de enlace de un servicio. El controlador también debe poder invocar las API de AWS para aprovisionar y configurar una ALB. En esta sección, analizaremos las mejores prácticas 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 de RBAC de Kubernetes a un pod. Se crea automáticamente una cuenta de servicio predeterminada para cada espacio de nombres de un clúster. Cuando implementas 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 el que. /var/run/secrets/kubernetes.io/serviceaccount Al decodificar el token de la cuenta de servicio de 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 al ser de acceso público.

Cuando una aplicación que se ejecuta en un pod llama a las API de Kubernetes, se debe asignar al pod una cuenta de servicio que le conceda permiso explícito para llamar a esas API. Al igual que las directrices para el acceso de los usuarios, el rol o la cuenta ClusterRole vinculada a un servicio deben 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 configura el spec.serviceAccountName campo de un pod con el nombre de la cuenta de servicio que deseas usar. Para obtener más información sobre la creación de cuentas de servicio, consulta https://kubernetes.io/docs/reference/access-authn-authz/rbac/ #service -account-permissions.

Roles de IAM para cuentas de servicio (IRSA)

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 Service Account Token Volume Projection. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection Cuando los pods se configuran con una cuenta de servicio que hace referencia a una función de IAM, el servidor de API de Kubernetes llamará al punto final de detección público del OIDC del 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 que el pod llame al rol de IAM asociado a las API de AWS. Cuando se invoca una API de AWS, los SDK de AWS llaman. sts:AssumeRoleWithWebIdentity Tras validar la firma del token, IAM intercambia 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 del Pod a S3 al asumir una función de IAM. Cuando la aplicación intenta leer desde S3, el token se intercambia 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 de forma manual.

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. Los SDK de AWS son responsables 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-roles-for-service-accounts-technical-overview.html.

Pod Identities de EKS

EKS Pod Identities es una función lanzada en re:Invent 2023 que 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 usar EKS Pod Identity, debe implementar un agente que se ejecute como un pod en cada nodo de trabajo que cumpla los requisitos. DaemonSet Este agente está disponible como EKS Add-on y es un requisito previo para utilizar la función EKS Pod Identity. Sus aplicaciones deben usar una versión compatible del AWS SDK para usar esta función.

Cuando las identidades de un pod de EKS estén configuradas para un pod, EKS montará y actualizará el token de identidad del 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 AssumeRoleForPodIdentity API. 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, 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 EKS Pod, consulta este blog.

No tiene que realizar ninguna modificación en el código de la aplicación para usar EKS Pod Identities. Las versiones compatibles del SDK de AWS descubrirán automáticamente las credenciales disponibles en 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 estado, por ejemplo, aws:SourceOrgId para ayudar a protegerse contra el confuso problema de los diputados entre servicios. En el ejemplo anterior de política de confianza de roles, ResourceOrgId se trata de una variable igual al identificador de organización de AWS de la organización de AWS a la que pertenece la cuenta de AWS. EKS transferirá un valor aws:SourceOrgId igual al de cuando asuma un rol en EKS Pod Identities.

Identidades de ABAC y EKS Pod

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 global, como aws:PrincipalTag/<tag-key> aws:PrincipalTag/eks-cluster-arn

Por ejemplo, si desea conceder acceso únicamente 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á que comprobar eks-cluster-arn y kubernetes-namespace etiquetar, así como asegurarse de que solo las kubernetes-service-account cuentas de servicio del clúster en cuestión tengan acceso a ese recurso, ya que otros clústeres podrían tener acceso a ese recursokubernetes-service-accounts. kubernetes-namespaces

Este ejemplo de política de bucket de S3 solo otorga acceso a los objetos del bucket de S3 al que está adjunto, solo si kubernetes-service-account eks-cluster-arn todos cumplen con 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 temporales de AWS 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.

Recomendaciones sobre identidades y credenciales para los pods de EKS

Actualice el daemonset de aws-node para usar IRSA

En la actualidad, el daemonset de aws-node está configurado para usar una función asignada a las instancias EC2 para asignar IP a los pods. Esta función incluye varias políticas administradas por AWS, como Amazoneks_CNI_Policy, que permiten de manera efectiva EC2ContainerRegistryReadOnly que todos los pods que se ejecuten en un nodo utilicen ENI, direcciones IP o extraigan imágenes del ECR. attach/detach assign/unassign Dado que esto representa un riesgo para el clúster, se recomienda actualizar el daemonset de aws-node para usar IRSA. Puede encontrar un script para hacerlo en el repositorio de esta guía. https://github.com/aws/aws-eks-best-practices/tree/master/projects/enable-irsa/src

El daemonset de aws-node es compatible con EKS Pod Identities en las versiones v1.15.5 y posteriores.

Restrinja el acceso al perfil de instancia asignado al nodo de trabajo

Cuando usas identidades de pod de IRSA o EKS, se actualiza la cadena de credenciales del pod para usar 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 necesitan 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 a la instancia que utilice únicamente IMDSv2 y actualizando el recuento de saltos a 1, como en el ejemplo siguiente. 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 los metadatos de EC2 manipulando las iptables del nodo. Para obtener más información sobre este método, consulte Limitar el acceso al servicio de metadatos de la instancia.

Si tiene una aplicación que usa una versión anterior del SDK de AWS que no admite identidades de pod de IRSA o EKS, debe actualizar la versión del SDK.

Limite la política de confianza de roles de IAM para los roles de IRSA al nombre de la cuenta de servicio, el espacio de nombres y el 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 los roles sea lo más explícita posible e incluir el nombre de la cuenta de servicio. De esta forma, evitarás que otros pods del mismo espacio de nombres asuman el rol. La CLI lo eksctl hará automáticamente cuando la utilices para crear accounts/IAM roles de servicio. Para obtener información adicional, consulte https://eksctl.io/usage/iamserviceaccounts/.

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 se corresponde con el espacio de nombres y la cuenta de servicio esperados. Por ejemplo, antes teníamos un token de IRSA con una subafirmación de «system:serviceaccount:default:s3-read-only». Este es el espacio s3-read-only de nombres y la cuenta de servicio es. default Deberías usar una condición como la siguiente para asegurarte de que solo tu cuenta de servicio de un espacio de nombres determinado de tu 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"
      }
  }

Usa 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 otra, y le permite aplicar el principio de mínimo privilegio concediendo a una aplicación únicamente los permisos que necesita.

Al usar ABAC con EKS Pod Identity, puedes usar 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 es especialmente útil cuando se opera a gran escala, ya que ABAC 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 las instancias EC2 a 2

IMDSv2 requiere 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 los SDK de AWS gestionarán esto y la renovación de dicho token de forma automática. También es importante tener en cuenta que el límite de saltos predeterminado en las instancias EC2 se establece intencionadamente en 1 para evitar el reenvío de IP. Como consecuencia, es posible que los pods que soliciten un token de sesión y se ejecuten en instancias EC2 acaben agotando el tiempo de espera y recurriendo al flujo de datos del IMDSv1. EKS añade compatibilidad con IMDSv2 al habilitar tanto la versión 1 como la 2 y cambiar el límite de saltos a 2 en los nodos aprovisionados por eksctl o con las plantillas oficiales. CloudFormation

Inhabilita 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 PodSpec para tu aplicación o aplica un parche a la cuenta de servicio predeterminada en cada espacio de nombres para que ya no se monte 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 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 usuario root no se considera una práctica recomendada. Como alternativa, considere agregar el spec.securityContext.runAsUser atributo al PodSpec. El valor de runAsUser es un valor arbitrario.

En el siguiente ejemplo, todos los procesos del pod se ejecutarán con el identificador 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 que no es root, se evita que el contenedor lea el token de la cuenta de servicio IRSA, ya que al token se le asignan 0600 permisos [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ñadirlas al grupo Nadie.

Otorgue 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 con privilegios mínimos 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. Puedes usar el límite de permisos para asegurarte de que las funciones utilizadas por IRSA o Pod Identities no puedan superar un nivel máximo de permisos. Para ver una guía de ejemplo sobre cómo empezar a usar los límites de permisos y 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 es que el acceso anónimo esté deshabilitado para todas las acciones de la API. El acceso anónimo se otorga creando un 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 de 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:public-info-viewer no debe estar vinculado a system:anonymous user o system:unauthenticated group.

Puede haber algunas razones legítimas para habilitar el acceso anónimo en API específicas. Si este es el caso de su clúster, asegúrese de que el usuario anónimo solo pueda acceder a esas API específicas y exponer esas API sin autenticación no hace que su clúster sea 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 Ten en cuenta que, aunque hayas actualizado tu clúster a la versión 1.14 o superior, es posible que estos permisos sigan habilitados en tu clúster, ya que las actualizaciones del clúster no los revocan. 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'

Y «system:unauthenticated» se puede eliminar de todas las funciones excepto de «system:public-info-viewer» usando:

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 comprobarlo y eliminarlo manualmente mediante kubectl describe y kubectl edit. Para comprobar si system:unauthenticated group tiene permisos de 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 el grupo system:unauthenticated 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 el grupo system:unauthenticated está vinculado a system:discovery system:basic-user en tu clúster, debes desvincular estas funciones del grupo and/or system:unauthenticated. ClusterRoles ClusterRoleBinding Edita 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 correspondiente al grupo system:unauthenticated de la sección «temas» de la pantalla del editor anterior.

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

Reutilice las sesiones del AWS SDK con IRSA

Cuando usa IRSA, las aplicaciones escritas con el SDK de AWS utilizan el token que se entrega en los pods sts:AssumeRoleWithWebIdentity para generar credenciales de AWS temporales. Esto difiere de otros servicios informáticos de AWS, en los que el servicio informático entrega credenciales temporales de AWS directamente al recurso informático 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 STS forAssumeRoleWithWebIdentity. Si su aplicación se amplía rápidamente e inicializa muchas sesiones del SDK de AWS, es posible que AWS STS lo limite, ya que su código generará muchas llamadas. AssumeRoleWithWebIdentity

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

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

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, como EC2, a EKS con IRSA, este detalle es especialmente importante. En otros servicios informáticos, al inicializar una sesión del SDK de AWS no se llama a AWS STS a menos que se lo indique usted.

Enfoques alternativos

Si bien las identidades de los pods de IRSA y EKS son las formas preferidas de asignar una identidad de AWS a un pod, es necesario que incluya la versión reciente de los SDK de AWS en la aplicación. Para obtener una lista completa de los SDK que actualmente son compatibles con IRSA, consultehttps://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html, para EKS Pod Identities, consulte https://docs.aws.amazon.com/eks/latest/userguide/pod-id-minimum-sdk.html. Si tiene una aplicación que no puede actualizar inmediatamente con un SDK compatible, hay varias soluciones creadas por la comunidad disponibles para asignar funciones de IAM a los pods de Kubernetes, incluidas kube2iam y kiam. Si bien AWS no respalda, 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 son de AWS, actúe con la debida diligencia y asegúrese de que comprende las implicaciones de seguridad que ello implica.

Herramientas y recursos