

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Funções do IAM para contas de serviço
<a name="iamserviceaccounts"></a>

**dica**  
 `eksctl`[suporta a configuração de permissões refinadas para aplicativos em execução do EKS por meio do EKS Pod Identity Associations](pod-identity-associations.md) 

O Amazon EKS oferece suporte [aqui](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) para Roles for Service Accounts (IRSA)], que permitem que operadores de cluster mapeiem funções do AWS IAM para contas de serviço do Kubernetes.

Isso fornece gerenciamento de permissões refinado para aplicativos que são executados no EKS e usam outros serviços da AWS. Podem ser aplicativos que usam o S3, qualquer outro serviço de dados (RDS, MQ, STS, DynamoDB) ou componentes do Kubernetes, como o controlador AWS Load Balancer ou o ExternalDNS.

Você pode criar facilmente pares de funções e contas de serviço do IAM com`eksctl`.

**nota**  
Se você usou [funções de instância](iam-policies.md) e está pensando em usar o IRSA em vez disso, não deve misturar as duas.

## Como funciona
<a name="iam-how-works"></a>

Ele funciona por meio do IAM OpenID Connect Provider (OIDC) que o EKS expõe, e as funções do IAM devem ser construídas com referência ao provedor IAM OIDC (específico para um determinado cluster EKS) e uma referência à conta de serviço do Kubernetes à qual ele será vinculado. Depois que uma função do IAM é criada, uma conta de serviço deve incluir o ARN dessa função como uma anotação (). `eks.amazonaws.com/role-arn` Por padrão, a conta de serviço será criada ou atualizada para incluir a anotação da função. Isso pode ser desativado usando o sinalizador. `--role-only`

Dentro do EKS, há um [controlador de admissão](https://github.com/aws/amazon-eks-pod-identity-webhook/) que injeta credenciais de sessão da AWS em pods, respectivamente, das funções com base na anotação na conta de serviço usada pelo pod. As credenciais serão expostas por `AWS_ROLE_ARN` & variáveis de `AWS_WEB_IDENTITY_TOKEN_FILE` ambiente. Como uma versão recente do AWS SDK é usada (veja [aqui](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) os detalhes da versão exata), o aplicativo usará essas credenciais.

No nome `eksctl` do recurso está *iamserviceaccount*, que representa um par de funções e contas de serviço do IAM.

## Uso da CLI
<a name="_usage_from_cli"></a>

**nota**  
As funções do IAM para contas de serviço exigem a versão 1.13 ou superior do Kubernetes.

O provedor IAM OIDC não está habilitado por padrão. Você pode usar o comando a seguir para ativá-lo ou usar o arquivo de configuração (veja abaixo):

```
eksctl utils associate-iam-oidc-provider --cluster=<clusterName>
```

Depois de ter o provedor IAM OIDC associado ao cluster, para criar uma função do IAM vinculada a uma conta de serviço, execute:

```
eksctl create iamserviceaccount --cluster=<clusterName> --name=<serviceAccountName> --namespace=<serviceAccountNamespace> --attach-policy-arn=<policyARN>
```

**nota**  
Você pode especificar `--attach-policy-arn` várias vezes para usar mais de uma política.

Mais especificamente, você pode criar uma conta de serviço com acesso somente de leitura ao S3 executando:

```
eksctl create iamserviceaccount --cluster=<clusterName> --name=s3-read-only --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
```

Por padrão, ele será criado no `default` namespace, mas você pode especificar qualquer outro namespace, por exemplo:

```
eksctl create iamserviceaccount --cluster=<clusterName> --name=s3-read-only --namespace=s3-app --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
```

**nota**  
Se o namespace ainda não existir, ele será criado.

Se você já tiver uma conta de serviço criada no cluster (sem uma função do IAM), precisará usar a `--override-existing-serviceaccounts` sinalização.

A marcação personalizada também pode ser aplicada à função do IAM `--tags` especificando:

```
eksctl create iamserviceaccount --cluster=<clusterName> --name=<serviceAccountName> --tags "Owner=John Doe,Team=Some Team"
```

CloudFormation gerará um nome de função que inclui uma string aleatória. Se você preferir um nome de função predeterminado, você pode especificar`--role-name`:

```
eksctl create iamserviceaccount --cluster=<clusterName> --name=<serviceAccountName> --role-name "custom-role-name"
```

Quando a conta de serviço é criada e gerenciada por alguma outra ferramenta, como o helm, use `--role-only` para evitar conflitos. A outra ferramenta é então responsável por manter a anotação do ARN da função. Observe que não `--override-existing-serviceaccounts` tem efeito nas contas `roleOnly` `--role-only` /service, a função sempre será criada.

```
eksctl create iamserviceaccount --cluster=<clusterName> --name=<serviceAccountName> --role-only --role-name=<customRoleName>
```

Quando você tem uma função existente que deseja usar com uma conta de serviço, pode fornecer o `--attach-role-arn` sinalizador em vez de fornecer as políticas. Para garantir que a função só possa ser assumida pela conta de serviço especificada, você deve definir um documento de política de relacionamento [aqui](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions)].

```
eksctl create iamserviceaccount --cluster=<clusterName> --name=<serviceAccountName> --attach-role-arn=<customRoleARN>
```

Para atualizar as funções de uma conta de serviço, as permissões que você pode executar`eksctl update iamserviceaccount`.

**nota**  
 `eksctl delete iamserviceaccount`exclui o Kubernetes `ServiceAccounts` mesmo que eles não tenham sido criados por. `eksctl`

## Uso com arquivos de configuração
<a name="_usage_with_config_files"></a>

Para gerenciar `iamserviceaccounts` usando o arquivo de configuração, você deverá definir `iam.withOIDC: true` e listar a conta que deseja usar. `iam.serviceAccount`

*Todos os comandos suportam`--config-file`, você pode gerenciar *iamserviceaccounts* da mesma forma que nodegroups.* O `eksctl create iamserviceaccount` comando suporta `--include` e `--exclude` sinaliza (consulte [esta seção](general-nodegroups.md#node-include) para obter mais detalhes sobre como eles funcionam). E o `eksctl delete iamserviceaccount` comando `--only-missing` também suporta, então você pode realizar exclusões da mesma forma que os grupos de nós.

**nota**  
As contas de serviço do IAM têm como escopo um namespace, ou seja, duas contas de serviço com o mesmo nome podem existir em namespaces diferentes. Portanto, para definir de forma exclusiva uma conta de serviço como parte dos `--include` `--exclude` sinalizadores, você precisará passar a string do nome no formato. `namespace/name` Por exemplo:

```
eksctl create iamserviceaccount --config-file=<path> --include backend-apps/s3-reader
```

A opção de habilitar `wellKnownPolicies` está incluída para usar o IRSA com casos de uso conhecidos, como `cluster-autoscaler` e`cert-manager`, como uma abreviatura para listas de políticas.

As políticas conhecidas suportadas e outras propriedades do `serviceAccounts` estão documentadas [no esquema de configuração](https://geoffcline.github.io/eksctl-schema-demo/#iam-serviceAccounts).

Você usa o seguinte exemplo de configuração com`eksctl create cluster`:

```
# An example of ClusterConfig with IAMServiceAccounts:
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: cluster-13
  region: us-west-2

iam:
  withOIDC: true
  serviceAccounts:
  - metadata:
      name: s3-reader
      # if no namespace is set, "default" will be used;
      # the namespace will be created if it doesn't exist already
      namespace: backend-apps
      labels: {aws-usage: "application"}
    attachPolicyARNs:
    - "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
    tags:
      Owner: "John Doe"
      Team: "Some Team"
  - metadata:
      name: cache-access
      namespace: backend-apps
      labels: {aws-usage: "application"}
    attachPolicyARNs:
    - "arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess"
    - "arn:aws:iam::aws:policy/AmazonElastiCacheFullAccess"
  - metadata:
      name: cluster-autoscaler
      namespace: kube-system
      labels: {aws-usage: "cluster-ops"}
    wellKnownPolicies:
      autoScaler: true
    roleName: eksctl-cluster-autoscaler-role
    roleOnly: true
  - metadata:
      name: some-app
      namespace: default
    attachRoleARN: arn:aws:iam::123:role/already-created-role-for-app
nodeGroups:
  - name: "ng-1"
    tags:
      # EC2 tags required for cluster-autoscaler auto-discovery
      k8s.io/cluster-autoscaler/enabled: "true"
      k8s.io/cluster-autoscaler/cluster-13: "owned"
    desiredCapacity: 1
```

Se você criar um cluster sem esses campos definidos, poderá usar os seguintes comandos para habilitar tudo o que você precisa:

```
eksctl utils associate-iam-oidc-provider --config-file=<path>
eksctl create iamserviceaccount --config-file=<path>
```

## Mais informações
<a name="_further_information"></a>
+  [Apresentando funções refinadas do IAM para contas de serviço](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) 
+  [Guia do usuário do EKS - Funções do IAM para contas de serviço](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) 
+  [Mapeamento de usuários e funções do IAM para funções RBAC do Kubernetes](iam-identity-mappings.md) 