TLSAutenticazione reciproca - AWS App Mesh
Certificati di autenticazione reciproca TLSConfigura gli endpoint meshMigra i servizi all'autenticazione reciproca TLSVerifica dell'autenticazione reciproca TLSProcedure dettagliate per l'TLSautenticazione reciproca di 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à.

TLSAutenticazione reciproca

Importante

Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post del blog Migrazione da AWS App Mesh ad Amazon ECS Service Connect.

L'autenticazione reciproca TLS (Transport Layer Security) è un componente opzionale TLS che offre l'autenticazione peer bidirezionale. TLSL'autenticazione reciproca aggiunge un livello di sicurezza TLS e consente ai servizi di verificare il client che effettua la connessione.

Il client nella relazione client-server fornisce anche un certificato X.509 durante il processo di negoziazione della sessione. Il server utilizza questo certificato per identificare e autenticare il client. Questo processo consente di verificare se il certificato è emesso da un'autorità di certificazione (CA) affidabile e se il certificato è valido. Utilizza inoltre il Subject Alternative Name (SAN) sul certificato per identificare il client.

È possibile abilitare TLS l'autenticazione reciproca per tutti i protocolli supportati da AWS App Mesh. SonoTCP, HTTP /1.1, HTTP /2, g. RPC

Nota

Utilizzando App Mesh, puoi configurare TLS l'autenticazione reciproca per le comunicazioni tra i proxy Envoy dei tuoi servizi. Tuttavia, le comunicazioni tra le applicazioni e i proxy Envoy non sono crittografate.

Certificati di autenticazione reciproca TLS

AWS App Mesh supporta due possibili fonti di certificati per l'TLSautenticazione reciproca. I certificati client in una TLS Client Policy e la convalida del server in una TLS configurazione listener possono provenire da:

  • File system: certificati dal file system locale del proxy Envoy in esecuzione. Per distribuire i certificati a Envoy, devi fornire i percorsi dei file per la catena di certificati e la chiave privata per l'App Mesh. API

  • Envoy's Secret Discovery Service (SDS): Bring-your-own sidecar che implementano SDS e consentono l'invio di certificati a Envoy. Includono il Runtime Environment (). SPIFFE SPIRE

Importante

App Mesh non archivia i certificati o le chiavi private utilizzate per TLS l'autenticazione reciproca. Invece, Envoy li archivia in memoria.

Configura gli endpoint mesh

Configura TLS l'autenticazione reciproca per gli endpoint mesh, come nodi o gateway virtuali. Questi endpoint forniscono certificati e specificano autorità affidabili.

A tale scopo, è necessario fornire certificati X.509 sia per il client che per il server e definire esplicitamente i certificati di autorità attendibili nel contesto di convalida sia della terminazione che dell'origine. TLS TLS

Fiducia all'interno di una rete

I certificati lato server sono configurati nei listener Virtual Node (TLSterminazione) e i certificati lato client sono configurati nei backend del servizio Virtual Nodes (origine). TLS In alternativa a questa configurazione, è possibile definire una politica client predefinita per tutti i servizi di backend di un nodo virtuale e quindi, se necessario, sovrascrivere questa politica per backend specifici in base alle esigenze. I gateway virtuali possono essere configurati solo con una politica client predefinita che si applica a tutti i relativi backend.

È possibile configurare la fiducia tra diverse mesh abilitando TLS l'autenticazione reciproca per il traffico in entrata sui gateway virtuali per entrambe le mesh.

Fiducia al di fuori di una rete

Specificate i certificati lato server nel listener Virtual Gateway per la terminazione. TLS Configura il servizio esterno che comunica con il tuo Virtual Gateway per presentare certificati lato client. I certificati devono essere derivati da una delle stesse autorità di certificazione (CAs) utilizzate dai certificati lato server sul listener Virtual Gateway per l'origine. TLS

Migra i servizi all'autenticazione reciproca TLS

Segui queste linee guida per mantenere la connettività durante la migrazione dei servizi esistenti all'interno di App Mesh all'TLSautenticazione reciproca.

Servizi di migrazione che comunicano tramite testo non crittografato

  1. Abilita PERMISSIVE la modalità per la TLS configurazione sull'endpoint del server. Questa modalità consente al traffico in testo semplice di connettersi all'endpoint.

  2. Configura TLS l'autenticazione reciproca sul tuo server, specificando il certificato del server, la catena di fiducia e, facoltativamente, il certificato affidabile. SANs

  3. Conferma che la comunicazione avvenga tramite una TLS connessione.

  4. Configura TLS l'autenticazione reciproca sui tuoi client, specificando il certificato del client, la catena di fiducia e, facoltativamente, il certificato affidabile. SANs

  5. Abilita STRICT la modalità per la TLS configurazione sul server.

Servizi di migrazione che comunicano tramite TLS

  1. Configura le TLS impostazioni reciproche sui tuoi client, specificando il certificato del client e, facoltativamente, il certificato affidabile. SANs Il certificato client viene inviato al suo backend solo dopo che il server di backend lo richiede.

  2. Configura le TLS impostazioni reciproche sul tuo server, specificando la catena di fiducia e, facoltativamente, quella affidabile. SANs A tal fine, il server richiede un certificato client.

Verifica dell'autenticazione reciproca TLS

Puoi fare riferimento alla documentazione sulla crittografia Transport Layer Security: Verify per vedere esattamente in che modo Envoy emette TLS le statistiche relative alla crittografia. Per l'TLSautenticazione reciproca, è necessario controllare le seguenti statistiche:

  • ssl.handshake

  • ssl.no_certificate

  • ssl.fail_verify_no_cert

  • ssl.fail_verify_san

I due esempi di statistiche seguenti mostrano insieme che le TLS connessioni riuscite che terminano verso il nodo virtuale hanno tutte avuto origine da un client che ha fornito un certificato.

listener.0.0.0.0_15000.ssl.handshake: 3
listener.0.0.0.0_15000.ssl.no_certificate: 0

Il prossimo esempio di statistica mostra che le connessioni da un nodo client virtuale (o gateway) a un nodo virtuale di backend non sono riuscite. Il nome alternativo del soggetto (SAN) presentato nel certificato del server non corrisponde a nessuno dei nomi SANs considerati attendibili dal client.

cluster.cds_egress_my-mesh_my-backend-node_http_9080.ssl.fail_verify_san: 5

Procedure dettagliate per l'TLSautenticazione reciproca di App Mesh