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à.
Autenticazione TLS 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 di blog Migrazione AWS App Mesh da Amazon ECS Service Connect.
L'autenticazione reciproca TLS (Transport Layer Security) è un componente opzionale di TLS che offre l'autenticazione peer bidirezionale. L'autenticazione TLS reciproca aggiunge un livello di sicurezza rispetto a 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 l'autenticazione TLS reciproca per tutti i protocolli supportati da AWS App Mesh. Sono TCP, HTTP/1.1, HTTP/2, gRPC.
Nota
Utilizzando App Mesh, puoi configurare l'autenticazione TLS 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 TLS reciproca
AWS App Mesh supporta due possibili fonti di certificati per l'autenticazione TLS reciproca. I certificati client in una politica client TLS e la convalida del server in una configurazione TLS del 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 all'API App Mesh.
-
Secret Discovery Service (SDS) di Envoy: Bring-your-own sidecar che implementano l'SDS e consentono l'invio di certificati a Envoy. Includono lo SPIFFE Runtime Environment (SPIRE).
Importante
App Mesh non archivia i certificati o le chiavi private utilizzati per l'autenticazione TLS reciproca. Invece, Envoy li archivia in memoria.
Configura gli endpoint mesh
Configura l'autenticazione TLS 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 in modo esplicito i certificati di autorità attendibili nel contesto di convalida sia della terminazione TLS che dell'origine TLS.
- Fiducia all'interno di una rete
-
I certificati lato server sono configurati nei listener Virtual Node (terminazione TLS) 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 l'autenticazione TLS 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 di TLS.
Migra i servizi all'autenticazione TLS reciproca
Segui queste linee guida per mantenere la connettività durante la migrazione dei servizi esistenti all'interno di App Mesh all'autenticazione TLS reciproca.
Servizi di migrazione che comunicano tramite testo non crittografato
-
Abilita
PERMISSIVEla modalità per la configurazione TLS sull'endpoint del server. Questa modalità consente al traffico in testo semplice di connettersi all'endpoint. -
Configura l'autenticazione TLS reciproca sul tuo server, specificando il certificato del server, la catena di fiducia e, facoltativamente, il certificato affidabile. SANs
-
Conferma che la comunicazione avvenga tramite una connessione TLS.
-
Configura l'autenticazione TLS reciproca sui tuoi client, specificando il certificato del client, la catena di fiducia e, facoltativamente, il certificato affidabile. SANs
-
Abilita
STRICTla modalità per la configurazione TLS sul server.
Servizi di migrazione che comunicano tramite TLS
-
Configura le impostazioni TLS reciproche sui tuoi client, specificando il certificato del client e, facoltativamente, il certificato affidabile. SANs Il certificato client viene inviato al backend solo dopo che il server di backend lo richiede.
-
Configura le impostazioni TLS 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 TLS reciproca
Puoi fare riferimento alla documentazione sulla crittografia Transport Layer Security: Verify per vedere in che modo esattamente Envoy emette le statistiche relative a TLS. Per l'autenticazione TLS 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 connessioni TLS 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 Subject Alternative Name (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'autenticazione TLS reciproca di App Mesh
-
Procedura dettagliata di autenticazione TLS reciproca
: questa procedura dettagliata descrive come utilizzare l'App Mesh CLI per creare un'app a colori con autenticazione TLS reciproca. -
Procedura dettagliata basata su Mutual TLS SDS di Amazon EKS: questa procedura dettagliata
mostra come utilizzare l'autenticazione reciproca basata su TLS SDS con Amazon EKS e SPIFFE Runtime Environment (SPIRE). -
Procedura dettagliata basata su file TLS reciproco di Amazon EKS: questa procedura dettagliata
mostra come utilizzare l'autenticazione reciproca basata su file TLS con Amazon EKS e SPIFFE Runtime Environment (SPIRE).
