

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à.

# Configura end-to-end la crittografia per le applicazioni su Amazon EKS utilizzando cert-manager e Let's Encrypt
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt"></a>

*Mahendra Revanasiddappa e Vasanth Jeyaraj, Amazon Web Services*

## Riepilogo
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-summary"></a>

L'implementazione della end-to-end crittografia può essere complessa e devi gestire i certificati per ogni risorsa nell'architettura dei microservizi. Sebbene sia possibile interrompere la connessione Transport Layer Security (TLS) ai margini della rete Amazon Web Services (AWS) con un Network Load Balancer o Amazon API Gateway, alcune organizzazioni richiedono la crittografia. end-to-end

Questo modello utilizza NGINX Ingress Controller per l'ingresso. Questo perché quando crei un ingresso Kubernetes, la risorsa di ingresso utilizza un Network Load Balancer. Il Network Load Balancer non consente il caricamento di certificati client. Pertanto, non puoi ottenere un TLS reciproco con Kubernetes Ingress.

Questo modello è destinato alle organizzazioni che richiedono l'autenticazione reciproca tra tutti i microservizi delle loro applicazioni. Mutual TLS riduce l'onere di mantenere i nomi utente o le password e può anche utilizzare il framework di sicurezza chiavi in mano. L'approccio di questo modello è compatibile se l'organizzazione ha un gran numero di dispositivi connessi o deve rispettare rigide linee guida di sicurezza.

Questo modello aiuta a migliorare il livello di sicurezza dell'organizzazione implementando la end-to-end crittografia per le applicazioni in esecuzione su Amazon Elastic Kubernetes Service (Amazon EKS). Questo modello fornisce un'applicazione e un codice di esempio nel repository di GitHub [End-to-end crittografia su Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme) per mostrare come un microservizio funziona con la end-to-end crittografia su Amazon EKS. L'approccio del pattern utilizza [cert-manager](https://cert-manager.io/docs/), un componente aggiuntivo di Kubernetes, con [Let's Encrypt](https://letsencrypt.org/) come autorità di certificazione (CA). Let's Encrypt è una soluzione economica per gestire i certificati e fornisce certificati gratuiti validi per 90 giorni. Cert-manager automatizza il provisioning e la rotazione su richiesta dei certificati quando viene distribuito un nuovo microservizio su Amazon EKS. 

**Destinatari**

Questo modello è consigliato agli utenti che hanno esperienza con Kubernetes, TLS, Amazon Route 53 e Domain Name System (DNS).

## Prerequisiti e limitazioni
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-prereqs"></a>

**Prerequisiti**
+ Un account AWS attivo.
+ Un cluster Amazon EKS esistente.
+ AWS Command Line Interface (AWS CLI) versione 1.7 o successiva, installata e configurata su macOS, Linux o Windows.
+ L'utilità da riga di `kubectl` comando, installata e configurata per accedere al cluster Amazon EKS. Per ulteriori informazioni su questo argomento, consulta [Installazione di kubectl nella documentazione](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) di Amazon EKS.
+ Un nome DNS esistente per testare l'applicazione. Per ulteriori informazioni su questo argomento, consulta [Registrazione di nomi di dominio utilizzando Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html) nella documentazione di Amazon Route 53. 
+ L'ultima versione di [Helm](https://docs.aws.amazon.com/eks/latest/userguide/helm.html), installata sul tuo computer locale. Per ulteriori informazioni su questo argomento, consulta [Using Helm with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/helm.html) nella documentazione di Amazon EKS e nel repository GitHub [Helm](https://github.com/helm/helm). 
+ La GitHub [End-to-end crittografia nel repository Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme), clonata sul tuo computer locale. 
+ Sostituisci i seguenti valori nei `trustpolicy.json` file `policy.json` and dalla GitHub [End-to-end crittografia clonata sull'archivio Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme):
  + `<account number>`— Sostituiscilo con l'ID dell'account AWS per l'account in cui desideri implementare la soluzione. 
  + `<zone id>`— Sostituire con l'ID di zona Route 53 del nome di dominio. 
  + `<node_group_role>`— Sostituire con il nome del ruolo AWS Identity and Access Management (IAM) associato ai nodi Amazon EKS.
  + `<namespace>`— Sostituiscilo con lo spazio dei nomi Kubernetes in cui distribuisci il controller di ingresso NGINX e l'applicazione di esempio.
  + `<application-domain-name>`— Sostituire con il nome di dominio DNS di Route 53.

**Limitazioni**
+ Questo modello non descrive come ruotare i certificati e dimostra solo come utilizzare i certificati con microservizi su Amazon EKS. 

## Architecture
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-architecture"></a>

Il diagramma seguente mostra i componenti del flusso di lavoro e dell'architettura di questo modello.

![Flusso di lavoro per configurare la crittografia per le applicazioni su Amazon EKS utilizzando cert-manager e Let's Encrypt.](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/images/pattern-img/9aa3ee9e-73db-41f5-a467-b5c47fef496e/images/40692ede-6fb3-474e-8c9e-85c51529e8ad.png)


Il diagramma mostra il flusso di lavoro seguente:

1. Un client invia una richiesta di accesso all'applicazione al nome DNS.

1. Il record Route 53 è un CNAME per il Network Load Balancer.

1. Il Network Load Balancer inoltra la richiesta al controller di ingresso NGINX configurato con un listener TLS. La comunicazione tra NGINX Ingress Controller e Network Load Balancer segue il protocollo HTTPS.

1. Il NGINX Ingress Controller esegue il routing basato sul percorso in base alla richiesta del client al servizio applicativo.

1. Il servizio applicativo inoltra la richiesta al pod dell'applicazione. L'applicazione è progettata per utilizzare lo stesso certificato chiamando segreti.

1. I pod eseguono l'applicazione di esempio utilizzando i certificati cert-manager. La comunicazione tra NGINX Ingress Controller e i pod utilizza HTTPS.


| 
| 
| Nota: Cert-Manager viene eseguito nel proprio spazio dei nomi. Utilizza un ruolo del cluster Kubernetes per fornire certificati come segreti in namespace specifici. Puoi collegare questi namespace ai pod delle applicazioni e al NGINX Ingress Controller.  | 
| --- |

## Tools (Strumenti)
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-tools"></a>

**Servizi AWS**
+ [Amazon Elastic Kubernetes Service (Amazon](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) EKS) è un servizio gestito che puoi usare per eseguire Kubernetes su AWS senza dover installare, gestire e mantenere il tuo piano di controllo o i tuoi nodi Kubernetes.
+ [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) distribuisce automaticamente il traffico in entrata su più destinazioni, contenitori e indirizzi IP.
+ [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) ti aiuta a gestire in modo sicuro l'accesso alle tue risorse AWS controllando chi è autenticato e autorizzato a utilizzarle.
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) è un servizio Web DNS altamente scalabile e disponibile.

**Altri strumenti**
+ [cert-manager](https://cert-manager.io/docs/installation/supported-releases/) è un componente aggiuntivo di Kubernetes che richiede certificati, li distribuisce nei contenitori Kubernetes e automatizza il rinnovo dei certificati.
+ [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/) è una soluzione di gestione del traffico per app native del cloud in Kubernetes e ambienti containerizzati.

## Epiche
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-epics"></a>

### Crea e configura una zona ospitata pubblica con Route 53
<a name="create-and-configure-a-public-hosted-zone-with-route-53"></a>


| Operazione | Description | Competenze richieste | 
| --- | --- | --- | 
| Crea una zona ospitata pubblica in Route 53. | Accedi alla Console di gestione AWS, apri la console Amazon Route 53, scegli **Zone ospitate**, quindi scegli **Crea zona ospitata**. Crea una zona ospitata pubblica e registra l'ID della zona. Per ulteriori informazioni su questo argomento, consulta [Creazione di una zona ospitata pubblica](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html) nella documentazione di Amazon Route 53.ACME DNS01 utilizza il provider DNS per inviare una richiesta di rilascio del certificato al cert-manager. Questa sfida ti chiede di dimostrare di controllare il DNS del tuo nome di dominio inserendo un valore specifico in un record TXT sotto quel nome di dominio. Dopo che Let's Encrypt ha assegnato un token al tuo client ACME, quest'ultimo crea un record TXT derivato da quel token e dalla chiave del tuo account, e inserisce quel record in. `_acme-challenge.<YOURDOMAIN>` Quindi Let's Encrypt interroga il DNS per quel record. Se trova una corrispondenza, puoi procedere all'emissione di un certificato. | AWS DevOps | 

### Configura un ruolo IAM per consentire al cert-manager di accedere alla zona pubblica ospitata
<a name="configure-an-iam-role-to-allow-cert-manager-to-access-the-public-hosted-zone"></a>


| Operazione | Description | Competenze richieste | 
| --- | --- | --- | 
| Crea la policy IAM per cert-manager.  | È necessaria una policy IAM per fornire al cert-manager l'autorizzazione a convalidare la proprietà del dominio Route 53. La policy IAM di `policy.json` esempio è fornita nella `1-IAMRole` directory del repository di GitHub [End-to-end crittografia clonata su Amazon EKS](https://github.com/aws-samples/end-to-end-encryption-on-amazon-eks#readme).<br />Inserisci il seguente comando nella CLI di AWS per creare la policy IAM.<pre>aws iam create-policy \<br />  --policy-name PolicyForCertManager \<br />  --policy-document file://policy.json</pre> | AWS DevOps | 
| Crea il ruolo IAM per cert-manager. | Dopo aver creato la policy IAM, devi creare un ruolo IAM. Il ruolo IAM di `trustpolicy.json` esempio è fornito nella `1-IAMRole` directory.<br />Inserisci il seguente comando nella CLI di AWS per creare il ruolo IAM.<pre>aws iam create-role \<br />  --role-name RoleForCertManager \<br />  --assume-role-policy-document file://trustpolicy.json</pre> | AWS DevOps | 
| Collegare la policy al ruolo. | Inserisci il seguente comando nella CLI di AWS per collegare la policy IAM al ruolo IAM. Sostituiscilo `AWS_ACCOUNT_ID` con l'ID del tuo account AWS. <pre>aws iam attach-role-policy \<br />  --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/PolicyForCertManager \<br />  --role-name RoleForCertManager</pre> | AWS DevOps | 

### Configurazione del controller di ingresso NGINX in Amazon EKS
<a name="set-up-the-nginx-ingress-controller-in-amazon-eks"></a>


| Operazione | Description | Competenze richieste | 
| --- | --- | --- | 
| Implementa il controller di ingresso NGINX. | Installa la versione più recente di utilizzo di Helm. `nginx-ingress` È possibile modificare la `nginx-ingress` configurazione in base alle proprie esigenze prima di distribuirla. Questo modello utilizza un Network Load Balancer annotato e rivolto internamente, disponibile nella directory. `5-Nginx-Ingress-Controller` <br />Installa il controller di ingresso NGINX eseguendo il seguente comando Helm dalla directory. `5-Nginx-Ingress-Controller`<br />`helm install test-nginx nginx-stable/nginx-ingress  -f  5-Nginx-Ingress-Controller/values_internal_nlb.yaml` | AWS DevOps | 
| Verifica che il controller di ingresso NGINX sia installato. | Immettere il comando `helm list`. L'output dovrebbe mostrare che il NGINX Ingress Controller è installato. | AWS DevOps | 
| Crea un record Route 53 A. | Il record A punta al Network Load Balancer creato da NGINX Ingress Controller.[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 

### Configurare NGINX VirtualServer su Amazon EKS
<a name="set-up-nginx-virtualserver-on-amazon-eks"></a>


| Operazione | Description | Competenze richieste | 
| --- | --- | --- | 
| Implementa NGINX VirtualServer. | La VirtualServer risorsa NGINX è una configurazione di bilanciamento del carico alternativa alla risorsa in ingresso. La configurazione per creare la VirtualServer risorsa NGINX è disponibile nel file nella directory. `nginx_virtualserver.yaml` `6-Nginx-Virtual-Server` Immettete il seguente comando `kubectl` per creare la risorsa VirtualServer NGINX.<br />`kubectl apply -f  nginx_virtualserver.yaml`Assicurati di aggiornare il nome di dominio dell'applicazione, il segreto del certificato e il nome del servizio dell'applicazione nel `nginx_virtualserver.yaml` file. | AWS DevOps | 
| Verifica che NGINX VirtualServer sia stato creato. | Inserisci il seguente comando `kubectl` per verificare che la VirtualServer risorsa NGINX sia stata creata correttamente.<br />`kubectl get virtualserver`Verifica che la `Host` colonna corrisponda al nome di dominio dell'applicazione. | AWS DevOps | 
| Implementa il server web NGINX con TLS abilitato. | Questo modello utilizza un server web NGINX con TLS abilitato come applicazione per testare la crittografia. end-to-end I file di configurazione necessari per distribuire l'applicazione di test sono disponibili nella directory. `demo-webserver` <br />Immettete il seguente comando `kubectl` per distribuire l'applicazione di test.<br />`kubectl apply -f nginx-tls-ap.yaml` | AWS DevOps | 
| Verifica che le risorse dell'applicazione di test siano state create. | Immettete i seguenti comandi `kubectl` per verificare che vengano create le risorse richieste per l'applicazione di test:[See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 
| Convalida l'applicazione. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/patterns/set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt.html) | AWS DevOps | 

## Risorse correlate
<a name="set-up-end-to-end-encryption-for-applications-on-amazon-eks-using-cert-manager-and-let-s-encrypt-resources"></a>

**Risorse AWS**
+ [Creazione di record utilizzando la console Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html) (documentazione Amazon Route 53)
+ [Utilizzo di un Network Load Balancer con il controller di ingresso NGINX su Amazon EKS (post sul blog AWS](https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/))

**Altre risorse**
+ [Route 53](https://cert-manager.io/docs/configuration/acme/dns01/route53/) (documentazione del cert-manager)
+ [Configurazione di DNS01 Challenge](https://cert-manager.io/docs/configuration/acme/dns01/) Provider (documentazione cert-manager)
+ Sfida [Let's encrypt DNS](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) (documentazione Let's Encrypt)