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. # Funciones de IAM para cuentas de servicio **sugerencia** `eksctl`[admite la configuración de permisos detallados para ejecutar aplicaciones de EKS mediante las asociaciones de identidad de EKS Pod](pod-identity-associations.md) Amazon EKS admite [aquí](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) [Roles for Service Accounts (IRSA)], que permite a los operadores de clústeres asignar las funciones de IAM de AWS a las cuentas de servicio de Kubernetes. Esto proporciona una administración de permisos detallada para las aplicaciones que se ejecutan en EKS y utilizan otros servicios de AWS. Pueden ser aplicaciones que usen S3, cualquier otro servicio de datos (RDS, MQ, STS, DynamoDB) o componentes de Kubernetes, como el controlador AWS Load Balancer o ExternalDNS. Puede crear fácilmente pares de roles y cuentas de servicio de IAM con. `eksctl` **nota** Si ha utilizado [roles de instancia](iam-policies.md) y está pensando en usar IRSA en su lugar, no debe mezclar ambos. ## Funcionamiento Funciona a través del proveedor de IAM OpenID Connect (OIDC) que EKS expone, y las funciones de IAM deben construirse con referencia al proveedor de OIDC de IAM (específico de un clúster de EKS determinado) y una referencia a la cuenta de servicio de Kubernetes a la que estará vinculado. Una vez que se crea un rol de IAM, la cuenta de servicio debe incluir el ARN de ese rol como anotación `eks.amazonaws.com/role-arn` (). De forma predeterminada, la cuenta de servicio se crea o actualiza para incluir la anotación del rol, que se puede deshabilitar con la marca. `--role-only` Dentro de EKS, hay un [controlador de admisión](https://github.com/aws/amazon-eks-pod-identity-webhook/) que inyecta las credenciales de sesión de AWS en los pods de las funciones, respectivamente, en función de la anotación de la cuenta de servicio utilizada por el pod. Las credenciales se expondrán en función de las variables `AWS_ROLE_ARN` de `AWS_WEB_IDENTITY_TOKEN_FILE` entorno. Si se utiliza una versión reciente del SDK de AWS (consulte [aquí](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) los detalles de la versión exacta), la aplicación utilizará estas credenciales. `eksctl`El nombre del recurso es *iamserviceaccount*, que representa un par de rol de IAM y cuenta de servicio. ## Uso desde CLI **nota** Las funciones de IAM para las cuentas de servicio requieren la versión 1.13 o superior de Kubernetes. El proveedor OIDC de IAM no está activado de forma predeterminada. Puede utilizar el siguiente comando para activarlo o utilizar el archivo de configuración (véase más abajo): ``` eksctl utils associate-iam-oidc-provider --cluster= ``` Una vez que tenga el proveedor OIDC de IAM asociado al clúster, para crear un rol de IAM vinculado a una cuenta de servicio, ejecute: ``` eksctl create iamserviceaccount --cluster= --name= --namespace= --attach-policy-arn= ``` **nota** Puede especificar `--attach-policy-arn` varias veces el uso de más de una política. Más específicamente, puede crear una cuenta de servicio con acceso de solo lectura a S3 ejecutando: ``` eksctl create iamserviceaccount --cluster= --name=s3-read-only --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess ``` De forma predeterminada, se creará en el espacio de `default` nombres, pero puede especificar cualquier otro espacio de nombres, por ejemplo: ``` eksctl create iamserviceaccount --cluster= --name=s3-read-only --namespace=s3-app --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess ``` **nota** Si el espacio de nombres aún no existe, se creará. Si ya tienes una cuenta de servicio creada en el clúster (sin un rol de IAM), tendrás que usar flag. `--override-existing-serviceaccounts` También se puede aplicar un etiquetado personalizado al rol de IAM especificando: `--tags` ``` eksctl create iamserviceaccount --cluster= --name= --tags "Owner=John Doe,Team=Some Team" ``` CloudFormation generará un nombre de rol que incluirá una cadena aleatoria. Si prefiere un nombre de rol predeterminado, puede especificar`--role-name`: ``` eksctl create iamserviceaccount --cluster= --name= --role-name "custom-role-name" ``` Cuando la cuenta de servicio la cree y administre otra herramienta, como Helm, úsela `--role-only` para evitar conflictos. La otra herramienta es entonces responsable de mantener la anotación ARN del rol. Tenga en `--override-existing-serviceaccounts` cuenta que esto no afecta a las cuentas `--role-only` de servicio`roleOnly`/, ya que el rol siempre se creará. ``` eksctl create iamserviceaccount --cluster= --name= --role-only --role-name= ``` Si ya tiene un rol que desea usar con una cuenta de servicio, puede proporcionar la `--attach-role-arn` marca en lugar de proporcionar las políticas. Para garantizar que el rol solo lo pueda asumir la cuenta de servicio especificada, debe establecer [aquí](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) [un documento de política de relaciones]. ``` eksctl create iamserviceaccount --cluster= --name= --attach-role-arn= ``` Para actualizar las funciones de una cuenta de servicio, puede ejecutar los permisos`eksctl update iamserviceaccount`. **nota** `eksctl delete iamserviceaccount`elimina Kubernetes `ServiceAccounts` aunque no los haya creado. `eksctl` ## Uso con archivos de configuración Para administrar `iamserviceaccounts` el uso del archivo de configuración, querrá configurar `iam.withOIDC: true` y enumerar la cuenta en la que desee`iam.serviceAccount`. *Todos los comandos son compatibles`--config-file`, por lo que puedes administrar las *cuentas de iamservicede* la misma manera que los grupos de nodos.* El `eksctl create iamserviceaccount` comando admite `--include` y `--exclude` marca (consulte [esta sección](general-nodegroups.md#node-include) para obtener más información sobre su funcionamiento). Además, el `eksctl delete iamserviceaccount` comando también es compatible`--only-missing`, por lo que puede realizar eliminaciones de la misma manera que con los grupos de nodos. **nota** Las cuentas de servicio de IAM se clasifican dentro de un espacio de nombres, es decir, pueden existir dos cuentas de servicio con el mismo nombre en espacios de nombres diferentes. Por lo tanto, para definir de forma exclusiva una cuenta de servicio como parte de los `--exclude` indicadores`--include`, tendrá que pasar la cadena del nombre en ese formato. `namespace/name` Por ejemplo: ``` eksctl create iamserviceaccount --config-file= --include backend-apps/s3-reader ``` La opción de habilitarla `wellKnownPolicies` se incluye para usar IRSA en casos de uso conocidos`cert-manager`, como las listas de políticas `cluster-autoscaler` y como forma abreviada de usarlas. Las políticas conocidas compatibles y otras propiedades de `serviceAccounts` se documentan en [el](https://geoffcline.github.io/eksctl-schema-demo/#iam-serviceAccounts) esquema de configuración. Se usa el siguiente ejemplo de configuración con`eksctl create cluster`: ``` # An example of ClusterConfig with IAMServiceAccounts: --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cluster-13 region: us-west-2 iam: withOIDC: true serviceAccounts: - metadata: name: s3-reader # if no namespace is set, "default" will be used; # the namespace will be created if it doesn't exist already namespace: backend-apps labels: {aws-usage: "application"} attachPolicyARNs: - "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" tags: Owner: "John Doe" Team: "Some Team" - metadata: name: cache-access namespace: backend-apps labels: {aws-usage: "application"} attachPolicyARNs: - "arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess" - "arn:aws:iam::aws:policy/AmazonElastiCacheFullAccess" - metadata: name: cluster-autoscaler namespace: kube-system labels: {aws-usage: "cluster-ops"} wellKnownPolicies: autoScaler: true roleName: eksctl-cluster-autoscaler-role roleOnly: true - metadata: name: some-app namespace: default attachRoleARN: arn:aws:iam::123:role/already-created-role-for-app nodeGroups: - name: "ng-1" tags: # EC2 tags required for cluster-autoscaler auto-discovery k8s.io/cluster-autoscaler/enabled: "true" k8s.io/cluster-autoscaler/cluster-13: "owned" desiredCapacity: 1 ``` Si creas un clúster sin estos campos configurados, puedes usar los siguientes comandos para habilitar todo lo que necesites: ``` eksctl utils associate-iam-oidc-provider --config-file= eksctl create iamserviceaccount --config-file= ``` ## Más información + [Presentamos funciones de IAM detalladas para las cuentas de servicio](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) + [Guía del usuario de EKS: Funciones de IAM para cuentas de servicio](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) + [Asignación de usuarios y roles de IAM a roles RBAC de Kubernetes](iam-identity-mappings.md)