Ayude a mejorar esta página
Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.
Autenticación en otra cuenta mediante IRSA
Puede configurar permisos de IAM entre cuentas mediante la creación de un proveedor de identidades a partir del clúster de otra cuenta o mediante operaciones AssumeRole encadenadas. En los siguientes ejemplos, la cuenta A posee un clúster de Amazon EKS que admite roles de IAM para las cuentas de servicio. Los pods que se ejecutan en ese clúster deben asumir permisos de IAM de la cuenta B.
-
La opción 1 es más sencilla, pero requiere que la cuenta B cree y administre un proveedor de identidad OIDC para el clúster de la cuenta A.
-
La opción 2 mantiene la administración del OIDC en la cuenta A, pero requiere el encadenamiento de funciones a través de dos llamadas
AssumeRole.
Opción 1: creación de un proveedor de identidades a partir del clúster de otra cuenta
En este ejemplo, la Cuenta A proporciona a la Cuenta B la URL del emisor de OpenID Connect (OIDC) desde su clúster. La cuenta B sigue las instrucciones que se encuentran en Creación de un proveedor de OIDC de IAM para su clúster y Asignación de roles de IAM a cuentas de servicio de Kubernetes mediante la URL del emisor de OIDC del clúster de la cuenta A. A continuación, un administrador del clúster anota la cuenta de servicio en el clúster de la cuenta A para utilizar el rol de la cuenta B (444455556666).
apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
Opción 2: uso de operaciones AssumeRole encadenadas
En este enfoque, cada cuenta crea un rol de IAM. El rol de la cuenta B confía en la cuenta A y el rol de la cuenta A usa la federación OIDC para obtener las credenciales del clúster. A continuación, el pod encadena los dos roles mediante perfiles de AWS CLI.
Paso 1: crear un rol objetivo en la cuenta B
La cuenta B (444455556666) crea un rol de IAM con los permisos que necesitan los pods del clúster de la cuenta A. La cuenta B adjunta la política de permisos deseada a este rol y, a continuación, agrega la siguiente política de confianza.
Política de confianza para el rol de la cuenta B: esta política permite que el rol IRSA específico de la cuenta A asuma este rol.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
importante
Para obtener los privilegios mínimos, sustituya el ARN de Principal por el ARN del rol específico de la cuenta A en lugar de usar la raíz de la cuenta (arn:aws:iam::111122223333:root). El uso de la raíz de la cuenta permite que cualquier entidad principal de IAM de la cuenta A asuma este rol.
Paso 2: crear un rol de IRSA en la cuenta A
La cuenta A (111122223333) crea un rol con una política de confianza que obtiene las credenciales del proveedor de identidades creado con la dirección del emisor OIDC del clúster.
Política de confianza para el rol de la cuenta A (federación de OIDC): esta política permite al proveedor de OIDC del clúster de EKS emitir credenciales para este rol.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com" } } } ] }
importante
Para obtener el privilegio mínimo, agregue una condición StringEquals a la notificación de sub para restringir este rol a una cuenta de servicio de Kubernetes específica. Sin ninguna condición sub, cualquier cuenta de servicio del clúster puede asumir este rol. El valor sub usa el formato system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME
. Por ejemplo, para restringirlo a una cuenta de servicio denominada my-service-account en el espacio de nombres default:
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
Paso 3: adjuntar el permiso de AssumeRole al rol de la cuenta A.
La cuenta A adjunta una política de permisos al rol creado en el paso 2. Esta política permite que el rol asuma el rol de la cuenta B.
Política de permisos para el rol de la cuenta A: esta política otorga sts:AssumeRole en el rol objetivo de la cuenta B.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::444455556666:role/account-b-role" } ] }
Paso 4: configurar el pod para encadenar roles
El código de aplicación para que los pods asuman el rol de la cuenta B utiliza dos perfiles: account_b_role y account_a_role. El perfil account_b_role utiliza el perfil account_a_role como origen. Para la CLI de AWS, el archivo ~/.aws/config es similar al siguiente.
[profile account_b_role] source_profile = account_a_role role_arn=arn:aws:iam::444455556666:role/account-b-role [profile account_a_role] web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token role_arn=arn:aws:iam::111122223333:role/account-a-role
Para especificar perfiles encadenados para otros SDK de AWS, consulte la documentación del SDK que utiliza. Para obtener más información, consulte herramientas para crear en AWS
