Transport Layer Security (TLS)

In App Mesh, Transport Layer Security (TLS) crittografa la comunicazione tra i proxy Envoy distribuiti su risorse di elaborazione rappresentate in App Mesh da endpoint mesh, come e. Nodi virtuali Gateway virtuali virtuale virtuale virtuale virtuale virtuale virtuale 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 di AWS Certificate Manager (ACM) rilasciato da un AWS Private Certificate Authority (AWS Private CA).

• Un certificato memorizzato 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) tramite Unix Domain Socket locale.

Autorizzazione proxy Envoy Proxydeve 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 cui stai abilitando la crittografia.

Requisiti del certificato

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

• DNS: uno dei certificati SAN deve corrispondere al valore fornito nelle impostazioni di rilevamento del servizio DNS. Per un'applicazione con il nome di rilevamento del serviziomesh-endpoint.apps.local, è possibile creare un certificato corrispondente a quel nome o un certificato con la wild card. *.apps.local

• AWS Cloud Map— Uno dei certificati SAN deve corrispondere al valore fornito nelle impostazioni di individuazione del AWS Cloud Map servizio utilizzando il formatoservice-name.namespace-name. Per un'applicazione con le AWS Cloud Map impostazioni di rilevamento dei servizi di mesh-endpoint ServiceName e apps.local NameSpaceName, è possibile creare un certificato corrispondente al mesh-endpoint.apps.local nome o un certificato con la wild card *.apps.local.

Per entrambi i meccanismi di rilevamento, se nessuno dei SAN del certificato corrisponde alle impostazioni di rilevamento del servizio DNS, la connessione tra Envoys fallisce e viene visualizzato il seguente messaggio di errore, visualizzato dal client Envoy.

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Certificati di autenticazione TLS

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

AWS Private CA

Il certificato deve essere archiviato in ACM nella stessa regione e nello stesso AWS account dell'endpoint mesh che utilizzerà il certificato. Non è necessario che il certificato della CA si trovi nello stesso AWS account, ma deve comunque trovarsi nella stessa regione dell'endpoint mesh. Se non ne possiedi uno CA privata AWS, devi crearne uno prima di poterne richiedere un certificato. Per ulteriori informazioni sulla richiesta di un certificato da un ACM esistente che AWS Private CA utilizza ACM, consulta Richiedere un certificato privato. Il certificato non può essere un certificato pubblico.

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

Per configurare un nodo virtuale con certificati e CA da AWS Private CA, il principale (come un utente o un ruolo) che usi per chiamare App Mesh deve disporre delle seguenti autorizzazioni IAM:

• Per tutti i certificati aggiunti alla configurazione TLS di un listener, il principale deve disporre dell'autorizzazione. acm:DescribeCertificate

• Per qualsiasi CA configurata su una politica client TLS, il principale deve disporre dell'autorizzazione. acm-pca:DescribeCertificateAuthority

Importante

La condivisione delle CA con altri account può conferire a tali account privilegi involontari alla CA. Si consiglia di utilizzare politiche basate sulle risorse per limitare l'accesso solo acm-pca:DescribeCertificateAuthority agli account che non devono emettere certificati dalla CA. acm-pca:GetCertificateAuthorityCertificate

Puoi aggiungere queste autorizzazioni a una policy IAM esistente collegata a un principale o creare un nuovo principale e una nuova policy e allegare la policy al principale. Per ulteriori informazioni, consulta Modifica delle politiche IAM, Creazione delle politiche IAM e Aggiunta delle autorizzazioni di identità IAM.

Nota

Paghi una tariffa mensile per il funzionamento di ciascuno di essi AWS Private CA fino a quando non lo elimini. Paghi anche i certificati privati che emetti ogni mese e i certificati privati che esporti. Per ulteriori informazioni, consulta la sezione Prezzi di AWS Certificate Manager.

Quando abiliti l'autorizzazione proxy per l'Envoy Proxy rappresentato da un endpoint mesh, al ruolo IAM che utilizzi devono essere assegnate le seguenti autorizzazioni IAM:

• Per tutti i certificati configurati sul listener di un nodo virtuale, il ruolo deve disporre dell'autorizzazione. acm:ExportCertificate

• Per qualsiasi CA configurata su una politica client TLS, il ruolo deve disporre dell'autorizzazione. acm-pca:GetCertificateAuthorityCertificate

File system

È possibile distribuire 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) di Envoy

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

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

Importante

Local Secrets Discovery Service che utilizza Unix Domain Socket è supportato sul proxy App Mesh Envoy versione 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 collaterale dell'API SDS, comprese le toolchain esistenti come SPIFFE Runtime Environment (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 i carichi di lavoro, di breve durata e con 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, se necessario. 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à di servizio e i certificati CA vengono ruotati e gli aggiornamenti vengono trasmessi in streaming a Envoy. Envoy li applica immediatamente alle nuove connessioni senza interruzioni o tempi di inattività e senza che le chiavi private tocchino mai il file system.

In che modo App Mesh configura Envoys per negoziare TLS

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

Con le politiche dei clienti

Quando una politica client impone l'uso di TLS e una delle porte nella politica del client corrisponde alla politica della porta del server, la politica del 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 politica della porta del server, il TLS tra i proxy può essere negoziato o meno, a seconda delle impostazioni TLS della politica del server.

Senza politiche client

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 come. Ad esempio, se un gateway virtuale non ha specificato una policy 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 le modalità TLS STRICT oppurePERMISSIVE, i proxy verranno 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 dell'utente root a cui è collegato il certificato.

• 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 dei soggetti

Facoltativamente, puoi specificare un elenco di nomi alternativi dei soggetti (SAN) da considerare attendibili. I SAN devono essere in formato FQDN o URI. Se vengono forniti dei SAN, Envoy verifica che il nome alternativo dell'oggetto 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 Mesh TLS: requisiti del certificato.

Importante

È possibile utilizzare SAN wildcard solo se la politica del client per TLS è impostata su. not enforced Se la policy client per il nodo virtuale o il gateway virtuale del client è configurata per applicare TLS, non può accettare una SAN wildcard.

Verifica 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 il numero di handshake TLS riusciti per un endpoint mesh denominato con il comando seguente. my-mesh-endpoint

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

Nell'esempio seguente, l'output restituito è che 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 si sono verificati 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 ci sono stati errori per diverse statistiche, quindi la negoziazione TLS è riuscita.

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 di Envoy TLS, vedere Envoy Listener Statistics.

Rinnovo del certificato

AWS Private CA

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

Il tuo certificato

Quando si utilizza un certificato del file system locale, Envoy non ricaricherà automaticamente il certificato quando viene modificato. È 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 virtuale o del gateway con quel percorso di file.

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

Puoi configurare la tua mesh per utilizzare l'autenticazione TLS. Assicurati che i certificati siano disponibili per i sidecar proxy Envoy che aggiungi ai tuoi carichi di lavoro. Puoi collegare un volume EBS o EFS al tuo sidecar Envoy oppure puoi archiviare e recuperare i certificati da Secrets Manager. AWS

• 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 in. AWS 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 con AWS App Mesh

Puoi configurare il AWS App Mesh Controller for Kubernetes per abilitare l'autenticazione TLS per i backend e i listener dei servizi di nodi e gateway virtuali. Assicurati che i certificati siano disponibili per i sidecar proxy Envoy che aggiungi ai tuoi carichi di lavoro. Puoi vedere un esempio per ogni tipo di distribuzione nella sezione dettagliata 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 utilizzare un Kubernetes Secret montato sul file system.

• Se utilizzi una distribuzione basata su SDS, devi configurare un provider SDS locale del nodo che implementi l'API SDS di Envoy. Envoy lo raggiungerà tramite UDS. Per abilitare il supporto MTL basato su SDS nel AppMesh controller EKS, imposta il enable-sds flag su true e fornisci il percorso UDS del provider SDS locale al controller tramite il flag. sds-uds-path Se usi helm, li imposti 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.