Autenticar em outra conta com IRSA - Amazon EKS

Autenticar em outra conta com IRSA

É possível configurar permissões entre contas do IAM criando um provedor de identidade do cluster de outra conta ou usando operações AssumeRole encadeadas. Nos exemplos a seguir, a Conta A tem um cluster do Amazon EKS que oferece suporte a perfis do IAM para contas de serviço. Os Pods que estão em execução nesse cluster devem assumir permissões do IAM da Conta B.

exemplo Criar um provedor de identidade de cluster de outra conta

Neste exemplo, a Conta A fornece à Conta B o URL do emissor de OpenID Connect (OIDC) do seu cluster. A conta B segue as instruções em Criar um provedor OIDC do IAM para o clusterCriar um provedor IAM OIDC para seu cluster e Atribuir perfis do IAM às contas de serviço do Kubernetes usando o URL do emissor OIDC do cluster da conta A. Em seguida, um administrador de cluster anota a conta de serviço no cluster da Conta A para usar o perfil da Conta B (444455556666).

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
exemplo Usar operações AssumeRole encadeadas

Neste exemplo, a Conta B cria uma política do IAM com as permissões a serem concedidas aos Pods no cluster da Conta A. A Conta B (444455556666) anexa essa política a um perfil do IAM com uma relação de confiança que concede permissões AssumeRole à Conta A (111122223333).

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

A conta A cria um perfil com uma política de confiança que obtém credenciais do provedor de identidade criado com o endereço do emissor de OIDC do cluster.

{
  "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"
    }
  ]
}

A Conta A anexa uma política a essa função com as seguintes permissões para assumir a função criada pela Conta B.

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

A aplicação cria o código para que os Pods assumam que a função da Conta B usa dois perfis: account_b_role e account_a_role. O perfil account_b_role usa o perfil account_a_role como origem. Para a CLI AWS, o arquivo ~/.aws/config é semelhante ao seguinte.

[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 perfis encadeados para outras SDKs da AWS, consulte a documentação do SDK em uso. Para obter mais informações, consulte Ferramentas para criar na AWS.