Collega le funzionalità di sicurezza

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 tra tutte queste capacità, a prescindere dal provider Kubernetes che usi. Connect è un agente leggero che fornisce quanto segue nelle economie di scala e attraverso di altri fornitori:

• 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 a Google Cloud per accedere ai server API Kubernetes non sono disponibili sulla rete internet pubblica. L'agente Connect viene eseguito Kubernetes (un agente per cluster) e si connette a una Connetti proxy. ai servizi Google Cloud che devono interagiscono con il cluster Kubernetes e la connessione al proxy, inoltra le richieste all'agente. L'agente, a sua volta, lo inoltra al team Server API Kubernetes come illustrato nel seguente diagramma.

Architettura di come gli utenti accedono a server API Kubernetes che non sono su internet (fai clic per ingrandire)

Al momento del deployment, l'agente stabilisce una connessione TLS 1.2+ permanente Google Cloud deve attendere le richieste. Servizi Google Cloud, se abilitati dagli amministratori, possono generare richieste per i tuoi cluster Kubernetes. Queste richieste Potrebbero 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 quindi inoltra la richiesta all'agente di cui è stato eseguito il deployment responsabile di un cluster Infine, l'agente inoltra la richiesta al server API Kubernetes. Il server API di Kubernetes applica l'autenticazione Kubernetes, di autorizzazione e di audit logging e restituisce una risposta. La risposta viene restituito al servizio Google Cloud tramite l'agente e il proxy. In ogni passaggio della procedura, i componenti vengono eseguiti per connessione e per richiesta l'autenticazione e l'autorizzazione.

Il server API Kubernetes applica la stessa autenticazione, di autorizzazione e di audit logging a tutte le richieste, comprese le richieste tramite Connect. Questa procedura ti consente di avere sempre e controllare l'accesso al cluster.

Connessione e difesa in profondità

Difesa in profondità è intrinseca a tutto ciò che fa Google Cloud all'interno della sua infrastruttura pratiche di sicurezza. Adottiamo un approccio a più livelli a ogni aspetto della sicurezza dei nostri organizzazione e ai nostri clienti al fine di proteggere dati, informazioni e utenti. Si tratta dello stesso principio con cui abbiamo progettato Connect.

Oltre alla strategia e alla progettazione di difesa in profondità di Google, dovresti valutare il contenuto qui fornito insieme al livello di sicurezza e standard. Questa sezione richiama altre misure che puoi integrano le best practice di protezione avanzata di Kubernetes.

Sicurezza da un componente all'altro

Ogni componente di una richiesta Connect autentica la sua peer e condivide solo i dati con peer autenticati e autorizzate per questi dati, come illustrato nel diagramma seguente.

Architettura di come eseguire l'autenticazione dei componenti Connect (fai clic per ingrandire)

Ogni componente di una richiesta Connect utilizza quanto segue per autenticarsi reciprocamente:

• Transport Layer Security (TLS)
• Application Layer Transport Security (ALTS)
• OAuth

Ogni componente di una richiesta Connect utilizza quanto segue per si autorizzano a vicenda:

• Identity and Access Management (IAM)
• Liste consentite

Ogni connessione tra il cluster Kubernetes e Google Cloud è criptato e almeno un peer di ogni connessione utilizza autenticazione. Questo processo aiuta a garantire che tutte le credenziali del token siano criptati in transito e ricevuti solo da peer autenticati e autorizzati.

Autenticazione degli utenti in Google Cloud

Quando utilizzano la console Google Cloud, gli utenti passano attraverso flusso standard di accesso a Google. Google Cloud fornisce un certificato TLS che il browser dell'utente esegue l'autenticazione e l'utente accede a un account Google Cloud o Google Workspace per devono eseguire l'autenticazione in Google Cloud.

L'accesso a un progetto tramite la console Google Cloud o altre API controllate da 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 un connessione autenticata e protetta da integrità.

I servizi Google Cloud devono essere autorizzati internamente per utilizzare il proxy per connettersi a un'istanza Connect remota perché il proxy utilizza un 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 indirizzi certificati integrati nel file binario, per evitare di considerare attendibili inavvertitamente i certificati aggiunto al container dell'agente. L'agente esegue solo chiamate API correttamente autenticati. Questa procedura aiuta a garantire che il servizio e le richieste API Kubernetes vengono inviate Google Cloud e che tutte le risposte vengano inviate solo a Google Cloud.

Per l'elenco dei domini con cui l'agente comunica durante il normale funzionamento, consulta l'articolo Garantire la connettività di rete.

Puoi configurare l'agente per connetterti a Google Cloud attraverso un proxy HTTP. In questa configurazione, l'agente utilizza HTTP/1.1 CONNECT per il proxy HTTP e stabilisce una connessione TLS a in Google Cloud. Il proxy HTTP vede solo il traffico criptato tra e Google Cloud. Integrità e sicurezza end-to-end della connessione tra l'agente e Google Cloud non è interessata.

Autenticazione dell'agente

L'agente esegue l'autenticazione in Google Cloud utilizzando una Account di servizio Google Cloud che crei. Quando l'amministratore del cluster esegue il deployment dell'agente, fornisce una chiave privata per questo account di servizio e assumersi la responsabilità privacy. Quando l'agente si connette a Google Cloud, con questo account di servizio, e chiede di ricevere richieste per il progetto configurato.

Google Cloud autentica le credenziali dell'account di servizio e controlla inoltre che l'account di servizio Google Cloud abbia gkehub.endpoints.connect Autorizzazione IAM nel progetto. Questa autorizzazione viene solitamente 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 l'ambiente Kubernetes libreria client per creare una connessione TLS al server API Kubernetes. Il cluster Kubernetes il runtime fornisce al container dell'agente un'autorità di certificazione (CA) TLS certificato utilizzato dall'agente per autenticare il server API.

Il server API autentica ogni richiesta separatamente, come descritto .

Richiedi sicurezza

Ogni richiesta inviata da Google Cloud tramite Connect include le credenziali che identificano il mittente della richiesta: sia la Il servizio Google Cloud che ha generato la richiesta e (ove applicabile) l'utente finale per il quale viene inviata la richiesta. Queste credenziali consentono Server API Kubernetes per 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 dal servizio Google Cloud che ha inviato la richiesta, come illustrato di seguito. in questo diagramma.

Architettura di richieste con un token che identifica i servizi Google Cloud (fai clic per ingrandire)

Il token è firmato da un account di servizio Google Cloud associato. esclusivamente con il 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 in il file binario. Questo processo aiuta a garantire che stia ricevendo messaggi autentici e richieste invariate da Google Cloud.

Autenticazione dell'utente finale

I servizi Google Cloud che accedono ai cluster per conto di un utente richiedono le credenziali di quell'utente per l'autenticazione sul server API, come illustrato nel seguente diagramma.

Architettura dei servizi Google Cloud che autenticano le credenziali di un utente (fai clic per ingrandire)

Questo criterio consente di garantire che venga applicato lo stesso insieme di autorizzazioni a: all'utente che accede tramite Connect. Alcune I servizi Google Cloud vengono autenticati nel server API per conto di un utente. Ad esempio, un utente può accedere alla console Google Cloud per visualizzare i carichi di lavoro in Cluster registrati del parco risorse. Quando un utente accede a questi servizi, fornisce Credenziali riconosciute dal server API Kubernetes: uno qualsiasi dei token supportate dal server API Kubernetes.

La console Google Cloud archivia queste credenziali come parte del profilo di un utente. Queste credenziali vengono criptate at-rest e sono accessibili solo dalla le credenziali di Google Cloud o Google Workspace e sono utilizzate solo per e le connessioni tramite Connect. Queste credenziali non possono essere scaricato di nuovo. Le credenziali vengono eliminate quando l'utente si disconnette cluster, quando la registrazione del cluster viene eliminata in Google Cloud e quando quando viene eliminato il progetto o l'account utente. Per ulteriori informazioni le informazioni, vedi Eliminazione dei dati su Google Cloud.

Quando un utente interagisce con la console Google Cloud, genera richieste di il server API di 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 azione (se configurata), e restituisce il risultato. Poiché le credenziali fornite dall'utente vengono utilizzate la richiesta, il server API Kubernetes applica criterio di autorizzazione e controllo per Connect delle richieste come per le altre.

Autenticazione da Service-to-Kubernetes

Servizi Google Cloud che accedono al server API Kubernetes al di fuori del contesto di un utente, usa la rappresentazione di Kubernetes per eseguire l'autenticazione il server API Kubernetes. Questo metodo consente all'API Kubernetes server per fornire controlli di autorizzazione e audit logging per servizio, come illustrato nel seguente diagramma.

Architettura dei controlli di autorizzazione per servizio (fai clic per ingrandire)

I servizi di Google Cloud possono utilizzare Connect al di fuori di il contesto di un utente. Ad esempio, un servizio Ingress multi-cluster può automaticamente sincronizzare le risorse in entrata tra i cluster. Questi servizi non dispongono di credenziali che il server API Kubernetes può autenticare: la maggior parte delle API i server non sono configurati per autenticare le applicazioni e credenziali. Tuttavia, un server API può delegare l'autenticazione limitata i privilegi a un altro servizio tramite furto d'identità e l'agente può autenticare i servizi Google Cloud che inviano richieste tramite Connect. Insieme, questi strumenti consentono tramite l'agente per l'autenticazione come servizio Google Cloud .

Quando un servizio Google Cloud invia una richiesta per proprio conto (anziché nel contesto di un utente), l'agente aggiunge il proprio Credenziali Kubernetes, e Intestazioni di rappresentazione Kubernetes che identificano il servizio Google Cloud, alla richiesta. Il furto d'identità intestazioni dichiarano un nome utente dell'account di servizio Google Cloud autenticato dall'agente.

Il server API di Kubernetes autentica le credenziali dell'agente e verifica anche che l'agente possono rubare l'identità l'account di servizio Google Cloud. La capacità di rubare l'identità è in genere controllato da regole di controllo degli accessi basato su ruoli (RBAC, Role-Based Access Control) e può essere limitato come gli account di servizio Google Cloud.

Se l'agente è autorizzato a impersonare l'identità richiesta, il server API quindi esegue autorizzazione verifica l'account di servizio Google Cloud e gestisce la richiesta. La dell'audit log per la richiesta include sia l'identità dell'agente sia ha impersonato l'account di servizio Google Cloud.

Sicurezza nel cluster

Infine, l'agente invia le richieste API Kubernetes API di Kubernetes, come illustrato nel diagramma seguente.

Architettura delle richieste API di Kubernetes inviate al server API Kubernetes (fai clic per ingrandire)

Il server API Kubernetes autentica, autorizza e autentica per queste richieste, così come avviene per tutte le altre richieste che gestisce.

Come proxy per queste richieste, l'agente ha accesso a dati sensibili, credenziali, richieste e risposte. Kubernetes e l'ecosistema Kubernetes mettono a disposizione una serie di strumenti per impedire ad altri soggetti di ottenere tale accesso e per per fare in modo che l'agente acceda solo a ciò che dovrebbe.

Autenticazione Kubernetes

Il server API Kubernetes autentica il mittente di ogni messaggio in entrata per stabilire quali autorizzazioni applicare nella fase di autorizzazione. Come descritto in precedenza, la richiesta include le credenziali di un utente include le credenziali Kubernetes e le intestazioni di rappresentazione dell'agente.

Gli amministratori dei cluster mantengono il controllo dei meccanismi di autenticazione riconosciuti il server API Kubernetes. Gli amministratori potrebbero essere in grado di revocare le credenziali dell'agente e può revocare o ridurre il privilegio e credenziali.

Autorizzazione Kubernetes

Il server API di Kubernetes controlla che l'identità autenticata sia autorizzato 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 funziona a qualsiasi controllo delle autorizzazioni per conto del cluster.

Sicurezza degli agenti

L'agente ha accesso alle proprie credenziali (Kubernetes e Google Cloud), nonché le credenziali, le richieste e le risposte che lo attraversano. Come l'agente occupa una posizione attendibile in un cluster connesso.

L'agente è progettato con i seguenti concetti fondamentali sulla sicurezza:

• L'agente è scritto in Vai, che fornisce la gestione della memoria garbage collection e impedisce a molte non sicuro le operazioni di memoria.
• Il deployment dell'agente è stato eseguito in senza distro nell'immagine container. L'immagine dell'agente non include un shell, libc o altro codice estraneo al percorso di esecuzione dell'agente.
• L'immagine dell'agente viene creata dall'infrastruttura di build condivisa di Google il codice di registrazione. Solo questo sistema di compilazione può eseguire il deployment delle immagini dell'agente in Container Registry. Gli sviluppatori Google Cloud non possono eseguire autonomamente il deployment di nuove immagini. Questo aiuta a garantire che tutte le modifiche all'origine dell'agente possano essere rintracciate all'autore e al recensore per non essere ripudiati.

L'agente viene eseguito deployment in un cluster Kubernetes di cui viene eseguito il deployment nel momento in cui registri il cluster. Di conseguenza, tutte le opzioni e le best practice disponibili per il monitoraggio e per proteggere i deployment, ReplicaSets e i pod.

Questi meccanismi sono progettati per rendere difficile la compromissione dell’agente containerizzato. Tuttavia, l'accesso privilegiato al nodo dell'agente può comunque essere compromesso dell'ambiente dell'agente; perciò è importante che gli amministratori linee guida di sicurezza standard di Kubernetes per la protezione dell'infrastruttura del cluster.

Sicurezza dei dati con i Controlli di servizio VPC

I Controlli di servizio VPC forniscono un ulteriore livello di protezione per Servizi Google Cloud indipendenti da Identity and Access Management (IAM). Sebbene IAM consenta un livello di analisi granulare dei controlli degli accessi, Controlli di servizio VPC consente un perimetro basato sul contesto , incluso il controllo del traffico in uscita dei dati attraverso il perimetro, Ad esempio, puoi specificare che solo alcuni progetti possano accedere Dati BigQuery. Scopri di più su come funzionano i Controlli di servizio VPC per proteggere i tuoi dati nella Panoramica dei Controlli di servizio VPC.

Puoi utilizzare Controlli di servizio VPC con Connect per una maggiore sicurezza dei dati, una volta assicurato che i servizi necessari per usare Connect possano essere a cui si accede dall'interno del perimetro di servizio specificato.

Se vuoi utilizzare Controlli di servizio VPC, devi abilitare le seguenti API:

• cloudresourcemanager.googleapis.com
• gkeconnect.googleapis.com
• gkehub.googleapis.com

Devi anche impostare le impostazioni private connettività per l'accesso le API pertinenti. Puoi scoprire come farlo nell'articolo Imposta come privato per la connettività.