Sicurezza del servizio
Questo documento fornisce una panoramica della sicurezza dei servizi con Cloud Service Mesh. È rivolto 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 da servizio a servizio nel tuo mesh. Nel mesh, ogni servizio ha un'identità. Le seguenti funzionalità aiutano per supportare comunicazioni sicure:
- Autenticazione e crittografia che utilizzano TLS (Transport Layer Security) e TLS (mTLS) reciproco sia per Cloud Service Mesh con Envoy che per Cloud Service Mesh con applicazioni gRPC senza proxy. Criteri TLS del client e criteri TLS del server controllare se i servizi devono dimostrare la propria identità tra loro e utilizzare a canali di comunicazione criptati.
- Autorizzazione, in base alle caratteristiche del client e della richiesta. I criteri di autorizzazione controllano se un servizio è autorizzato ad accedere a un altro servizio e quali azioni sono consentite.
Utilizzando certificati e chiavi forniti da un'autorità di certificazione privata (CA), Certificate Authority Service di Google, per permetterti di mantenere la sicurezza dei servizi. CA Service fornisce Certificati mesh GKE. La funzionalità dei certificati del mesh GKE e Cloud Service Mesh ti consentono di eseguire automaticamente il deployment di questi certificati e di utilizzarli per i carichi di lavoro. Modifica i pod per consentire ai carichi di lavoro di ricevere e utilizzare le credenziali mTLS. Servizio Cloud Service Mesh la sicurezza è attualmente disponibile solo per i carichi di lavoro basati su GKE.
Nelle architetture moderne basate su microservizi, servizi più piccoli e mirati sostituiscono le grandi applicazioni monolitiche. Le chiamate di servizio comunicano tra loro sulla rete. Queste chiamate, che erano chiamate in-process in un ambiente applicazioni, presentano sfide di sicurezza, quindi è meglio autenticarsi, crittografarle e autorizzarle. Questi passaggi supportano il principio Zero Trust, in che si presuppone che tutto il traffico di rete sia a rischio, indipendentemente dal fatto che il traffico ha origine all'interno o all'esterno della rete.
Il pattern di progettazione del mesh di servizi separa qualsiasi complessità relativa le comunicazioni tra servizi dalla logica di business. È il piano di dati a gestire questa complessità. Oltre a ridurre la complessità dell'applicazione, il pattern di progettazione del mesh di servizi consente modelli di sicurezza che altrimenti potrebbero essere 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 la procedura di implementazione 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 e etichette di deployment.
- Disponibilità elevata dei servizi gestiti di Google, tra cui Cloud Service Mesh e Pool di autorità di certificazione private gestite da CA Service.
- Sicurezza legata a Google Identity and Access Management (IAM): autorizzazione del servizio basata su account di servizio Google autorizzati.
- Interoperabilità perfetta con i tuoi carichi di lavoro 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 da gRPC ma il client utilizza un proxy Envoy.
Comunicazioni tra servizi sicure
Cloud Service Mesh fornisce l'autorizzazione e la sicurezza da servizio a servizio con crittografia e autenticazione che utilizzano TLS. 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 adottare misure speciali per essere sicure.
I criteri di autorizzazione ti consentono di negare o consentire l'accesso in base a regole che definisci.
Utilizzare TLS per la crittografia
Quando un servizio chiama su un altro servizio utilizzando HTTP, HTTP/2 o gRPC il traffico in transito nella rete è in testo normale. Questo traffico potrebbe essere soggetto a attacchi man-in-the-middle, in cui un malintenzionato intercetta il traffico e ne ispeziona o manipola i contenuti.
Per ridurre questo potenziale problema, puoi utilizzare HTTP, HTTP/2 o gRPC tramite TLS con Cloud Service Mesh. Quando utilizzi questi protocolli su TLS, il traffico tra il client e il server viene criptato utilizzando TLS in base al 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 relativi contenuti.
Utilizzare TLS per l'autenticazione
Quando un servizio effettua una chiamata a un altro servizio, poniti le seguenti domande:
Come fa un cliente a sapere che sta ricevendo una risposta da parte di server piuttosto che un impostore? Ad esempio, in una tipica richiesta-risposta basata su HTTP, il client non verifica l'identità del server.
Cosa succede se un aggressore intercetta questo traffico? Ad esempio, traffico HTTP non è criptato, quindi chiunque riceva il traffico può esaminarne il contenuto. Questo è noto come attacco man 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 per dimostrare la propria identità al client. Le richieste e le risposte vengono quindi criptate utilizzando TLS.
Autenticazione TLS reciproca
Quando Cloud Service Mesh configura la rete di applicazioni sia per il client sia per il server, ad esempio configurando un proxy Envoy sul lato client e un altro proxy Envoy sul lato server, puoi sfruttare modelli di autenticazione avanzati come l'autenticazione reciproca.
In un tipico scambio HTTP su TLS, che non si basa su reciproche autenticazione, 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 l'handshake TLS. Tuttavia, il server non verifica l'identità del client.
Quando l'autenticazione reciproca è abilitata, il client ha anche un certificato. La verifica l'identità del server, come descritto nel paragrafo precedente, e il server può anche verificare l'identità del client. I certificati sia del client sia del server vengono utilizzati per criptare il canale di comunicazione. Ciò consente inoltre il server ad autorizzare i client in base a una verifica dell'identità del client.
Autorizza chiamate di servizio
Puoi scegliere di consentire o negare l'accesso al servizio utilizzando i criteri di autorizzazione.
Con Cloud Service Mesh, puoi definire regole di autorizzazione e di rifiuto per autorizzare l'accesso in base ai parametri di richiesta. Puoi basare queste regole sul livello 3 e 7
parametro, incluso l'ID client, derivato da client-cert
in un
Connessione mTLS, indirizzo IP di origine, corrispondenza dell'host, corrispondenza del metodo e intestazione
corrispondono. Il seguente diagramma mostra l'autorizzazione con i proxy Envoy. La procedura è simile per i client gRPC.
Limitare l'accesso tramite l'autorizzazione
Una best practice all'interno di un mesh di servizi è rispettare il principio di almeno di accesso. Puoi aderire a questo principio limitando l'accesso ai servizi solo ai chiamanti che dipendono dal servizio. Quando un chiamante tenta di accedere per un servizio per il quale non è autorizzato, il tentativo viene rifiutato.
Con Cloud Service Mesh, puoi configurare criteri di autorizzazione che consentano al tuo piano dati di consentire o negare l'accesso ai servizi in base alle 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 un'RPC, il client Cloud Service Mesh nel 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 a cui trovare una corrispondenza come i seguenti:
- Quando viene utilizzato mTLS, l'account di servizio 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 i nomi host, i metodi e le intestazioni HTTP definite dall'utente.
Nomi sicuri
Come meccanismo di sicurezza aggiuntivo, puoi configurare una denominazione sicura con Cloud Service Mesh. In questo modo puoi definire un elenco di nomi consentiti o di 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 cliente quindi controlla il certificato per confermare che il certificato X.509 corrisponda a uno degli i nomi o le identità SPIFFE. Per saperne di più sulle identità SPIFFE, consulta Secure Production Identity Framework for Everyone.
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 in uno dei seguenti modi:
- Un gateway in entrata che gestisce il traffico in entrata 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 proxy inverso o un proxy centrale che distribuisce il traffico in entrata tra uno o altri servizi
I client che vogliono inviare traffico all'interno o all'esterno del mesh lo inviano al gateway. Il gateway gestisce quindi le richieste in base alle regole configurato con Cloud Service Mesh. Ad esempio, puoi imporre che entrano nel mesh (sebbene il gateway in entrata) sia criptato tramite TLS.
Componenti di sicurezza
La sicurezza del servizio Cloud Service Mesh supporta i criteri TLS del client e TLS del server i criteri e i criteri di autorizzazione. I criteri vengono creati in modo da Cloud Service Mesh può configurare il tuo piano dati e abilitare la sicurezza le funzionalità di machine learning. Per creare o aggiornare queste norme, non è necessario apportare modifiche alle applicazioni.
Crittografia e modalità di autenticazione supportate
Quando un servizio effettua una chiamata a un altro servizio, il primo passo per stabilire la sicurezza le comunicazioni è fare in modo che ogni servizio dimostri la propria identità all'altro servizio. Il grado in cui un servizio deve dimostrare la propria identità si basa sulla modalità TLS configurata.
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 costituiscono la base per la fiducia in un sistema distribuito come un mesh di servizi. Utilizzando i certificati, i servizi possono dimostrare la propria identità e verificare le identità che vengono loro presentate nei seguenti modi:
- Un servizio che vuole dimostrare la propria identità a un altro servizio presenta il suo 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 proveniente da una CA che considera attendibile.
Cloud Service Mesh non è un'autorità di certificazione. Per attivare la sicurezza comunicazione, è necessario impostare un meccanismo che:
- Esegue il provisioning di identità e certificati
- Rende disponibili i certificati per i client Cloud Service Mesh, come i proxy Envoy, configurati da Cloud Service Mesh
Cloud Service Mesh supporta il servizio CA di Google. Le guide alla configurazione per Envoy e gRPC proxyless includono istruzioni per la configurazione (per maggiori dettagli, consulta Passaggi successivi).
Architettura e risorse
Cloud Service Mesh include lo spazio dei nomi dell'API Network Security, composto da tre risorse dell'API Google Cloud che ti consentono di specificare i criteri di sicurezza da applicare al piano dati.
L'autenticazione nella mesh è supportata da due risorse API Google Cloud: ai criteri TLS del client e ai criteri TLS del server. Una terza risorsa, l'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 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.
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 client supportano l'autenticazione TLS e mTLS. I criteri TLS del client devono essere collegato a una risorsa del servizio di backend globale.
Quando configuri TLS, devi fornire un meccanismo tramite il quale il client convalida il certificato che riceve dal server durante lo scambio TLS utilizzando il campo API serverValidationCa
. Il cliente utilizza questo
informazioni per ottenere un certificato di convalida che possa essere utilizzato per convalidare
certificato del server.
Quando configuri mTLS, devi anche fornire un meccanismo tramite il quale il client ottiene il proprio certificato e la propria 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. Configurazione
È diretta: devi specificare il nome del plug-in google_cloud_private_spiffe
quando configuri il provider del certificato. Questo fa sì che i client xDS
caricare certificati e chiavi da una posizione statica. Come prerequisiti, devi configurare i pool di servizi CA e abilitare i certificati mesh sul tuo cluster GKE.
Criterio TLS del server
Un criterio 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. I criteri TLS del server supportano TLS, mTLS e, solo con Envoy,
Autenticazione Open_or_mTLS
. Puoi collegare i criteri TLS del server a un endpoint
risorsa del criterio.
Nomi alternativi dell'oggetto
Quando configuri il campo securitySettings
di un servizio di backend globale, puoi:
fornisce un elenco di nomi alternativi dei soggetti nel campo subjectAltNames
. Quando
un client avvia un handshake TLS con uno dei backend del servizio,
server presenta il proprio certificato X.509. Il client ispeziona il camposubjectAltName
del certificato. Se il campo contiene uno dei valori specificati, la comunicazione continua. Questo meccanismo è descritto in precedenza in
Denominazione sicura.
Criterio di autorizzazione
Un criterio di autorizzazione (risorsa AuthorizationPolicy
) specifica in che modo un server autorizzi le richieste o le RPC in entrata. Può essere configurato per consentire o negare un
in entrata o in RPC in base a vari parametri, ad esempio l'identità del client
che ha inviato la richiesta, l'host, le intestazioni e altri attributi HTTP. Allega
di autorizzazione a una risorsa
dei criteri degli endpoint.
Una regola del criterio di autorizzazione include i seguenti componenti:
from
: specifica l'identità del client consentita dalla regola. L'identità può essere ricavata da un certificato client in un protocollo TLS reciproco o l'identità Ambient associata al client ad esempio da un account di servizio o da un tag sicuro.to
: specifica le operazioni consentite dalla regola, ad esempio gli URL che o i metodi HTTP consentiti.when
: consente di definire vincoli aggiuntivi che devono essere soddisfatti. Puoi utilizzare le espressioni Common Expression Language (CEL) per definire le limitazioni.action
: specifica l'azione della regola. Può essere uno diALLOW
,DENY
oCUSTOM
.
Limitazioni
La sicurezza del servizio Cloud Service Mesh è supportata solo con GKE. Non puoi eseguire il deployment della sicurezza dei servizi con Compute Engine.
Quando valuta una richiesta, un criterio di autorizzazione esegue una delle seguenti azioni:
ALLOW
: concede l'accesso alla risorsa richiesta se la richiesta corrisponde alla regole definite nel criterio di autorizzazione. Il criterio di autorizzazione blocca l'accesso alla risorsa richiesta se la richiesta non corrisponde a nessuna delle regole definite all'interno del criterio di autorizzazione. Se una richiesta viene rifiutata, non corrisponde a un criterioALLOW
, anche se altri criteri lo consentono.DENY
: blocca l'accesso alla risorsa se una richiesta corrisponde a una delle regole specificate in un criterioDENY
. Il criterio di autorizzazione concede l'accesso alla risorsa richiesta se la richiesta non corrisponde a nessuna regola definita all'interno del criterio di autorizzazione. Una richiesta viene rifiutata se corrisponde a un criterioDENY
. anche se altri criteri lo consentono.CUSTOM
(non supportato su Cloud Service Mesh): abilita l'integrazione con sistemi di autorizzazione esterni per decisioni di autorizzazione complesse.CUSTOM
azioni vengono utilizzate per i criteri che utilizzano le estensioni di servizio per le decisioni sull'autorizzazione.
Ordine di valutazione criteri di autorizzazione
Quando a una singola risorsa sono associati più criteri di autorizzazione, questi vengono valutati nell'ordine seguente per determinare se una richiesta è consentita o negata.
Criteri con azioni
CUSTOM
: se il criterioCUSTOM
nega il richiesta, la richiesta viene rifiutata immediatamente. CriteriDENY
oALLOW
non vengono valutati, anche se configurati.Criteri con azioni
DENY
: se esistono criteriDENY
corrispondono alla richiesta, la richiesta viene rifiutata. I criteriALLOW
non vengono valutati, anche se sono configurati.Criteri con azioni
ALLOW
: se non sono presenti criteriALLOW
o se un criterioALLOW
corrisponde alla richiesta, la richiesta è consentita. Tuttavia, se nessun criterioALLOW
corrisponde alla richiesta, la richiesta viene rifiutata.
Limitazioni con applicazioni gRPC senza proxy
La sicurezza del servizio per i servizi gRPC senza proxy presenta le seguenti limitazioni:
- Questa release è limitata a Java, Python, C++ e Go.
Quote di AuthzPolicy
- Non puoi superare un totale di 5 criteri di autorizzazione per gateway.
- Sei limitato a 20 risorse AuthorizationPolicy per progetto.
- Un singolo AuthorizationPolicy può puntare a un massimo di 100 gateway.
Passaggi successivi
- Per saperne di più sulle opzioni di configurazione, consulta Casi d'uso per la sicurezza del servizio Cloud Service Mesh.
- Per scoprire di più sui criteri di autorizzazione, consulta la Panoramica dei criteri di autorizzazione.
- Per configurare la sicurezza dei servizi con i proxy Envoy, consulta Configurazione della sicurezza del servizio Cloud Service Mesh con Envoy.
- Per configurare la sicurezza del servizio con applicazioni gRPC senza proxy, consulta Configurazione della sicurezza del servizio Cloud Service Mesh con applicazioni gRPC senza proxy.