**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](enable-iam-roles-for-service-accounts.md) e [Atribuir perfis do IAM às contas de serviço do Kubernetes](associate-service-account-role.md) 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](https://aws.amazon.com/developer/tools/).