Autenticación en otra cuenta mediante IRSA - Amazon EKS

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.

ejemplo 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ústerCrear 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 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
ejemplo Uso de operaciones AssumeRole encadenadas

En este ejemplo, la cuenta B crea una política de IAM con los permisos que debe otorgar a los Pods del clúster de la cuenta A. La cuenta B (444455556666) adjunta dicha política a un rol de IAM con una relación de confianza que concede permisos de AssumeRole a la cuenta A (111122223333).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

La cuenta A 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.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity"
    }
  ]
}

La cuenta A asocia una política a ese rol con los siguientes permisos para asumir el rol que ha creado la cuenta B.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::444455556666:role/account-b-role"
        }
    ]
}

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.