Autenticar em outra conta com IRSA - Amazon EKS
Opção 1: Criar um provedor de identidade a partir do cluster de outra contaOpção 2: Usar operações AssumeRole encadeadas

Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

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 compatível com perfis do IAM para contas de serviço. Os pods em execução nesse cluster devem assumir as permissões do IAM da Conta B.

  • A Opção 1 é mais simples, mas exige que a Conta B crie e gerencie um provedor de identidade OIDC para o cluster da Conta A.

  • A Opção 2 mantém o gerenciamento do OIDC na Conta A, mas exige o encadeamento de funções por meio de duas chamadas AssumeRole.

Opção 1: Criar um provedor de identidade a partir do cluster de outra conta

Neste exemplo, a Conta A fornece à Conta B o URL do emissor de OpenID Connect (OIDC) de seu cluster. A conta B segue as instruções em Criar um provedor OIDC do IAM para o cluster e Atribuir perfis do IAM às contas de serviço do Kubernetes usando o URL do emissor do 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

Opção 2: Usar operações AssumeRole encadeadas

Nessa abordagem, cada conta cria um perfil do IAM. O perfil da Conta B confia no perfil da Conta A, e o perfil da Conta A utiliza a federação OIDC para obter credenciais do cluster. Em seguida, o Pod encadeia as duas funções usando perfis da AWS CLI.

Passo 1: Crie o perfil de destino na Conta B

A Conta B (444455556666) cria um perfil do IAM com as permissões necessárias para os pods no cluster da Conta A. A conta B atribui a política de permissões desejada a esse perfil e, em seguida, adiciona a seguinte política de confiança.

Política de confiança para o perfil da Conta B: essa política permite que o perfil IRSA específico da Conta A assuma esse perfil.

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

Para aplicar o princípio do privilégio mínimo, faça a troca do ARN Principal pelo ARN do perfil específico da Conta A, em vez de usar a conta raiz (arn:aws:iam::111122223333:root). O uso da conta root permite que qualquer entidade principal do IAM na Conta A assuma esse perfil.

Passo 2: Criar o perfil IRSA na Conta A

A conta A (111122223333) 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.

Política de confiança para o perfil da Conta A (federação OIDC): essa política permite que o provedor OIDC do cluster do EKS emita credenciais para este perfil.

{
  "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 aplicar o princípio do privilégio mínimo, adicione uma condição StringEquals à reivindicação sub para restringir esse perfil a uma conta de serviço específica do Kubernetes. Sem nenhuma condição sub, qualquer conta de serviço no cluster pode assumir esse perfil. O valor sub segue o formato system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME . Por exemplo, para restringir a uma conta de serviço cujo nome my-service-account consta no namespace default:

"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"

Etapa 3: atribuir a permissão AssumeRole ao perfil da Conta A

A conta A atribui uma política de permissões ao perfil criado na Etapa 2. Essa política permite que o perfil assuma o perfil da Conta B.

Política de permissões para o perfil da Conta A: essa política concede sts:AssumeRole sobre o perfil alvo da Conta B.

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

Etapa 4: Configurar o Pod para encadeamento de perfis

A aplicação cria o código para que os pods assumam que o perfil 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.