Sicurezza dei servizi

Questo documento fornisce una panoramica della sicurezza dei servizi con Cloud Service Mesh. È destinata agli utenti di Cloud Service Mesh che vogliono aggiungere autenticazione, crittografia e autorizzazione ai propri deployment. Questo documento presuppone che tu abbia familiarità con la panoramica di Cloud Service Mesh e con le applicazioni gRPC senza proxy.

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

  • Autenticazione e crittografia che utilizzano Transport Layer Security (TLS) e mutual TLS (mTLS) sia per Cloud Service Mesh con Envoy sia per Cloud Service Mesh con applicazioni gRPC senza proxy. Le policy TLS client e le policy TLS server controllano se i servizi devono dimostrare le proprie identità l'uno all'altro e utilizzare canali di comunicazione criptati.
  • Autorizzazione, in base alle caratteristiche del client e della richiesta. Le policy di autorizzazione controllano se un servizio è autorizzato ad accedere a un altro servizio e quali azioni sono consentite.

L'utilizzo di certificati e chiavi forniti da un'autorità di certificazione (CA) privata, Certificate Authority Service di Google, semplifica la gestione della sicurezza dei servizi. Certificate Authority Service fornisce certificati mesh GKE. La funzionalità dei certificati mesh GKE e Cloud Service Mesh ti consentono di eseguire automaticamente il deployment di questi certificati e di utilizzarli per i workload. Modifichi i pod per consentire ai workload di ricevere e utilizzare le credenziali mTLS. La sicurezza dei servizi Cloud Service Mesh è attualmente disponibile solo per i workload basati su GKE.

Nelle moderne architetture basate su microservizi, servizi più piccoli e mirati sostituiscono le grandi applicazioni monolitiche. Le chiamate di servizio comunicano tra loro tramite la rete. Queste chiamate, che erano chiamate in-process nelle applicazioni monolitiche, presentano sfide di sicurezza, quindi è meglio autenticarle, criptarle e autorizzarle. Questi passaggi supportano il principio Zero Trust, in base al quale si presume che tutto il traffico di rete sia a rischio, indipendentemente dal fatto che 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. È il piano dati che gestisce questa complessità. Oltre a ridurre la complessità delle applicazioni, il pattern di progettazione del mesh di servizi consente di utilizzare pattern di sicurezza che altrimenti potrebbero essere difficili da implementare e gestire.

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

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 mesh.
  • Rotazione automatica di chiavi e certificati per fornire un ulteriore livello di sicurezza.
  • Integrazione con Google Kubernetes Engine (GKE) per utilizzare tutte le sue funzionalità, come i descrittori di deployment e le etichette.
  • Alta affidabilità dei servizi gestiti da Google, tra cui Cloud Service Mesh e i pool di autorità di certificazione private gestiti da Certificate Authority Service.
  • Sicurezza legata a Google Identity and Access Management (IAM): autorizzazione del servizio basata su service account Google autorizzati.
  • Interoperabilità perfetta con i workload basati su Envoy e senza proxy. Ad esempio, un servizio può trovarsi dietro un proxy Envoy, ma il client utilizza la sicurezza del mesh di servizi gRPC senza proxy. Al contrario, un servizio può essere protetto dalla sicurezza del mesh di servizi gRPC senza proxy, ma il client utilizza un proxy Envoy.

Comunicazioni sicure tra servizi

Cloud Service Mesh fornisce l'autorizzazione e la sicurezza tra servizi con crittografia e autenticazione che utilizzano TLS. Le policy TLS del client e del server consentono ai servizi di:

  • Affermare e convalidare le proprie identità.
  • Criptare 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 adottare disposizioni speciali per essere sicure.

Le policy di autorizzazione ti consentono di negare o consentire l'accesso in base alle regole che definisci.

Utilizza TLS per la crittografia

Quando un servizio chiama un altro servizio utilizzando il protocollo HTTP, HTTP/2 o gRPC, il traffico che transita sulla rete è in testo normale. Questo traffico potrebbe essere soggetto ad attacchi manipulator-in-the-middle(MITM), in cui un malintenzionato intercetta il traffico e ne ispeziona o manipola i contenuti.

Per mitigare 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 utilizzando TLS basato sul certificato del server. Il traffico non è più in testo normale, il che riduce la probabilità che un malintenzionato possa intercettare e ispezionare o manipolare i suoi contenuti.

Utilizza TLS per l'autenticazione

Quando un servizio chiama un altro servizio, considera le seguenti domande:

  • Come fa un client a sapere che sta ricevendo una risposta dal server corretto anziché 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 malintenzionato intercetta questo traffico? Ad esempio, il traffico HTTP non è criptato, quindi chiunque lo riceva può ispezionarne i contenuti. Questo è noto come attacco manipulator-in-the-middle.

Per mitigare 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 server per dimostrare la propria identità al client. Le richieste e le risposte vengono poi criptate utilizzando 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 over TLS, che non si basa sull'autenticazione reciproca, il server dispone di un certificato che utilizza 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 il TLS handshake. Tuttavia, il server non verifica l'identità del client.

Quando l'autenticazione reciproca è abilitata, anche il client ha 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 client che quelli server vengono utilizzati per criptare il canale di comunicazione. In questo modo, il server può anche autorizzare i client in base all'identità client verificata.

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

Autorizza le chiamate di servizio

Puoi scegliere di consentire o negare l'accesso ai servizi utilizzando le policy di autorizzazione. Utilizzando Cloud Service Mesh, puoi definire 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 livello 7, tra cui l'ID client, derivato da client-cert in una connessione mTLS, l'indirizzo IP di origine, la corrispondenza dell'host, la corrispondenza del metodo e la corrispondenza dell'intestazione. Il seguente diagramma mostra l'autorizzazione con i proxy Envoy. La procedura è simile con i client gRPC.

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

Limita l'accesso utilizzando l'autorizzazione

Una best practice all'interno di un mesh di servizi consiste nell'adottare 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 policy di autorizzazione che consentono al tuo piano dati di consentire o negare l'accesso ai servizi in base alle regole che definisci. Queste policy sono costituite da due componenti:

  • Un'azione: consenti o nega
  • 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 con una regola. Se viene trovata una corrispondenza, la richiesta o l'RPC viene consentita o negata. Puoi definire una regola per la corrispondenza di attributi come i seguenti:

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

Denominazione sicura

Come meccanismo di sicurezza aggiuntivo, puoi configurare la denominazione sicura con Cloud Service Mesh. In questo modo puoi definire un elenco di nomi consentiti o identità SPIFFE (Secure Production Identity Framework for Everyone) per un determinato 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 quindi esamina 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 Everyone.

Proteggi il traffico in un gateway

Per configurare i gateway, puoi utilizzare Cloud Service Mesh. Un gateway è un proxy Envoy autonomo che in genere funge da:

  • Un gateway in entrata che gestisce il traffico che entra in un 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 reverse proxy o un proxy intermedio che distribuisce il traffico in entrata tra uno o più servizi

I client che vogliono inviare traffico all'interno o all'esterno del mesh inviano il traffico al gateway. Il gateway gestisce quindi le richieste in base alle regole che hai configurato con Cloud Service Mesh. Ad esempio, puoi imporre che il traffico che entra nel mesh (tramite il gateway in entrata) venga criptato utilizzando TLS.

Componenti di sicurezza

La sicurezza dei servizi Cloud Service Mesh supporta le policy TLS client, le policy TLS server e le policy di autorizzazione. Puoi creare queste policy in modo che Cloud Service Mesh possa configurare il piano dati e attivare le funzionalità di sicurezza. Per creare o aggiornare queste policy, non è necessario apportare modifiche alle applicazioni.

Crittografia e modalità di autenticazione supportate

Quando un servizio chiama un altro servizio, il primo passaggio per stabilire comunicazioni sicure consiste nel fare in modo che ogni servizio dimostri la propria identità all'altro servizio. Il grado di necessità di un servizio di dimostrare la propria identità si basa sulla modalità TLS configurata.

Puoi configurare i seguenti livelli di sicurezza:

  • Non criptato/non autenticato
  • TLS
  • Mutual TLS (mTLS)
  • Permissiva: mTLS o non criptata/non autenticata, a seconda di come il client avvia la connessione

Certificati e autorità di certificazione

I certificati e un'autorità di certificazione (CA) attendibile costituiscono la base per la fiducia in un sistema distribuito come un mesh di servizi. Utilizzando i certificati, i servizi possono dimostrare le proprie identità e verificare quelle presentate nei seguenti modi:

  • Un servizio che vuole dimostrare la propria identità a un altro servizio presenta il proprio certificato all'altro servizio. Una CA considerata attendibile da entrambi i servizi firma e rilascia questo certificato in modo crittografico.
  • Il servizio che riceve questo certificato può verificare che il certificato provenga da una CA attendibile.

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

  • Esegue il provisioning di identità e certificati
  • Rende i certificati disponibili ai client Cloud Service Mesh, come i proxy Envoy, configurati da Cloud Service Mesh

Cloud Service Mesh supporta Certificate Authority Service di Google. Le guide alla configurazione per Envoy e gRPC senza proxy includono istruzioni per la configurazione (per maggiori dettagli, consulta Passaggi successivi).

Architettura e risorse

Cloud Service Mesh include lo spazio dei nomi dell'API Sicurezza di rete, che è composto da tre risorse API Google Cloud che ti consentono di specificare le policy di sicurezza da applicare al piano dati.

Due risorse API Google Cloud supportano l'autenticazione nel mesh: le policy TLS client e le policy TLS server. Una terza risorsa, la policy di autorizzazione, supporta l'autorizzazione.

Lo spazio dei nomi dell'API Network Services include la risorsa della policy endpoint, che consente a Cloud Service Mesh di fornire la configurazione (TLS server, TLS client e policy 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.

Policy TLS del client

Una policy TLS del client ti consente di specificare la modalità TLS lato client e le informazioni del provider di certificati da applicare al tuo piano dati. Le policy TLS client supportano l'autenticazione TLS e mTLS. Le policy TLS del client devono essere collegate a una risorsa del servizio di backend globale.

Quando configuri TLS, devi fornire un meccanismo con cui 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 che può utilizzare per convalidare il certificato del server.

Quando configuri mTLS, devi anche fornire un meccanismo tramite 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 il TLS handshake.

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

Policy TLS del server

Una policy TLS del server (risorsa ServerTlsPolicy) consente di specificare la modalità TLS lato server e le informazioni del provider di certificati da applicare al piano dati. Le policy TLS del server supportano l'autenticazione TLS, mTLS e, solo con Envoy, Open_or_mTLS. Puoi collegare le policy TLS del server a una risorsa della policy endpoint.

Nomi alternativi dell'oggetto

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

Policy di autorizzazione

Una policy di autorizzazione (risorsa AuthorizationPolicy) specifica in che modo un server autorizza le richieste o le RPC in entrata. Può essere configurato per consentire o negare una richiesta o una RPC in entrata in base a vari parametri, come l'identità del client che ha inviato la richiesta, l'host, le intestazioni e altri attributi HTTP. Puoi collegare le policy di autorizzazione a una risorsa della policy degli endpoint.

Una regola della policy di autorizzazione è costituita dai seguenti componenti:

  • from: specifica l'identità del client consentito dalla regola. L'identità può essere derivata da un certificato client in una connessione mutual TLS o può essere l'identità ambientale associata alla VM client, ad esempio da un account di servizio o da un tag sicuro.
  • to: specifica le operazioni consentite dalla regola, ad esempio gli URL a cui è possibile accedere o i metodi HTTP consentiti.
  • when: consente di definire vincoli aggiuntivi che devono essere soddisfatti. Per definire i vincoli, puoi utilizzare le espressioni Common Expression Language (CEL).
  • action: specifica l'azione della regola. Può essere uno dei seguenti: ALLOW, DENY o CUSTOM.

Limitazioni

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

Quando valuta una richiesta, una policy di autorizzazione esegue una delle seguenti azioni:

  • ALLOW: concede l'accesso alla risorsa richiesta se la richiesta corrisponde alle regole definite all'interno della policy di autorizzazione. La policy di autorizzazione blocca l'accesso alla risorsa richiesta se la richiesta non corrisponde ad alcuna regola definita all'interno della policy di autorizzazione. Una richiesta viene negata se non corrisponde a una policy ALLOW, anche se altre policy la consentono.

  • DENY: blocca l'accesso alla risorsa se una richiesta corrisponde a una delle regole specificate all'interno di una policy DENY. La policy di autorizzazione concede l'accesso alla risorsa richiesta se la richiesta non corrisponde a nessuna regola definita all'interno della policy di autorizzazione. Una richiesta viene rifiutata se corrisponde a una policy DENY, anche se altre policy la consentono.

  • CUSTOM (non supportato in Cloud Service Mesh): consente l'integrazione con sistemi di autorizzazione esterni per decisioni di autorizzazione complesse. Le azioni CUSTOM vengono utilizzate per le policy che utilizzano le estensioni dei servizi per le decisioni di autorizzazione.

Ordine di valutazione delle policy di autorizzazione

Quando a una singola risorsa sono associate più policy di autorizzazione, queste vengono valutate nel seguente ordine per determinare se una richiesta è consentita o negata.

  1. Policy con azioni CUSTOM: se la policy CUSTOM nega la richiesta, questa viene rifiutata immediatamente. Le policy DENY o ALLOW non vengono valutate, anche se sono configurate.

  2. Policy con azioni DENY: se una policy DENY corrisponde alla richiesta, la richiesta viene rifiutata. Le policy ALLOW non vengono valutate, anche se sono configurate.

  3. Policy con azioni ALLOW: se non sono presenti policy ALLOW o se una policy ALLOW corrisponde alla richiesta, la richiesta viene consentita. Tuttavia, se nessuna policy ALLOW corrisponde alla richiesta, questa viene rifiutata.

Limitazioni con applicazioni gRPC senza proxy

La sicurezza dei servizi gRPC senza proxy presenta le seguenti limitazioni:

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

Quote di AuthzPolicy

  • Puoi avere un massimo di 5 policy di autorizzazione per gateway.
  • Puoi avere un massimo di 20 risorse AuthzPolicy per progetto.
  • Una singola risorsa AuthzPolicy può puntare a un massimo di 100 gateway.

Passaggi successivi