Questo documento illustra le misure di sicurezza integrate in Connect.
Una piattaforma ibrida e multi-cloud efficace offre gestione centralizzata, osservabilità e accesso ai servizi in più ambienti. GKE Enterprise offre un'esperienza uniforme e completa per tutte queste funzionalità, a prescindere dal provider Kubernetes che utilizzi. Connect è un agente leggero che fornisce quanto segue nelle economie di scala e tra i provider:
- Gestione multi-cluster e visibilità dei cluster
- Deployment e gestione del ciclo di vita dei servizi per le applicazioni
In questo documento vengono trattati i seguenti argomenti:
- In che modo il design di Connect mette la sicurezza al primo posto
- Best practice per il deployment dell'agente Connect
- Come migliorare la strategia di sicurezza per il deployment di Kubernetes
Architettura di Connect
Connect consente agli utenti finali e ai servizi Google Cloud di accedere ai server API Kubernetes che non si trovano sulla rete internet pubblica. L'agente Connect viene eseguito nel cluster Kubernetes (un agente per cluster) e si connette a un proxy di connessione. I servizi Google Cloud che devono interagire con il cluster Kubernetes si connettono al proxy, che inoltra le richieste all'agente. L'agente, a sua volta, li inoltra al server API Kubernetes come illustrato nel diagramma seguente.
Durante il deployment, l'agente stabilisce una connessione TLS 1.2 o superiore permanente a Google Cloud per attendere le richieste. Se abilitati dagli amministratori, i servizi Google Cloud possono generare richieste per i tuoi cluster Kubernetes. Queste richieste possono anche provenire dall'interazione diretta dell'utente con la console Google Cloud, Connect Gateway o altri servizi Google.
Il servizio Google Cloud invia la richiesta al proxy. Il proxy inoltra quindi la richiesta all'agente di cui è stato eseguito il deployment responsabile di un cluster e infine l'agente inoltra la richiesta al server API Kubernetes. Il server API Kubernetes applica i criteri di autenticazione, autorizzazione e audit logging di Kubernetes e restituisce una risposta. La risposta viene restituita tramite l'agente e il proxy al servizio Google Cloud. In ogni passaggio del processo, i componenti eseguono l'autenticazione e l'autorizzazione per connessione e per richiesta.
Il server API Kubernetes applica gli stessi criteri di autenticazione, autorizzazione e audit logging a tutte le richieste, incluse quelle effettuate tramite Connect. In questo modo avrai sempre il controllo dell'accesso al cluster.
Connessione e difesa in profondità
La difesa in profondità è intrinseca a tutto ciò che Google Cloud fa all'interno della sua infrastruttura e delle prassi di sicurezza. Adottiamo un approccio a più livelli a ogni aspetto della protezione della nostra organizzazione e dei nostri clienti al fine di proteggere dati, informazioni e utenti preziosi. Si tratta dello stesso principio con cui abbiamo progettato Connect.
Oltre alla strategia e alla progettazione di difesa in profondità di Google, è necessario valutare i contenuti qui forniti insieme alla condizione e agli standard di sicurezza. Questa sezione illustra altre misure che puoi adottare, a complemento delle best practice di protezione di Kubernetes.
Sicurezza da un componente all'altro
Ogni componente di una richiesta Connect autentica i suoi peer e condivide solo i dati con peer autenticati e autorizzati per questi dati, come illustrato nel diagramma seguente.
Ogni componente di una richiesta Connect utilizza quanto segue per autenticarsi:
- Transport Layer Security (TLS)
- Application Layer Transport Security (ALTS)
- OAuth
Ogni componente di una richiesta Connect utilizza quanto segue per autorizzarsi a vicenda:
- Identity and Access Management (IAM)
- Liste consentite
Ogni connessione tra il cluster Kubernetes e Google Cloud è criptata e almeno un peer di ogni connessione utilizza l'autenticazione basata su certificati. Questo processo garantisce che tutte le credenziali del token siano crittografate in transito e ricevute solo da peer autenticati e autorizzati.
Autenticazione degli utenti in Google Cloud
Quando utilizzano la console Google Cloud, gli utenti seguono il flusso di accesso standard a Google. Google Cloud fornisce un certificato TLS autenticato dal browser dell'utente e l'utente accede a un account Google Cloud o Google Workspace per eseguire l'autenticazione in Google Cloud.
L'accesso a un progetto tramite la console Google Cloud o altre API è controllato dalle autorizzazioni IAM.
Autenticazione da servizi a servizio di Google Cloud
Google Cloud utilizza ALTS per l'autenticazione interna tra servizi. ALTS consente ai servizi Google Cloud, ad esempio il proxy, di creare una connessione autenticata e protetta dall'integrità.
I servizi Google Cloud devono essere autorizzati internamente in modo da utilizzare il proxy per connettersi a un'istanza Connect remota, poiché il proxy utilizza una lista consentita di identità di servizio per limitare l'accesso.
Autenticazione di Google Cloud
L'agente utilizza TLS per autenticare e criptare ogni connessione. L'agente autentica i certificati TLS di Google Cloud utilizzando un set di certificati radice integrati nel programma binario, per evitare di considerare attendibili i certificati aggiunti inavvertitamente al container dell'agente. L'agente esegue solo le chiamate API su endpoint correttamente autenticati. Questo processo garantisce che i certificati degli account di servizio e le richieste API Kubernetes vengano inviati da Google Cloud e che le eventuali risposte vengano inviate solo a Google Cloud.
Per l'elenco dei domini con cui l'agente comunica durante il normale funzionamento, consulta Garantire la connettività di rete.
Puoi configurare l'agente in modo che connetta a Google Cloud tramite un proxy HTTP. In questa configurazione, l'agente utilizza HTTP/1.1
CONNECT per il proxy HTTP e stabilisce una connessione TLS a
Google Cloud. Il proxy HTTP vede solo il traffico criptato tra l'agente e Google Cloud. L'integrità e la sicurezza end-to-end della connessione
tra l'agente e Google Cloud non sono interessate.
Autenticazione dell'agente
L'agente esegue l'autenticazione in Google Cloud utilizzando un account di servizio Google Cloud creato da te. Quando l'amministratore del cluster esegue il deployment dell'agente, fornisce una chiave privata per questo account di servizio e si assume la responsabilità della privacy della chiave. Quando l'agente si connette a Google Cloud, esegue l'autenticazione con questo account di servizio e chiede di ricevere richieste per il progetto configurato.
Google Cloud autentica le credenziali dell'account di servizio e verifica inoltre che l'account di servizio Google Cloud disponga dell'autorizzazione IAM gkehub.endpoints.connect nel progetto. Questa autorizzazione viene in genere concessa
tramite il ruolo gkehub.connect. Senza questa autorizzazione, la richiesta dell'agente
viene rifiutata e non può ricevere richieste da Google Cloud.
Server API Kubernetes
L'agente utilizza la libreria client di Kubernetes per creare una connessione TLS al server API Kubernetes. Il runtime Kubernetes fornisce al container dell'agente un certificato dell'autorità di certificazione (CA) TLS che l'agente utilizza per autenticare il server API.
Il server API autentica ogni richiesta separatamente, come descritto nella sezione successiva.
Richiedi sicurezza
Ogni richiesta inviata da Google Cloud tramite Connect include credenziali che identificano il mittente della richiesta: sia il servizio Google Cloud che ha generato la richiesta sia (ove applicabile) l'utente finale per il quale viene inviata la richiesta. Queste credenziali consentono al server API Kubernetes di fornire controlli di autorizzazione e controllo per ogni richiesta.
Autenticazione da servizio ad agente
Ogni richiesta inviata all'agente include un token di breve durata che identifica il servizio Google Cloud che ha inviato la richiesta, come illustrato nel diagramma seguente.
Il token è firmato da un account di servizio Google Cloud associato esclusivamente al servizio Google Cloud. L'agente carica le chiavi pubbliche dell'account di servizio per convalidare il token. Questo token non viene inoltrato al server API.
L'agente convalida i certificati Google Cloud utilizzando le radici CA incorporate nel file binario. Questo processo contribuisce a garantire che riceva richieste autentiche e inalterate da Google Cloud.
Autenticazione dell'utente finale
I servizi Google Cloud che accedono ai cluster per conto di un utente richiedono le credenziali dell'utente per l'autenticazione sul server API, come illustrato nel diagramma seguente.
Questo criterio consente di garantire che all'utente venga applicato lo stesso insieme di autorizzazioni quando accede tramite Connect. Alcuni servizi Google Cloud eseguono l'autenticazione nel server API per conto di un utente. Ad esempio, un utente può accedere alla console Google Cloud per visualizzare i carichi di lavoro nei cluster registrati nel parco risorse. Quando un utente accede a questi servizi, fornisce le credenziali che il server API Kubernetes riconosce: qualsiasi token supportato dal server API Kubernetes.
La console Google Cloud archivia queste credenziali come parte del profilo di un utente. Queste credenziali vengono criptate at-rest, sono accessibili solo con le credenziali Google Cloud o Google Workspace dell'utente e vengono utilizzate solo per le connessioni tramite Connect. Queste credenziali non possono essere scaricate di nuovo. Le credenziali vengono eliminate quando l'utente si disconnette dal cluster, quando la registrazione del cluster viene eliminata in Google Cloud, quando il progetto viene eliminato o quando l'account utente viene eliminato. Per ulteriori informazioni, consulta Eliminazione di dati su Google Cloud.
Quando un utente interagisce con la console Google Cloud, genera richieste per il server API Kubernetes. Il servizio invia le credenziali dell'utente insieme alla richiesta tramite Connect. L'agente quindi presenta la richiesta e le credenziali al server API Kubernetes.
Il server API Kubernetes autentica le credenziali dell'utente, esegue l'autorizzazione sull'identità dell'utente, produce un evento di controllo per l'azione (se configurato) e restituisce il risultato. Poiché le credenziali fornite dall'utente vengono utilizzate per autenticare la richiesta, il server API Kubernetes applica per le richieste Connect gli stessi criteri di autorizzazione e controllo applicati ad altre richieste.
Autenticazione da servizio a Kubernetes
I servizi Google Cloud che accedono al server API Kubernetes al di fuori del contesto di un utente utilizzano la rappresentazione di Kubernetes per eseguire l'autenticazione al server API Kubernetes. Questo metodo consente al server API Kubernetes di fornire controlli di autorizzazione e audit logging per servizio, come illustrato nel diagramma seguente.
I servizi di Google Cloud possono usare Connect al di fuori del contesto dell'utente. Ad esempio, un servizio Ingress multi-cluster può sincronizzare automaticamente le risorse in entrata tra i cluster. Questi servizi non hanno credenziali che il server API Kubernetes può autenticare: la maggior parte dei server API non è configurata per autenticare le credenziali del servizio Google Cloud. Tuttavia, un server API può delegare privilegi di autenticazione limitati a un altro servizio tramite il furto d'identità e l'agente può autenticare i servizi Google Cloud inviando richieste tramite Connect. Insieme, queste consentono alle richieste tramite l'agente di autenticarsi come account di servizio Google Cloud.
Quando un servizio Google Cloud invia una richiesta per proprio conto (anziché nel contesto di un utente), l'agente aggiunge alla richiesta le proprie credenziali Kubernetes e le intestazioni di rappresentazione Kubernetes che identificano il servizio Google Cloud. Le intestazioni di rappresentazione richiedono un nome utente dell'account di servizio Google Cloud autenticato dall'agente.
Il server API Kubernetes autentica le credenziali dell'agente e verifica inoltre che l'agente possa impersonare l'account di servizio Google Cloud. La capacità di impersonare è in genere controllata da regole di controllo dell'accesso basato sui ruoli (RBAC) e può essere limitata a identità specifiche, come gli account di servizio Google Cloud.
Se l'agente è autorizzato a impersonare l'identità richiesta, il server API esegue quindi i controlli di autorizzazione per l'account di servizio Google Cloud e gestisce la richiesta. L'audit log per la richiesta include sia l'identità dell'agente sia l'account di servizio Google Cloud impersonato.
Sicurezza nel cluster
Infine, l'agente invia le richieste API Kubernetes al server API Kubernetes, come illustrato nel diagramma seguente.
Il server API Kubernetes autentica, autorizza e registra queste richieste, proprio come fa per tutte le altre richieste che gestisce.
Come proxy per queste richieste, l'agente ha accesso a dati sensibili, come credenziali, richieste e risposte. Kubernetes e l'ecosistema Kubernetes forniscono un set di strumenti per impedire ad altri attori di ottenere questo accesso e per contribuire a garantire che l'agente acceda solo a ciò che dovrebbe.
Autenticazione Kubernetes
Il server API Kubernetes autentica il mittente di ogni richiesta in entrata per determinare quali autorizzazioni applicare nella fase di autorizzazione. Come descritto in precedenza, la richiesta include le credenziali di un utente o include le credenziali Kubernetes e le intestazioni di rappresentazione dell'agente.
Gli amministratori dei cluster mantengono il controllo dei meccanismi di autenticazione riconosciuti dal server API Kubernetes. Gli amministratori potrebbero essere in grado di revocare le credenziali di un utente e possono revocare o ridurre i privilegi delle credenziali dell'agente.
Autorizzazione Kubernetes
Il server API Kubernetes controlla che l'identità autenticata sia autorizzata a eseguire l'azione richiesta sulla risorsa richiesta.
L'amministratore del cluster può utilizzare uno qualsiasi dei meccanismi di autorizzazione di Kubernetes per configurare le regole di autorizzazione. Connect non esegue alcun controllo di autorizzazione per conto del cluster.
Sicurezza degli agenti
L'agente ha accesso alle proprie credenziali (Kubernetes e Google Cloud), nonché alle credenziali, alle richieste e alle risposte che lo attraversano. Pertanto, l'agente occupa una posizione attendibile in un cluster connesso.
L'agente è progettato con i seguenti concetti fondamentali sulla sicurezza:
- L'agente è scritto in Go, che fornisce la gestione della memoria garbage collection e impedisce molte operazioni di memoria non sicure.
- Il deployment dell'agente viene eseguito in un'immagine container distroless. L'immagine dell'agente non include una shell, libc o altro codice non pertinente al percorso di esecuzione dell'agente.
- L'immagine dell'agente viene creata dall'infrastruttura di build condivisa di Google a partire dal codice registrato. Solo questo sistema di compilazione può eseguire il deployment delle immagini agente in Container Registry. Gli sviluppatori Google Cloud non possono eseguire autonomamente il deployment di nuove immagini. Questo processo aiuta a garantire che tutte le modifiche all'origine dell'agente possano essere ricondotte a un autore e a un revisore in caso di non ripudio.
L'agente viene eseguito come deployment standard
in un cluster Kubernetes il cui deployment viene eseguito nel momento in cui registri il cluster.
Di conseguenza, tutte le opzioni e le best practice disponibili per il monitoraggio e la protezione dei deployment, ReplicaSets e dei pod sono disponibili per l'agente.
Questi meccanismi sono progettati in modo da rendere difficile la compromissione del container dell'agente. Tuttavia, l'accesso privilegiato al nodo dell'agente può comunque compromettere l'ambiente dell'agente; pertanto, è importante che gli amministratori seguano le linee guida di sicurezza standard di Kubernetes per proteggere l'infrastruttura del cluster.
Sicurezza dei dati con i Controlli di servizio VPC
I Controlli di servizio VPC forniscono un ulteriore livello di protezione per i servizi Google Cloud, indipendente da Identity and Access Management (IAM). Mentre IAM consente un controllo dell'accesso basato sull'identità granulare, i Controlli di servizio VPC offrono una più ampia sicurezza perimetrale basata sul contesto, compreso il controllo del traffico in uscita dei dati attraverso il perimetro. Ad esempio, puoi specificare che solo determinati progetti possono accedere ai tuoi dati BigQuery. Per saperne di più su come funzionano i Controlli di servizio VPC per proteggere i tuoi dati, consulta la Panoramica sui Controlli di servizio VPC.
Puoi utilizzare Controlli di servizio VPC con Connect per una maggiore sicurezza dei dati, dopo aver verificato che i servizi necessari per utilizzare Connect siano accessibili dall'interno del perimetro di servizio specificato.
Se vuoi utilizzare Controlli di servizio VPC, devi abilitare le seguenti API:
cloudresourcemanager.googleapis.comgkeconnect.googleapis.comgkehub.googleapis.com
Devi inoltre configurare la connettività privata per l'accesso alle API pertinenti. Puoi scoprire come farlo in Configurare la connettività privata.