Autenticazione TLS reciproca - AWS 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à.

Autenticazione TLS reciproca

L'autenticazione Mutual TLS (Transport Layer Security) è un componente opzionale di TLS che offre l'autenticazione peer bidirezionale. L'autenticazione TLS reciproca aggiunge un livello di sicurezza su TLS e consente ai servizi di verificare il client che sta effettuando 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 è rilasciato da un'autorità di certificazione attendibile (CA) e se il certificato è un certificato valido. Utilizza inoltre il nome alternativo del soggetto (SAN) sul certificato per identificare il client.

È possibile abilitare l'autenticazione TLS reciproca per tutti i protocolli supportati daAWS App Mesh. Sono TCP, HTTP/1.1, HTTP/2, gRPC.

Nota

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

Certificati TLS reciproca

AWS App Meshsupporta due possibili fonti di certificato per l'autenticazione TLS reciproca. I certificati client in un criterio client TLS e la convalida del server in una configurazione TLS del listener possono essere ricavati da:

  • File system—Certificati dal file system locale del proxy Envoy in esecuzione. Per distribuire i certificati a Envoy, è necessario fornire percorsi file per la catena di certificati e la chiave privata all'API App Mesh.

  • Servizio Secret Discovery Service (SDS) dell'inviato —Porta le tue sidecar che implementano SDS e consentono l'invio di certificati a Envoy. Includono SPIFFE Runtime Environment (SPIRE).

Importante

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

Configurare gli endpoint mesh

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

Per fare ciò, è necessario eseguire il provisioning dei 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 TLS che dell'origine TLS.

Fidati 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 dei servizi Nodi virtuali (origine TLS). In alternativa a questa configurazione, è possibile definire un criterio client predefinito per tutti i backend dei servizi di un nodo virtuale e quindi, se necessario, è possibile sovrascrivere questo criterio per backend specifici in base alle esigenze. I gateway virtuali possono essere configurati solo con un criterio client predefinito applicabile a tutti i back-end.

È possibile configurare l'attendibilità su diverse mesh abilitando l'autenticazione TLS reciproca per il traffico in entrata sui gateway virtuali per entrambe le mesh.

Fidati al di fuori di una rete

Specificare i certificati lato server nel listener Virtual Gateway per la terminazione di TLS. Configurare il servizio esterno che comunica con il gateway virtuale per presentare i certificati lato client. I certificati devono essere derivati da una delle stesse autorità di certificazione (CA) utilizzate dai certificati lato server sul listener Virtual Gateway per la creazione di TLS.

Migrazione dei 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.

Migrazione dei servizi che comunicano in testo semplice

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

  2. Configurare l'autenticazione TLS reciproca sul server, specificando il certificato del server, la catena di trust e, facoltativamente, le SAN attendibili.

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

  4. Configurare l'autenticazione TLS reciproca sui client, specificando il certificato client, la catena di fiducia e, facoltativamente, le SAN attendibili.

  5. Abilitazione diSTRICTmodalità per la configurazione TLS sul server.

Migrazione dei servizi che comunicano tramite TLS

  1. Configurare le impostazioni TLS reciproche sui client, specificando il certificato client e facoltativamente le SAN attendibili. Il certificato client non viene inviato al back-end fino a quando il server backend lo ha richiesto.

  2. Configurare le impostazioni TLS reciproche sul server, specificando la catena di fiducia e facoltativamente le SAN attendibili. Per questo, il server richiede un certificato client.

Verificare l'autenticazione TLS reciproca

È possibile fare riferimento alTransport Layer Security: Verificare la crittodocumentazione per vedere come Envoy emette esattamente le statistiche relative a TLS. Per l'autenticazione TLS reciproca, è necessario esaminare le seguenti statistiche:

  • ssl.handshake

  • ssl.no_certificate

  • ssl.fail_verify_no_cert

  • ssl.fail_verify_san

I due esempi seguenti di statistiche mostrano insieme che le connessioni TLS che terminano con il nodo virtuale hanno 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 backend non sono riuscite. Il nome alternativo del soggetto (SAN) presentato nel certificato del server non corrisponde a nessuna delle SAN attendibili dal client.

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

Procedura dettagliata dell'autenticazione TLS reciproca dell'App Mesh