Questo documento illustra le misure di sicurezza integrate in Connect.
Una piattaforma ibrida e multi-cloud efficace offre gestione centralizzata, observability e accesso ai servizi in tutti gli ambienti. GKE Enterprise offre un'esperienza uniforme e completa per queste funzionalità, indipendentemente dal provider Kubernetes che utilizzi. Connect è un agente leggero che offre quanto segue a economie di scala e tra fornitori:
- Gestione multi-cluster e visibilità dei cluster
- Deployment e gestione del ciclo di vita dei servizi di applicazioni
Questo documento illustra quanto segue:
- In che modo il design di Connect mette la sicurezza al primo posto
- Best practice per l'implementazione di Connect Agent
- Come migliorare la strategia di sicurezza del 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 Connect. 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, le inoltra al server API Kubernetes, come mostrato nel seguente diagramma.
Quando viene eseguito il deployment dell'agente, viene stabilita una connessione TLS 1.2 o successiva persistente con Google Cloud per attendere le richieste. I servizi Google Cloud, se abilitati dagli amministratori, possono generare richieste per i tuoi cluster Kubernetes. Queste richieste potrebbero anche derivare 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 poi forwarda la richiesta all'agente di cui è stato eseguito il deployment responsabile di un cluster e infine l'agente la inoltra al server API Kubernetes. Il server dell'API Kubernetes applica i criteri di autenticazione, autorizzazione e di logging di controllo di Kubernetes e restituisce una risposta. La risposta viene riassegnata tramite l'agente e il proxy al servizio Google Cloud. In ogni fase del processo, i componenti eseguono l'autenticazione e l'autorizzazione per connessione e per richiesta.
Il server dell'API Kubernetes applica gli stessi criteri di autenticazione, autorizzazione e registrazione dei controlli a tutte le richieste, incluse quelle tramite Connect. Questa procedura ti garantisce sempre il controllo dell'accesso al cluster.
Connettiti e difesa in profondità
La difesa in profondità è intrinseca a tutto ciò che fa Google Cloud all'interno della propria infrastruttura e delle proprie pratiche di sicurezza. Adottiamo un approccio a più livelli per ogni aspetto della protezione della nostra organizzazione e dei nostri clienti al fine di proteggere dati, informazioni e utenti di valore. È lo stesso principio su cui abbiamo progettato Connect.
Oltre alla strategia e al design di difesa in profondità di Google, devi valutare i contenuti forniti qui insieme alla tua posizione di sicurezza e ai tuoi standard. Questa sezione illustra le misure aggiuntive che puoi adottare per integrare le best practice di hardening di Kubernetes.
Sicurezza da componente a componente
Ogni componente di una richiesta Connect autentica i suoi peer e condivide i dati solo con i peer che sono sia autenticati sia autorizzati per quei dati, come illustrato nel seguente diagramma.
Ogni componente di una richiesta di connessione utilizza quanto segue per autenticarsi tra di loro:
- 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. Questa procedura contribuisce ad assicurare che tutte le credenziali dei token siano criptate durante il transito e ricevute solo da peer autenticati e autorizzati.
Autenticazione utente in Google Cloud
Quando utilizzano la console Google Cloud, gli utenti devono seguire il flusso di accesso standard di Google. Google Cloud fornisce un certificato TLS che viene autenticato dal browser dell'utente, che accede a un account Google Cloud o Google Workspace per autenticarsi su Google Cloud.
L'accesso a un progetto tramite la console Google Cloud o altre API è controllato dalle autorizzazioni IAM.
Autenticazione di servizio a servizio di Google Cloud
Google Cloud utilizza ALTS per l'autenticazione da un servizio all'altro interna. ALTS consente ai servizi Google Cloud, come il proxy, di creare una connessione autenticata e protetta dall'integrità.
I servizi Google Cloud devono essere autorizzati internamente a utilizzare il proxy per connettersi a un'istanza Connect remota perché 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 insieme di certificati radice incorporati nel file binario per evitare di considerare attendibili inavvertitamente i certificati aggiunti al contenitore dell'agente. L'agente esegue chiamate API solo su endpoint autenticati correttamente. Questa procedura contribuisce a garantire che i certificati dell'account servizio e le richieste dell'API Kubernetes vengano inviati da Google Cloud e che 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 si connetta a Google Cloud tramite un proxy HTTP. In questa configurazione, l'agente utilizza HTTP/1.1
CONNECT contro il proxy HTTP e stabilisce una connessione TLS con 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 si autentica in Google Cloud utilizzando un 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 si assume la responsabilità della privacy della chiave. Quando l'agente si connette a Google Cloud, si autentica 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 disponga dell'autorizzazione IAM gkehub.endpoints.connect nel progetto. In genere questa autorizzazione viene 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 Kubernetes per creare una connessione TLS al server API Kubernetes. Il runtime Kubernetes fornisce al contenitore 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 le credenziali che identificano il mittente della richiesta: sia il servizio Google Cloud che ha generato la richiesta sia, se applicabile, l'utente finale per cui viene inviata la richiesta. Queste credenziali consentono al server API Kubernetes di fornire controlli di autorizzazione e auditing 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 seguente diagramma.
Il token è firmato da un account di servizio Google Cloud associato esclusivamente al servizio Google Cloud. L'agente recupera 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 CA radice incorporate nel codice binario. Questo processo contribuisce ad assicurare che vengano ricevute richieste autentiche e non alterate 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 autenticarsi al server API, come illustrato nel seguente diagramma.
Questo criterio contribuisce a garantire che all'utente venga applicato lo stesso insieme di autorizzazioni quando accede tramite Connect. Alcuni servizi Google Cloud si autenticano al 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 in Fleet. Quando un utente accede a questi servizi, fornisce le credenziali riconosciute dal server API Kubernetes: qualsiasi token supportato dal server API Kubernetes.
La console Google Cloud memorizza queste credenziali nel profilo di un utente. Queste credenziali sono criptate a riposo, 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 viene eliminato l'account utente. Per ulteriori informazioni, consulta Eliminazione dei 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 poi presenta la richiesta e le credenziali al server API Kubernetes.
Il server API Kubernetes autentica le credenziali dell'utente, esegue l'autorizzazione per l'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 lo stesso criterio di autorizzazione e controllo per le richieste Connect come per le 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 l'usurpazione di identità di Kubernetes per autenticarsi al server API Kubernetes. Questo metodo consente al server API Kubernetes di fornire controlli di autorizzazione per servizio e registrazione di controllo, come illustrato nel seguente diagramma.
I servizi di Google Cloud possono utilizzare Connect al di fuori del contesto di un utente. Ad esempio, un servizio di importazione multi-cluster può sincronizzare automaticamente le risorse di importazione tra i cluster. Questi servizi non dispongono di 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 sostituzione di identità e l'agente può autenticare i servizi Google Cloud inviando richieste tramite Connect. Insieme, 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 di Kubernetes che identificano il servizio Google Cloud. Le intestazioni di rappresentazione usurpata rivendicano un nome utente dell'account di servizio Google Cloud autenticato dall'agente.
Il server API Kubernetes autentica le credenziali dell'agente e controlla anche che l'agente possa rubare l'identità dell'account di servizio Google Cloud. La possibilità di rubare l'identità è in genere controllata dalle regole controllo dell'accesso basato su ruoli (RBAC) e può essere limitata a identità specifiche, come gli account di servizio Google Cloud.
Se l'agente è autorizzato a rubare l'identità richiesta, il server API esegue controlli di autorizzazione per l'account di servizio Google Cloud e gestisce la richiesta. Il log di controllo per la richiesta include sia l'identità dell'agente sia l'account di servizio Google Cloud impersonato.
Sicurezza in-cluster
L'agente invia infine le richieste API Kubernetes al server API Kubernetes, come illustrato nel seguente diagramma.
Il server API Kubernetes autentica, autorizza e registra come audit queste richieste, come per tutte le altre richieste che gestisce.
In qualità di proxy per queste richieste, l'agente ha accesso a dati sensibili, come credenziali, richieste e risposte. Kubernetes e l'ecosistema Kubernetes forniscono un insieme di strumenti per impedire ad altri utenti di ottenere questo accesso e per contribuire a garantire che l'agente acceda solo a ciò che deve.
Autenticazione Kubernetes
Il server API Kubernetes autentica il mittente di ogni richiesta in entrata per determinare le autorizzazioni da applicare nella fase di autorizzazione. Come описано ранее, la richiesta include le credenziali di un utente o le credenziali Kubernetes e le intestazioni di rappresentazione dell'agente.
Gli amministratori del 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 di revocare o ridurre il privilegio delle credenziali dell'agente.
Autorizzazione Kubernetes
Il server dell'API Kubernetes controlla che l'identità autenticata sia autorizzata a eseguire l'azione richiesta sulla risorsa richiesta.
L'amministratore del cluster può utilizzare uno dei meccanismi di autorizzazione 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 principi di sicurezza di base:
- L'agente è scritto in Go, che fornisce la gestione della memoria con garbage collection e impedisce molte operazioni di memoria non sicure.
- L'agente viene disegnato in un'immagine container senza distribuzione. 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 dal codice sottoposto a check-in. Solo questo sistema di compilazione può eseguire il deployment delle immagini dell'agente in Container Registry. Gli sviluppatori di Google Cloud non possono eseguire il deployment di nuove immagini autonomamente. Questa procedura contribuisce a garantire che tutte le modifiche all'origine dell'agente possano essere ricondotte a un autore e a un revisore per la non ripudio.
L'agente viene eseguito come deployment standard in un cluster Kubernetes di cui viene eseguito il deployment al momento della registrazione.
Di conseguenza, tutte le opzioni e le best practice disponibili per il monitoraggio e la protezione di deployment, ReplicaSets e pod sono disponibili per l'agente.
Questi meccanismi sono progettati per rendere difficile la compromissione del contenitore 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 livello aggiuntivo di difesa della sicurezza per i servizi Google Cloud indipendente da Identity and Access Management (IAM). Sebbene IAM consenta un controllo dell'accesso basato sull'identità granulare, i Controlli di servizio VPC consentono una sicurezza del perimetro basata sul contesto più ampia, incluso il controllo dell'esportazione dei dati all'interno del perimetro. Ad esempio, puoi specificare che solo determinati progetti possono accedere ai tuoi dati BigQuery. Per scoprire di più sul funzionamento dei Controlli di servizio VPC per proteggere i tuoi dati, consulta la Panoramica dei 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 possano essere accesi dal perimetro di servizio specificato.
Se vuoi utilizzare Controlli di servizio VPC, devi abilitare le seguenti API:
cloudresourcemanager.googleapis.comgkeconnect.googleapis.comgkehub.googleapis.com
Devi anche configurare la connettività privata per accedere alle API pertinenti. Scopri come farlo in Configurare la connettività privata.