

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Ruoli IAM per gli account di servizio
<a name="iamserviceaccounts"></a>

**Suggerimento**  
 `eksctl`[supporta la configurazione di autorizzazioni granulari per le app che eseguono EKS tramite EKS Pod Identity Associations](pod-identity-associations.md) 

Amazon EKS supporta [here](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) Roles for Service Accounts (IRSA)] che consente agli operatori del cluster di mappare i ruoli AWS IAM agli account di servizio Kubernetes.

Ciò fornisce una gestione granulare delle autorizzazioni per le app eseguite su EKS e che utilizzano altri servizi AWS. Potrebbero essere app che utilizzano S3, qualsiasi altro servizio dati (RDS, MQ, STS, DynamoDB) o componenti Kubernetes come il controller AWS Load Balancer o ExternalDNS.

Puoi creare facilmente coppie di ruoli e account di servizio IAM con. `eksctl`

**Nota**  
Se hai utilizzato [ruoli di istanza](iam-policies.md) e stai pensando di utilizzare invece IRSA, non dovresti mischiare i due.

## Come funziona
<a name="iam-how-works"></a>

Funziona tramite IAM OpenID Connect Provider (OIDC) esposto da EKS e i ruoli IAM devono essere costruiti con riferimento al provider IAM OIDC (specifico per un determinato cluster EKS) e un riferimento all'account di servizio Kubernetes a cui sarà associato. Una volta creato un ruolo IAM, un account di servizio dovrebbe includere l'ARN di quel ruolo come annotazione (). `eks.amazonaws.com/role-arn` Per impostazione predefinita, l'account di servizio verrà creato o aggiornato per includere l'annotazione del ruolo, che può essere disabilitata utilizzando il flag. `--role-only`

All'interno di EKS, c'è un [controller di ammissione](https://github.com/aws/amazon-eks-pod-identity-webhook/) che inietta le credenziali di sessione AWS nei pod rispettivamente dei ruoli in base all'annotazione sull'account di servizio utilizzato dal pod. Le credenziali verranno esposte dalle variabili di ambiente &. `AWS_ROLE_ARN` `AWS_WEB_IDENTITY_TOKEN_FILE` Dato che viene utilizzata una versione recente di AWS SDK (vedi [qui](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) per i dettagli della versione esatta), l'applicazione utilizzerà queste credenziali.

Nel nome `eksctl` della risorsa c'è *iamserviceaccount*, che rappresenta una coppia IAM Role e Service Account.

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

**Nota**  
IAM Roles for Service Accounts richiede la versione 1.13 o successiva di Kubernetes.

Il provider IAM OIDC non è abilitato per impostazione predefinita, puoi utilizzare il seguente comando per abilitarlo o utilizzare il file di configurazione (vedi sotto):

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

Una volta associato il provider IAM OIDC al cluster, per creare un ruolo IAM associato a un account di servizio, esegui:

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

**Nota**  
Puoi specificare `--attach-policy-arn` più volte di utilizzare più di una policy.

Più specificamente, puoi creare un account di servizio con accesso in sola lettura a S3 eseguendo:

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

Per impostazione predefinita, verrà creato nello spazio dei `default` nomi, ma puoi specificare qualsiasi altro spazio dei nomi, ad esempio:

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

**Nota**  
Se il namespace non esiste già, verrà creato.

Se hai già un account di servizio creato nel cluster (senza un ruolo IAM), dovrai usare `--override-existing-serviceaccounts` flag.

I tag personalizzati possono essere applicati anche al ruolo IAM `--tags` specificando:

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

CloudFormation genererà un nome di ruolo che include una stringa casuale. Se preferisci un nome di ruolo predeterminato puoi specificare`--role-name`:

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

Quando l'account di servizio viene creato e gestito da un altro strumento, ad esempio helm, utilizzalo `--role-only` per prevenire i conflitti. L'altro strumento è quindi responsabile del mantenimento dell'annotazione ARN del ruolo. Nota che non `--override-existing-serviceaccounts` ha alcun effetto sugli account `roleOnly` `--role-only` /service, il ruolo verrà sempre creato.

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

Se disponi di un ruolo esistente che desideri utilizzare con un account di servizio, puoi fornire il `--attach-role-arn` flag invece di fornire le politiche. Per garantire che il ruolo possa essere assunto solo dall'account di servizio specificato, è necessario impostare [qui](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) un documento sulla politica di relazione].

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

Per aggiornare i ruoli di un account di servizio, le autorizzazioni che puoi eseguire`eksctl update iamserviceaccount`.

**Nota**  
 `eksctl delete iamserviceaccount`elimina Kubernetes `ServiceAccounts` anche se non sono stati creati da. `eksctl`

## Utilizzo con file di configurazione
<a name="_usage_with_config_files"></a>

Per gestire `iamserviceaccounts` l'utilizzo del file di configurazione, dovrai impostare `iam.withOIDC: true` ed elencare l'account che desideri utilizzare. `iam.serviceAccount`

*Tutti i comandi supportati`--config-file`, puoi gestire *iamserviceaccounts* allo stesso modo dei nodegroups.* I supporti `--include` e i `--exclude` flag dei `eksctl create iamserviceaccount` comandi (consulta [questa sezione](general-nodegroups.md#node-include) per maggiori dettagli su come funzionano). Inoltre, il `eksctl delete iamserviceaccount` comando `--only-missing` lo supporta, quindi puoi eseguire le eliminazioni allo stesso modo dei gruppi di nodi.

**Nota**  
Gli account di servizio IAM rientrano nell'ambito di un namespace, ovvero possono esistere due account di servizio con lo stesso nome in namespace diversi. Pertanto, per definire in modo univoco un account di servizio come parte di`--include`, `--exclude` flags, è necessario passare la stringa del nome nel formato. `namespace/name` (ad esempio

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

L'opzione di attivazione `wellKnownPolicies` è inclusa per utilizzare IRSA con casi d'uso noti come `cluster-autoscaler` e`cert-manager`, come abbreviazione per elenchi di policy.

[Le politiche note supportate e altre proprietà di `serviceAccounts` sono documentate nello schema di configurazione.](https://geoffcline.github.io/eksctl-schema-demo/#iam-serviceAccounts)

Si utilizza il seguente esempio di configurazione con: `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 crei un cluster senza questi campi impostati, puoi utilizzare i seguenti comandi per abilitare tutto ciò di cui hai bisogno:

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

## Ulteriori informazioni
<a name="_further_information"></a>
+  [Presentazione dei ruoli IAM dettagliati per gli account di servizio](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) 
+  [Guida per l'utente EKS - IAM Roles For Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) 
+  [Mappatura degli utenti e del ruolo IAM ai ruoli RBAC di Kubernetes](iam-identity-mappings.md) 