Transport Layer Security (TLS) - AWS App Mesh

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

Transport Layer Security (TLS)

In App Mesh, Transport Layer Security (TLS) crittografa la comunicazione tra i proxy Envoy distribuiti sulle risorse di calcolo rappresentate in App Mesh da endpoint mesh, comeNodi virtualieGateway virtuali. Il proxy negozia e termina TLS. Quando il proxy viene distribuito con un'applicazione, il codice dell'applicazione non è responsabile della negoziazione di una sessione TLS. Il proxy negozia TLS per conto dell'applicazione.

App Mesh consente di fornire il certificato TLS al proxy nei seguenti modi:

  • Un certificato privato daAWS Certificate Manager(ACM) emesso da unAWS Certificate Manager Private Certificate Authority(ACM PCA).

  • Un certificato archiviato nel file system locale di un nodo virtuale emesso dalla propria autorità di certificazione (CA)

  • Un certificato fornito da un endpoint Secrets Discovery Service (SDS) su un socket di dominio Unix locale.

Envoy Proxy Authorizationdeve essere abilitato per il proxy Envoy distribuito rappresentato da un endpoint mesh. Quando abiliti l'autorizzazione proxy, ti consigliamo di limitare l'accesso solo all'endpoint mesh per il quale stai abilitando la crittografia.

Requisiti del certificato

Uno dei nomi alternativi del soggetto (SAN) del certificato deve soddisfare criteri specifici, a seconda di come viene rilevato il servizio effettivo rappresentato da un endpoint mesh.

  • DNS— Uno dei SAN certificati deve corrispondere al valore fornito nelle impostazioni di rilevamento del servizio DNS. Per un'applicazione con il nome di service discoverymesh-endpoint.apps.local, puoi creare un certificato corrispondente a quel nome o un certificato con la wild card*.apps.local.

  • AWS Cloud Map— Uno dei SAN certificati deve corrispondere al valore fornito nelAWS Cloud Mapimpostazioni di rilevamento del servizio utilizzando il formatoservice-name.namespace-name. Per un'applicazione conAWS Cloud Mapimpostazioni di rilevamento del servizio di serviceNamemesh-endpointe il NameSpaceNameapps.local, puoi creare un certificato corrispondente al nomemesh-endpoint.apps.localo un certificato con la wild card*.apps.local.

Per entrambi i meccanismi di rilevamento, se nessuno dei SAN certificati corrisponde alle impostazioni di rilevamento del servizio DNS, la connessione tra Envoys fallisce con il seguente messaggio di errore, come mostrato dal client Envoy.

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Certificati di autenticazione TLS

App Mesh supporta più fonti di certificati quando si utilizza l'autenticazione TLS.

ACM PCA

Il certificato deve essere memorizzato in ACM nella stessa regione eAWSaccount come endpoint mesh che utilizzerà il certificato. Non è necessario che il certificato della CA sia nello stessoAWSaccount, ma deve comunque trovarsi nella stessa regione dell'endpoint della mesh. Se non disponi di una CA privata ACM, devicreane unoprima di poter richiedere un certificato. Per ulteriori informazioni su come richiedere un certificato da un ACM PCA esistente tramite ACM, consulta la paginaRichiedi un certificato privato. Il certificato non può essere un certificato pubblico.

Le CA private utilizzate per le policy dei client TLS devono essere CA root.

Per configurare un nodo virtuale con certificati e CA di ACM PCA, il principale (come un utente o un ruolo) utilizzato per chiamare App Mesh deve avere le seguenti autorizzazioni IAM:

  • Per qualsiasi certificato aggiunto alla configurazione TLS di un listener, il principale deve avere ilacm:DescribeCertificateautorizzazione.

  • Per tutte le CA configurate su una policy client TLS, il committente deve disporre delacm-pca:DescribeCertificateAuthorityautorizzazione.

Importante

La condivisione delle CA con altri account può conferire a tali account privilegi involontari alla CA. Ti consigliamo di utilizzare policy basate sulle risorse per limitare l'accesso solo aacm-pca:DescribeCertificateAuthorityeacm-pca:GetCertificateAuthorityCertificateper gli account che non devono emettere certificati dalla CA.

È possibile aggiungere queste autorizzazioni a una policy IAM esistente associata a un committente o creare un nuovo principale e una nuova policy e allegare la policy al principale. Per ulteriori informazioni, consulta la paginaModifica delle policy IAM,Creazione di policy IAM, eAggiungere le autorizzazioni di identità IAM.

Nota

Paghi una tariffa mensile per il funzionamento di ogni ACM PCA fino a quando non lo elimini. Paghi anche i certificati privati che emetti ogni mese e i certificati privati che esporti. Per ulteriori informazioni, consultare Prezzi di AWS Certificate Manager.

Quando abilitiautorizzazione proxyper l'Envoy Proxy rappresentato da un endpoint mesh, al ruolo IAM utilizzato devono essere assegnate le seguenti autorizzazioni IAM:

  • Per qualsiasi certificato configurato sul listener di un nodo virtuale, il ruolo deve avere ilacm:ExportCertificateautorizzazione.

  • Per tutte le CA configurate su una policy client TLS, il ruolo deve disporre delacm-pca:GetCertificateAuthorityCertificateautorizzazione.

File system

È possibile distribuire i certificati a Envoy utilizzando il file system. È possibile farlo rendendo disponibili la catena di certificati e la chiave privata corrispondente nel percorso del file. In questo modo, queste risorse sono raggiungibili dal proxy sidecar Envoy.

Secret Discovery Service (SDS) dell'inviato

Envoy recupera segreti come i certificati TLS da un endpoint specifico tramite il protocollo Secrets Discovery. Per ulteriori informazioni su questo protocollo, consulta la pagina Envoy'sDocumentazione SDS.

App Mesh configura il proxy Envoy per utilizzare un socket di dominio Unix locale al proxy per fungere da endpoint Secret Discovery Service (SDS) quando SDS funge da origine per i certificati e le catene di certificati. È possibile configurare il percorso di questo endpoint utilizzando ilAPPMESH_SDS_SOCKET_PATHvariabile di ambiente.

Importante

Il servizio Local Secrets Discovery che utilizza Unix Domain Socket è supportato dalla versione proxy di App Mesh Envoy 1.15.1.0 e successive.

App Mesh supporta il protocollo SDS V2 utilizzando gRPC.

Integrazione con SPIFFE Runtime Environment (SPIRE)

Puoi utilizzare qualsiasi implementazione laterale dell'API SDS, comprese le toolchain esistenti comeAmbiente di runtime SPIFFE (SPIRE). SPIRE è progettato per consentire l'implementazione dell'autenticazione TLS reciproca tra più carichi di lavoro in sistemi distribuiti. Attesta l'identità dei carichi di lavoro in fase di esecuzione. SPIRE fornisce inoltre chiavi e certificati specifici per il carico di lavoro, di breve durata e a rotazione automatica direttamente ai carichi di lavoro.

È necessario configurare l'agente SPIRE come provider SDS per Envoy. Consentitegli di fornire direttamente a Envoy il materiale chiave di cui ha bisogno per fornire l'autenticazione TLS reciproca. Esegui gli agenti SPIRE nei sidecar accanto ai proxy Envoy. L'agente si occupa della rigenerazione delle chiavi e dei certificati di breve durata, come richiesto. L'agente attesta Envoy e determina quali identità di servizio e certificati CA deve rendere disponibili a Envoy quando Envoy si connette al server SDS esposto dall'agente SPIRE.

Durante questo processo, le identità dei servizi e i certificati CA vengono ruotati e gli aggiornamenti vengono trasmessi a Envoy. Envoy li applica immediatamente a nuove connessioni senza interruzioni o tempi di inattività e senza che le chiavi private tocchino mai il file system.

  • AWS Certificate Manager–AWS Certificate Manager Private Certificate Authority(ACM PCA) può essere utilizzato insieme a SPIRE per fungere da autorità di certificazione upstream. Utilizzando una Private Certificate Authority (PCA), le chiavi private per le CA sono basate su hardware e non sono archiviate nella memoria o sul disco. Questo aggiunge un ulteriore livello di sicurezza. Per ulteriori informazioni, consulta laDocumentazione SPIRE.

In che modo App Mesh configura Envoys per negoziare TLS

App Mesh utilizza la configurazione mesh degli endpoint sia del client che del server per determinare come configurare la comunicazione tra Envoys in una mesh.

Con le politiche dei clienti

Quando una policy client impone l'uso di TLS e una delle porte della policy client corrisponde alla porta della politica del server, la politica client viene utilizzata per configurare il contesto di convalida TLS del client. Ad esempio, se la politica client di un gateway virtuale corrisponde alla politica del server di un nodo virtuale, verrà tentata la negoziazione TLS tra i proxy utilizzando le impostazioni definite nella politica client del gateway virtuale. Se la politica del client non corrisponde alla porta della politica del server, il TLS tra i proxy può essere negoziato o meno, a seconda delle impostazioni TLS della politica del server.

Senza politiche dei clienti

Se il client non ha configurato una politica client o la politica del client non corrisponde alla porta del server, App Mesh utilizzerà il server per determinare se negoziare o meno TLS dal client e in che modo. Ad esempio, se un gateway virtuale non ha specificato una politica client e un nodo virtuale non ha configurato la terminazione TLS, TLS non verrà negoziato tra i proxy. Se un client non ha specificato una politica client corrispondente e un server è stato configurato con modalità TLSSTRICToPERMISSIVE, i proxy saranno configurati per negoziare TLS. A seconda di come sono stati forniti i certificati per la terminazione TLS, si applica il seguente comportamento aggiuntivo.

  • Certificati TLS gestiti da ACM— Quando un server ha configurato la terminazione TLS utilizzando un certificato gestito da ACM, App Mesh configura automaticamente i client per negoziare TLS e convalidare il certificato rispetto alla CA principale a cui il certificato è collegato.

  • Certificati TLS basati su file— Quando un server ha configurato la terminazione TLS utilizzando un certificato del file system locale del proxy, App Mesh configura automaticamente un client per negoziare TLS, ma il certificato del server non viene convalidato.

Nomi alternativi dell'oggetto

Facoltativamente, è possibile specificare un elenco di nomi alternativi dei soggetti (SAN) da considerare attendibili. I SAN devono essere nel formato FQDN o URI. Se vengono forniti dei SAN, Envoy verifica che il nome alternativo del soggetto del certificato presentato corrisponda a uno dei nomi in questo elenco.

Se non si specificano le SAN nell'endpoint della mesh di terminazione, il proxy Envoy per quel nodo non verifica la SAN su un certificato client peer. Se non si specificano le SAN nell'endpoint della mesh di origine, la SAN sul certificato fornito dall'endpoint di terminazione deve corrispondere alla configurazione di rilevamento del servizio endpoint della mesh.

Per ulteriori informazioni, consulta App MeshTLS: Requisiti del.

Importante

È possibile utilizzare i SAN con caratteri jolly solo se la politica del client per TLS è impostata sunot enforced. Se la policy del client per il nodo virtuale o il gateway virtuale del client è configurata per applicare TLS, non può accettare una rete SAN jolly.

Verificare la crittografia

Dopo aver abilitato TLS, puoi interrogare il proxy Envoy per confermare che la comunicazione sia crittografata. Il proxy Envoy emette statistiche sulle risorse che possono aiutarti a capire se la tua comunicazione TLS funziona correttamente. Ad esempio, il proxy Envoy registra le statistiche sul numero di handshake TLS riusciti che ha negoziato per un endpoint mesh specificato. Determina quanti handshake TLS hanno avuto successo per un endpoint mesh denominatomy-mesh-endpointcon il comando riportato qui di seguito.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep ssl.handshake

Nel seguente esempio restituito l'output, c'erano tre handshake per l'endpoint mesh, quindi la comunicazione è crittografata.

listener.0.0.0.0_15000.ssl.handshake: 3

Il proxy Envoy emette anche statistiche quando la negoziazione TLS fallisce. Determina se ci sono stati errori TLS per l'endpoint mesh.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep -e "ssl.*\(fail\|error\)"

Nell'esempio restituito dall'output, non vi sono stati errori per diverse statistiche, pertanto la negoziazione TLS ha avuto successo.

listener.0.0.0.0_15000.ssl.connection_error: 0 listener.0.0.0.0_15000.ssl.fail_verify_cert_hash: 0 listener.0.0.0.0_15000.ssl.fail_verify_error: 0 listener.0.0.0.0_15000.ssl.fail_verify_no_cert: 0 listener.0.0.0.0_15000.ssl.ssl.fail_verify_san: 0

Per ulteriori informazioni sulle statistiche TLS di Envoy, consulta la paginaStatistiche Envoy Listener.

Rinnovo del certificato

ACM PCA

Quando rinnovi un certificato con ACM, il certificato rinnovato verrà automaticamente distribuito ai proxy connessi entro 35 minuti dal completamento del rinnovo. Ti consigliamo di utilizzare il rinnovo gestito per rinnovare automaticamente i certificati verso la fine del loro periodo di validità. Per ulteriori informazioni, consulta la paginaRinnovo gestito per i certificati emessi da Amazon di ACMnelAWS Certificate ManagerGuida per l'utente.

Certificato dell'utente

Quando si utilizza un certificato dal file system locale, Envoy non ricaricherà automaticamente il certificato quando cambia. È possibile riavviare o ridistribuire il processo Envoy per caricare un nuovo certificato. È inoltre possibile inserire un certificato più recente in un percorso di file diverso e aggiornare la configurazione del nodo o del gateway virtuale con quel percorso di file.

Configura i carichi di lavoro Amazon ECS per utilizzare l'autenticazione TLS conAWS App Mesh

È possibile configurare la mesh per utilizzare l'autenticazione TLS. Assicurati che i certificati siano disponibili per i proxy sidecar Envoy che aggiungi ai tuoi carichi di lavoro. È possibile allegare un volume EBS o EFS al sidecar Envoy oppure archiviare e recuperare i certificati daAWSSecrets Manager.

  • Se utilizzi la distribuzione di certificati basata su file, collega un volume EBS o EFS al sidecar Envoy. Assicurati che il percorso del certificato e della chiave privata corrisponda a quello configurato inAWS App Mesh.

  • Se utilizzi una distribuzione basata su SDS, aggiungi un sidecar che implementa l'API SDS di Envoy con accesso al certificato.

Nota

SPIRE non è supportato su Amazon ECS.

Configura i carichi di lavoro Kubernetes per utilizzare l'autenticazione TLS conAWS App Mesh

È possibile configurare l'AWS App MeshController per Kubernetes per abilitare l'autenticazione TLS per i backend e i listener dei servizi di gateway virtuali e nodi virtuali. Assicurati che i certificati siano disponibili per i sidecar proxy Envoy che aggiungi ai tuoi carichi di lavoro. È possibile visualizzare un esempio per ogni tipo di distribuzione nelprocedura dettagliatasezione di Autenticazione TLS reciproca.

  • Se utilizzi la distribuzione di certificati basata su file, collega un volume EBS o EFS al sidecar Envoy. Assicurati che il percorso del certificato e della chiave privata corrisponda a quello configurato nel controller. In alternativa, puoi usare un Kubernetes Secret montato sul file system.

  • Se utilizzi una distribuzione basata su SDS, devi configurare un provider SDS locale del nodo che implementa l'API SDS di Envoy. L'inviato lo raggiungerà tramite UDS. Per abilitare il supporto MTL basato su SDS in EKS AppMesh controller, imposta ilenable-sdsFlag atruee fornisce il percorso UDS del provider SDS locale al controller tramite ilsds-uds-pathFlag. Se usi helm, impostali come parte dell'installazione del controller:

    --set sds.enabled=true
Nota

Non potrai utilizzare SPIRE per distribuire i tuoi certificati se utilizzi Amazon Elastic Kubernetes Service (Amazon EKS) in modalità Fargate.