Sicurezza dei servizi (legacy)

Questo documento fornisce una panoramica della sicurezza dei servizi con Cloud Service Mesh utilizzando le API di bilanciamento del carico. È destinato agli utenti di Cloud Service Mesh che desiderano aggiungere autenticazione, crittografia e autorizzazione ai propri deployment. Questo documento presuppone che tu abbia familiarità con Cloud Service Mesh con Envoy e con le applicazioni gRPC senza proxy.

Questo documento riguarda le configurazioni che utilizzano le API di bilanciamento del carico. Se utilizzi le API di routing dei servizi, consulta Sicurezza dei servizi. Questo è un documento precedente.

Cloud Service Mesh ti consente di proteggere le comunicazioni tra servizi nella tua rete mesh. Nella rete mesh, ogni servizio ha un'identità. Le seguenti funzionalità contribuiscono a supportare le comunicazioni sicure:

  • Autenticazione e crittografia che utilizzano TLS (Transport Layer Security) e TLS reciprocamente (mTLS) sia per Cloud Service Mesh con Envoy che per Cloud Service Mesh con applicazioni gRPC senza proxy. I criteri TLS del client e i criteri TLS del server controllano se i servizi devono dimostrare le loro identità tra loro e utilizzare canali di comunicazione criptati.
  • Autorizzazione, basata sulle caratteristiche del cliente e della richiesta. I criteri di autorizzazione controllano se un servizio può accedere a un altro servizio e quali azioni sono consentite.

L'utilizzo di certificati e chiavi forniti da un'autorità di certificazione (CA) privata, il Certificate Authority Service di Google, semplifica la gestione della sicurezza dei servizi. CA Service fornisce certificati mesh GKE. La funzionalità dei certificati mesh GKE e Cloud Service Mesh consentono di eseguire automaticamente il deployment di questi certificati e fare in modo che i carichi di lavoro li utilizzino. Puoi modificare i pod per consentire ai carichi di lavoro di ricevere e utilizzare le credenziali mTLS. La sicurezza del servizio Cloud Service Mesh è disponibile solo per i carichi di lavoro basati su GKE.

Nelle moderne architetture basate su microservizi, i servizi più piccoli e più mirati sostituiscono le grandi applicazioni monolitiche. Le chiamate ai servizi comunicano tra loro sulla rete. Queste chiamate, che erano chiamate in-process in applicazioni monolitiche, presentano difficoltà di sicurezza, perciò è preferibile autenticarle, criptarle e autorizzarle. Questi passaggi supportano il principio Zero Trust, in base al quale si presuppone che tutto il traffico di rete sia a rischio, indipendentemente dal fatto che il traffico abbia origine all'interno o all'esterno della rete.

Il pattern di progettazione del mesh di servizi separa qualsiasi complessità relativa alle comunicazioni tra servizi dalla logica di business. È invece il piano dati che gestisce questa complessità. Oltre a ridurre la complessità delle applicazioni, il pattern di progettazione della mesh di servizi consente pattern di sicurezza che altrimenti sarebbero difficili da implementare e gestire.

In questo modello, i sidecar gRPC o Envoy senza proxy autenticano e criptano in modo sicuro le comunicazioni ottenendo informazioni di configurazione da Cloud Service Mesh e certificati da un pool di servizi CA.

Queste funzionalità di sicurezza semplificano il processo di deployment di Cloud Service Mesh fornendo quanto segue:

  • Provisioning automatico di chiavi e certificati per tutti i servizi nel tuo mesh.
  • Rotazione automatica di chiavi e certificati per maggiore sicurezza.
  • Integrazione con Google Kubernetes Engine (GKE) per utilizzare tutte le sue funzionalità, come descrittori ed etichette del deployment.
  • Alta disponibilità dei servizi gestiti Google, tra cui Cloud Service Mesh e CA Service gestiti da pool di autorità di certificazione.
  • Sicurezza associata a Google Identity and Access Management (IAM): autorizzazione del servizio basata sugli account di servizio Google autorizzati.
  • Interoperabilità perfetta con i tuoi carichi di lavoro basati su Envoy e senza proxy. Ad esempio, un servizio può essere dietro un proxy Envoy, ma il client utilizza la sicurezza del mesh di servizi senza proxy gRPC. Al contrario, un servizio può trovarsi dietro la sicurezza del mesh di servizi senza proxy gRPC, ma il client utilizza un proxy Envoy.

Comunicazioni tra servizi sicure

Cloud Service Mesh fornisce l'autorizzazione e la sicurezza service-to-service con crittografia e autenticazione che utilizzano TLS. I criteri TLS del client e i criteri TLS del server consentono ai servizi di:

  • Rivendicare e convalidare le loro identità.
  • Cripta le sessioni di comunicazione utilizzando TLS o mTLS.

In un mesh di servizi, il piano dati gestisce questo tipo di sicurezza in modo che le applicazioni non debbano prevedere disposizioni speciali per garantire la sicurezza.

I criteri di autorizzazione ti consentono di negare o consentire l'accesso in base a regole da te definite.

Usa TLS per la crittografia

Quando un servizio effettua chiamate a un altro servizio utilizzando il protocollo HTTP, HTTP/2 o gRPC, il traffico che transita nella rete è in testo normale. Questo traffico potrebbe essere soggetto ad attacchi person in the middle, nei quali un utente malintenzionato intercetta il traffico e ispeziona o manipola i contenuti.

Per ridurre questo potenziale problema, puoi utilizzare HTTP, HTTP/2 o gRPC su TLS con Cloud Service Mesh. Quando utilizzi questi protocolli su TLS, il traffico tra il client e il server viene criptato tramite il protocollo TLS basato sul certificato del server. Il traffico non è più in testo normale, riducendo la probabilità che un utente malintenzionato possa intercettare e ispezionare o manipolare i contenuti.

Utilizza TLS per l'autenticazione

Quando un servizio chiama su un altro servizio, poniti le seguenti domande:

  • Come fa il client a sapere di ricevere una risposta dal server corretto e non da un impostore? Ad esempio, in una tipica interazione richiesta-risposta basata su HTTP, il client non verifica l'identità del server.

  • Cosa succede se un aggressore intercetta questo traffico? Ad esempio, il traffico HTTP non è criptato, quindi chiunque lo riceva può esaminarne i contenuti. Si tratta di un attacco person in the middle.

Per limitare questi problemi, puoi utilizzare HTTP, HTTP/2 e gRPC su TLS. In questi scambi tra un client e un server, il server deve utilizzare un certificato del server per dimostrare la propria identità al client. Le richieste e le risposte vengono quindi criptate tramite TLS.

Autenticazione TLS reciproca

Quando Cloud Service Mesh configura il networking delle applicazioni sia per il client che per il server, ad esempio configurando un proxy Envoy sul lato client e un altro proxy Envoy sul lato server, puoi sfruttare pattern di autenticazione avanzati come l'autenticazione reciproca.

In un tipico scambio HTTP su TLS, che non è basato sull'autenticazione reciproca, il server dispone di un certificato che viene utilizzato per criptare le comunicazioni tra il client e il server. Il client può verificare l'identità del server controllando la firma che il server invia durante l'handshake TLS. Tuttavia, il server non verifica l'identità del client.

Quando l'autenticazione reciproca è abilitata, il client ha anche un certificato. Il client verifica l'identità del server, come descritto nel paragrafo precedente, e il server può anche verificare l'identità del client. Sia i certificati del client che del server vengono utilizzati per criptare il canale di comunicazione. Inoltre, il server può autorizzare i client in base alla loro identità verificata.

Autenticazione TLS (mTLS) reciproca in un mesh di servizi.
Autenticazione TLS reciproca (mTLS) in un mesh di servizi (fai clic per ingrandire)

Autorizza chiamate di servizio

Puoi scegliere di consentire o negare l'accesso al servizio utilizzando i criteri di autorizzazione. Utilizzando Cloud Service Mesh, puoi definire le regole di autorizzazione e negazione per autorizzare l'accesso in base ai parametri della richiesta. Puoi basare queste regole sui parametri di livello 3 e 7, incluso l'ID client, che deriva da client-cert in una connessione mTLS, indirizzo IP di origine, corrispondenza dell'host, corrispondenza del metodo e corrispondenza dell'intestazione. Il seguente diagramma mostra l'autorizzazione con i proxy Envoy. Il processo è simile per i client gRPC.

Autorizzazione in un mesh di servizi.
Autorizzazione in un mesh di servizi che utilizza Envoy (fai clic per ingrandire)

Limitare l'accesso tramite l'autorizzazione

Una best practice all'interno di un mesh di servizi consiste nel rispettare il principio del privilegio minimo. Puoi rispettare questo principio limitando l'accesso al servizio solo ai chiamanti che dipendono dal servizio. Quando un chiamante tenta di accedere a un servizio per il quale non è autorizzato, il tentativo viene rifiutato.

Con Cloud Service Mesh, puoi configurare criteri di autorizzazione che consentono al tuo piano dati di consentire o negare l'accesso ai servizi in base a regole che definisci. Questi criteri sono costituiti da due componenti:

  • Un'azione: consentire o negare
  • Un elenco di regole

Quando viene inviata una richiesta o una RPC, il client Cloud Service Mesh sul servizio chiamato determina se esiste una corrispondenza di regola. Se viene trovata una corrispondenza, la richiesta o RPC viene consentita o negata. Puoi definire una regola per trovare corrispondenze con attributi quali:

  • Quando si utilizza mTLS, l'account di servizio Kubernetes del servizio chiamante
  • L'indirizzo IP (o intervallo di indirizzi) del servizio chiamante
  • Le porte del servizio di destinazione
  • Gli attributi HTTP della richiesta, tra cui nomi host, metodi e intestazioni HTTP definite dall'utente.

Denominazione sicura

Come meccanismo di sicurezza aggiuntivo, puoi configurare una denominazione sicura con Cloud Service Mesh. Ciò consente di definire un elenco di nomi consentiti, o identità SPIFFE (Secure Production Identity Framework for Tutti), per un particolare servizio a cui un client sta tentando di connettersi. Durante lo scambio TLS, il backend del servizio restituisce un certificato X.509 al client. Il client ispeziona quindi il certificato per confermare che il certificato X.509 corrisponda a uno dei nomi o delle identità SPIFFE. Per ulteriori informazioni sulle identità SPIFFE, consulta Secure Production Identity Framework for Tutti.

Proteggere il traffico a un gateway

Per configurare i tuoi gateway, puoi utilizzare Cloud Service Mesh. Un gateway è un proxy Envoy autonomo che generalmente agisce come uno dei seguenti:

  • Un gateway in entrata che gestisce il traffico che entra in una rete mesh o in un altro dominio.
  • Un gateway in uscita che gestisce il traffico in uscita da un mesh o da un altro dominio
  • Un proxy inverso o centrale che distribuisce il traffico in entrata tra uno o più servizi

I client che vogliono inviare traffico al mesh o fuori dal mesh lo inviano al gateway. Il gateway gestisce quindi le richieste in base alle regole configurate con Cloud Service Mesh. Ad esempio, puoi imporre che il traffico in entrata nella rete mesh (sebbene il gateway in entrata) debba essere criptato tramite TLS.

Componenti di sicurezza

La sicurezza del servizio Cloud Service Mesh supporta i criteri TLS del client, i criteri TLS del server e i criteri di autorizzazione. Questi criteri vengono creati in modo che Cloud Service Mesh possa configurare il piano dati e abilitare funzionalità di sicurezza. Per creare o aggiornare questi criteri, non è necessario apportare modifiche alle applicazioni.

Crittografia e modalità di autenticazione supportate

Quando un servizio effettua chiamate a un altro servizio, il primo passo per stabilire comunicazioni sicure consiste nel verificare la propria identità da parte di ciascun servizio all'altro servizio. Il grado in cui un servizio ha bisogno di dimostrare la propria identità dipende dalla modalità TLS che configuri.

Puoi configurare i seguenti livelli di sicurezza:

  • Non criptato/non autenticato
  • TLS
  • TLS reciproco (mTLS)
  • Permissivo: mTLS o non criptato/non autenticato, a seconda di come il client avvia la connessione

Certificati e autorità di certificazione

I certificati e un'autorità di certificazione (CA) attendibile forniscono le basi per l'attendibilità in un sistema distribuito come un mesh di servizi. Utilizzando i certificati, i servizi possono dimostrare la propria identità e verificare le identità presentate nei seguenti modi:

  • Un servizio che vuole dimostrare la propria identità a un altro servizio presenta il certificato all'altro servizio. Una CA considerata attendibile da entrambi i servizi firma ed emette questo certificato in modo crittografico.
  • Il servizio che riceve questo certificato può verificare che il certificato abbia avuto origine da una CA che considera attendibile.

Cloud Service Mesh non è un'autorità di certificazione. Per abilitare comunicazioni sicure, devi configurare un meccanismo che:

  • Esegue il provisioning di identità e certificati
  • Rende i certificati disponibili per i client Cloud Service Mesh, come i proxy Envoy, che Cloud Service Mesh configura

Cloud Service Mesh supporta il servizio CA di Google. Le guide alla configurazione per Envoy e gRPC senza proxy includono istruzioni per la configurazione (per i dettagli, consulta la sezione Passaggi successivi).

Architettura e risorse

Cloud Service Mesh include lo spazio dei nomi dell'API Network Security, composto da tre risorse API Google Cloud che consentono di specificare i criteri di sicurezza da applicare al piano dati.

Due risorse API Google Cloud supportano l'autenticazione nel mesh: i criteri TLS del client e i criteri TLS del server. Una terza risorsa, il criterio di autorizzazione, supporta l'autorizzazione.

Lo spazio dei nomi dell'API Network Services include la risorsa dei criteri degli endpoint, che consente a Cloud Service Mesh di fornire la configurazione (TLS del server, TLS del client e criteri di autorizzazione) agli endpoint. Gli endpoint sono i client Cloud Service Mesh che terminano una comunicazione in entrata da un altro client Cloud Service Mesh.

Per abilitare il servizio di sicurezza, utilizza il proxy HTTPS di destinazione o il proxy gRPC di destinazione nel deployment. Non puoi utilizzare il proxy HTTP di destinazione o il proxy TCP di destinazione.

Criterio TLS del client

Un criterio TLS del client consente di specificare la modalità TLS lato client e le informazioni sul fornitore di certificati da applicare al piano dati. I criteri TLS del client supportano l'autenticazione TLS e mTLS. I criteri TLS del client devono essere collegati a una risorsa del servizio di backend globale.

Quando configuri TLS, devi fornire un meccanismo mediante il quale il client convalida il certificato che riceve dal server durante lo scambio TLS utilizzando il campo API serverValidationCa. Il client utilizza queste informazioni per ottenere un certificato di convalida da utilizzare per convalidare il certificato del server.

Quando configuri mTLS, devi anche fornire un meccanismo mediante il quale il client ottiene il certificato e la chiave privata utilizzando il campo API clientCertificate. Il client utilizza queste informazioni per presentare un certificato al server durante l'handshake TLS.

In questa release, Cloud Service Mesh supporta un'autorità di certificazione gestita, CA Service. La configurazione è semplice: devi specificare il nome del plug-in google_cloud_private_spiffe quando configuri il fornitore del certificato. In questo modo i client xDS caricano certificati e chiavi da una posizione statica. Come prerequisiti, devi configurare i pool di servizi CA e abilitare i certificati mesh sul cluster GKE.

Criterio TLS del server

Un criterio TLS del server (risorsa ServerTlsPolicy) consente di specificare la modalità TLS lato server e le informazioni sul provider di certificati da applicare al piano dati. I criteri TLS del server supportano TLS, mTLS e, solo con Envoy, l'autenticazione Open_or_mTLS. I criteri TLS del server possono essere collegati alla risorsa proxy HTTPS di destinazione o a una risorsa dei criteri degli endpoint.

Nomi alternativi dei soggetti

Quando configuri il campo securitySettings di un servizio di backend globale, puoi fornire un elenco di nomi alternativi degli oggetti nel campo subjectAltNames. Quando un client avvia un handshake TLS con uno dei backend del servizio, il server presenta il proprio certificato X.509. Il client controlla il campo subjectAltName del certificato. Se il campo contiene uno dei valori specificati, la comunicazione continua. Questo meccanismo è descritto in precedenza in Nomi sicuri.

Criterio di autorizzazione

Un criterio di autorizzazione (risorsa AuthorizationPolicy) specifica in che modo un server autorizza le richieste in entrata o le RPC. Può essere configurato per consentire o negare una richiesta in arrivo o RPC in base a vari parametri, come l'identità del client che ha inviato la richiesta, l'host, le intestazioni e altri attributi HTTP. Un criterio di autorizzazione può essere collegato alla risorsa proxy HTTPS di destinazione o a una risorsa del criterio endpoint.

Limitazioni

La sicurezza del servizio Cloud Service Mesh è supportata solo con GKE. Non puoi eseguire il deployment della sicurezza dei servizi con Compute Engine.

Limitazioni con applicazioni gRPC senza proxy

La sicurezza dei servizi per i servizi gRPC senza proxy ha le seguenti limitazioni:

  • Questa release è limitata a Java, Python, C++ e Go.

Passaggi successivi