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à. # Concetti Il diagramma seguente mostra alcune delle opzioni disponibili per l'utilizzo di TLS in un cluster Amazon EKS. Il cluster di esempio si trova dietro un sistema di bilanciamento del carico. I numeri identificano i possibili endpoint per le comunicazioni protette da TLS. ![\[Un diagramma che mostra i possibili endpoint per la crittografia TLS. Ogni endpoint ha un numero che corrisponde all'elenco seguente.\]](http://docs.aws.amazon.com/it_it/privateca/latest/userguide/images/kubernetes-pca.png) 1. **Interruzione presso il sistema di bilanciamento del carico** Elastic Load Balancing (Elastic Load Balancing) è integrato con il servizio. AWS Certificate Manager Non è necessario installarlo `cert-manager` sul sistema di bilanciamento del carico. Puoi effettuare il provisioning di ACM con una CA privata, firmare un certificato con la CA privata e installare il certificato utilizzando la console Elastic Load Balancing. AWS Private CA i certificati vengono rinnovati automaticamente. In alternativa, puoi fornire un certificato privato a un sistema che non prevede il AWS bilanciamento del carico per terminare TLS. Ciò fornisce una comunicazione crittografata tra un client remoto e il sistema di bilanciamento del carico. I dati dopo il bilanciamento del carico sono stati passati non crittografati al cluster Amazon EKS. 1. **Terminazione presso il controller di ingresso Kubernetes** Il controller di ingresso si trova all'interno del cluster Amazon EKS e funge da sistema di bilanciamento del carico e router. Per utilizzare il controller di ingresso come endpoint del cluster per le comunicazioni esterne, devi: + Installa entrambi e `cert-manager` `aws-privateca-issuer` + Fornisci al controller un certificato privato TLS da. AWS Private CA Le comunicazioni tra il load balancer e il controller di ingresso sono crittografate, i dati vengono trasmessi in modo non crittografato alle risorse del cluster. 1. **Terminazione presso un pod** Ogni pod è un gruppo di uno o più contenitori che condividono risorse di archiviazione e di rete. Se installi entrambi `cert-manager` `aws-privateca-issuer` e fornisci al cluster una CA privata, Kubernetes può installare un certificato privato TLS firmato sui pod, se necessario. Per impostazione predefinita, una connessione TLS che termina su un pod non è disponibile per gli altri pod del cluster. 1. **Comunicazioni sicure tra i pod.** È possibile fornire certificati a più pod per consentire loro di comunicare tra loro. Gli scenari possibili sono i seguenti: + Il provisioning con certificati autofirmati generati da Kubernetes. Ciò protegge le comunicazioni tra i pod, ma i certificati autofirmati non soddisfano i requisiti HIPAA o FIPS. + Fornitura con certificati firmati da. AWS Private CA Ciò richiede l'installazione di entrambi `cert-manager` e`aws-privateca-issuer`. Kubernetes può quindi installare certificati MTLS firmati sui pod, se necessario.