Transport Layer Security (TLS)

Il certificato deve essere archiviato 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 utente esistenteACM, AWS Private CA consulta Richiedere un certificato privato. Il certificato non può essere un certificato pubblico.

L'utente privato CAs utilizzato per le politiche TLS dei client deve essere un utente rootCAs.

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

È possibile aggiungere queste autorizzazioni a una IAM politica esistente associata a un principale o creare un nuovo principale e una nuova politica e allegare la politica al principale. Per ulteriori informazioni, vedere Modifica dei IAM criteri, Creazione IAM di criteri e Aggiungere autorizzazioni di IAM identità.

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

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

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

App Mesh configura il proxy Envoy per utilizzare un Unix Domain Socket 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 la variabile di ambiente. APPMESH_SDS_SOCKET_PATH

È possibile utilizzare qualsiasi implementazione collaterale di SDSAPI, incluse le toolchain esistenti come SPIFFERuntime Environment (). SPIRE SPIREè progettato per consentire l'implementazione dell'TLSautenticazione reciproca tra più carichi di lavoro in sistemi distribuiti. Attesta l'identità dei carichi di lavoro in fase di esecuzione. SPIREfornisce 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 come provider per EnvoySPIRE. SDS Consentitegli di fornire direttamente a Envoy il materiale chiave di cui ha bisogno per fornire l'autenticazione reciproca. TLS Esegui SPIRE gli agenti 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 esposto dall'agente. SDS 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.

Quando una policy client impone l'uso di TLS e una delle porte nella policy client corrisponde alla porta della policy del server, la policy client viene utilizzata per configurare il contesto di TLS convalida del client. Ad esempio, se la politica client di un gateway virtuale corrisponde alla politica del server di un nodo virtuale, verrà tentata la TLS negoziazione 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, è possibile negoziare o meno TLS tra i proxy, a seconda delle impostazioni della politica del server. TLS

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 TLS o meno con il client e come. Ad esempio, se un gateway virtuale non ha specificato una policy client e un nodo virtuale non ha configurato la TLS terminazione, non TLS verrà negoziata tra i proxy. Se un client non ha specificato una politica client corrispondente e un server è stato configurato con TLS modalità STRICT oPERMISSIVE, i proxy verranno configurati per la negoziazione. TLS A seconda del modo in cui i certificati sono stati forniti per la TLS terminazione, si applica il seguente comportamento aggiuntivo.

Facoltativamente, puoi specificare un elenco di nomi alternativi dei soggetti (SANs) di cui fidarti. SANsdeve essere nel URI formato FQDN o. Se SANs forniti, Envoy verifica che il nome alternativo del soggetto del certificato presentato corrisponda a uno dei nomi in questo elenco.

Se non lo specifichi SANs sull'endpoint mesh di terminazione, il proxy Envoy per quel nodo non verifica il certificato su un client peer. SAN Se non lo specifichi SANs sull'endpoint mesh di origine, il certificato fornito dall'endpoint terminante deve corrispondere alla configurazione di rilevamento del servizio di endpoint mesh. SAN

Per ulteriori informazioni, consulta App Mesh TLS: requisiti del certificato.