Transport Layer Security (TLS)

Il certificato deve essere archiviato in ACM nella stessa regione e nello stesso AWS account dell'endpoint mesh che utilizzerà il certificato. Il certificato della CA non deve necessariamente appartenere allo stesso AWS account, ma deve comunque trovarsi nella stessa regione dell'endpoint mesh. Se non ne hai uno CA privata AWS, devi crearne uno prima di potervi richiedere un certificato. Per ulteriori informazioni sulla richiesta di un certificato da un ACM esistente AWS Private CA , 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 utente root.

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

Puoi aggiungere queste autorizzazioni a una policy IAM esistente associata a un principale o creare una nuova 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.

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:

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

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. https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret

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

È possibile 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 SPIRE Agent come provider SDS per Envoy. Consentitegli di fornire direttamente a Envoy il materiale chiave necessario per fornire l'autenticazione TLS reciproca. Esegui SPIRE Agents in sidecar accanto ai proxy Envoy. L'agente si occupa di rigenerare le chiavi e i 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 alle nuove connessioni senza interruzioni o tempi di inattività e senza che le chiavi private tocchino mai il file system.

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

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 il protocollo TLS dal client e in che modo. 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 oPERMISSIVE, 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.

È possibile specificare facoltativamente un elenco di nomi alternativi del soggetto (SAN) di cui fidarsi. 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.