Funzionalità di sicurezza connesse

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 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 fornisce quanto segue con economie di scala e tra i provider:

• Gestione multi-cluster e visibilità dei cluster
• Deployment e gestione del ciclo di vita dei servizi applicativi

Questo documento tratta i seguenti argomenti:

• In che modo la progettazione di Connect mette la sicurezza al primo posto
• Best practice per il deployment dell'agente Connect
• Come migliorare la security posture del deployment di Kubernetes

Architettura di Connect

Connect consente agli utenti finali e ai Google Cloud servizi di accedere ai server API Kubernetes che non si trovano su internet pubblico. L'agente Connect viene eseguito in nel cluster Kubernetes (un agente per cluster) e si connette a un proxy Connect. Google Cloud I servizi 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 illustrato nel seguente diagramma.

Architettura di come gli utenti accedono ai server API Kubernetes che non si trovano su internet (fai clic per ingrandire)

Quando l'agente viene sottoposto a deployment, stabilisce una connessione TLS 1.2+ persistente per Google Cloud attendere le richieste. Google Cloud I servizi, se abilitati dagli amministratori, possono generare richieste per i cluster Kubernetes. Queste richieste potrebbero provenire anche dall'interazione utente diretta con la Google Cloud console, Connect Gateway o altri servizi Google.

Il Google Cloud servizio invia la richiesta al proxy. Il proxy inoltra quindi la richiesta all'agente sottoposto a 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 logging di controllo di Kubernetes e restituisce una risposta. La risposta viene restituita tramite l'agente e il proxy al Google Cloud servizio. In ogni passaggio della procedura, 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 logging di controllo a tutte le richieste, incluse quelle tramite Connect. Questa procedura ti garantisce il controllo dell'accesso al cluster.

Connect e difesa in profondità

La difesa in profondità è intrinseca a tutto ciò che Google Cloud fa Google all'interno della sua infrastruttura e delle sue 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. Questo è lo stesso principio in base al quale abbiamo progettato Connect.

Oltre alla strategia e alla progettazione di difesa in profondità di Google, devi valutare i contenuti forniti qui insieme alla tua security posture e ai tuoi standard. Questa sezione illustra le misure aggiuntive che puoi adottare e che completano 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 autenticati e autorizzati per questi dati, come illustrato nel seguente diagramma.

Architettura di come i componenti di Connect eseguono l'autenticazione (fai clic per ingrandire)

Ogni componente di una richiesta Connect utilizza quanto segue per autenticare gli altri componenti:

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

Ogni componente di una richiesta Connect utilizza quanto segue per autorizzare gli altri componenti:

• 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 consente di garantire che tutte le credenziali dei token siano criptate durante il transito e ricevute solo da peer autenticati e autorizzati.

Autenticazione utente a Google Google Cloud

Quando utilizzano la Google Cloud console, gli utenti seguono il flusso di accesso standard di Google. Google Cloud fornisce un certificato TLS che il browser dell'utente autentica e l'utente accede a un account Google Cloud o Google Workspace per autenticarsi a Google Cloud.

L'accesso a un progetto tramite la Google Cloud console o altre API è controllato dalle autorizzazioni IAM.

Google Cloud Autenticazione da servizio a servizio

Google Cloud Google utilizza ALTS per l'autenticazione interna da servizio a servizio. ALTS consente ai servizi, come il proxy, di creare una connessione autenticata e protetta dall'integrità. Google Cloud

Google Cloud I servizi 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 Google Cloud

L'agente utilizza TLS per autenticare e criptare ogni connessione. L'agente autentica Google Cloud i certificati TLS utilizzando un insieme di certificati radice integrati nel file binario, per evitare di considerare attendibili inavvertitamente i certificati aggiunti al container dell'agente. L'agente esegue solo chiamate API su endpoint autenticati correttamente. Questa procedura consente di garantire che i certificati dei service account e le richieste API Kubernetes vengano inviati da Google CloudGoogle e che le risposte vengano inviate solo a Google CloudGoogle.

Per l'elenco dei domini con cui l'agente comunica durante il normale funzionamento, consulta Assicurati della 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 sul 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 Google Cloud non sono interessate.

Autenticazione dell'agente

L'agente esegue l'autenticazione a Google Cloud utilizzando la federazione delle identità per i workload del parco risorse. La federazione delle identità per i workload del parco risorse consente di eseguire l'autenticazione dai carichi di lavoro del parco risorse alle Google Cloud API utilizzando i meccanismi di autenticazione integrati Google Cloud e Kubernetes. Quando l'agente vuole eseguire l'autenticazione a Google Cloud, scambia il token del service account Kubernetes con un token di accesso che rappresenta la sua identità del carico di lavoro.

Server API Kubernetes

L'agente utilizza la libreria client 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.

Sicurezza delle richieste

Ogni richiesta inviata da Google Cloud tramite Connect include le credenziali che identificano il mittente della richiesta: sia il Google Cloud servizio che ha generato la richiesta sia (se applicabile) l'utente finale per il quale viene inviata la richiesta. Queste credenziali consentono al server API Kubernetes di fornire controlli di autorizzazione e audit per ogni richiesta.

Autenticazione da servizio ad agente

Ogni richiesta inviata all'agente include un token di breve durata che identifica il Google Cloud servizio che ha inviato la richiesta, come illustrato nel seguente diagramma.

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

Il token è firmato da un Google Cloud service account associato esclusivamente al Google Cloud servizio. L'agente recupera le chiavi pubbliche del service account per convalidare il token. Questo token non viene inoltrato al server API.

L'agente convalida Google Cloud i certificati utilizzando le radici CA incorporate nel file binario. Questa procedura consente di garantire che riceva richieste autentiche e non modificate da Google Cloud.

Autenticazione degli utenti finali

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

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

Questo criterio consente di garantire che all'utente venga applicato lo stesso insieme di autorizzazioni quando accede tramite Connect. Alcuni Google Cloud servizi eseguono l'autenticazione al server API per conto di un utente. Ad esempio, un utente può accedere alla Google Cloud console per visualizzare i carichi di lavoro nei cluster registrati nel parco risorse. Quando un utente accede a questi servizi, fornisce le credenziali riconosciute dal server API Kubernetes: uno qualsiasi dei token supportati dal server API Kubernetes.

La Google Cloud console memorizza queste credenziali come parte del profilo di un utente. Queste credenziali vengono criptate durante il riposo, sono accessibili solo con le credenziali dell'utente's Google Cloud o di Google Workspace e vengono utilizzate solo per le connessioni tramite Connect. Queste credenziali non possono essere scaricate di nuovo. Le credenziali vengono eliminate quando l'utente esce 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 dei dati su Google Cloud Google.

Quando un utente interagisce con la Google Cloud console, questa genera richieste per il server API Kubernetes. Il servizio invia le credenziali dell'utente insieme alla richiesta tramite Connect. L'agente presenta quindi 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, genera 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 gli stessi criteri di autorizzazione e audit per le richieste Connect come per le altre richieste.

Autenticazione da servizio a Kubernetes

Google Cloud I servizi che accedono al server API Kubernetes al di fuori del contesto di un utente utilizzano la rappresentazione di Kubernetes per l'autenticazione al server API Kubernetes. Questo metodo consente al server API Kubernetes di fornire controlli di autorizzazione e logging di controllo per servizio, come illustrato nel seguente diagramma.

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

I servizi di Google possono utilizzare Connect al di fuori del contesto di un utente. Google Cloud Ad esempio, un servizio Ingress multi-cluster può sincronizzare automaticamente le risorse Ingress 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 Google Cloud le credenziali del servizio. Tuttavia, un server API può delegare privilegi di autenticazione limitati a un altro servizio tramite la rappresentazione e l'agente può autenticare i servizi che inviano richieste tramite Connect. Google Cloud Insieme, questi consentono alle richieste tramite l'agente di autenticarsi come Google Cloud service account.

Quando un Google Cloud servizio invia una richiesta per proprio conto (anziché nel contesto di un utente), l'agente aggiunge alla richiesta le proprie credenziali Kubernetes, e intestazioni di rappresentazione di Kubernetes che identificano il Google Cloud servizio. Le intestazioni di rappresentazione rivendicano un nome utente del Google Cloud service account autenticato dall'agente.

Il server API Kubernetes autentica le credenziali dell'agente e verifica anche che l'agente possa rappresentare il Google Cloud service account. La possibilità di rappresentare è in genere controllata dalle regole di controllo dell'accesso basato sui ruoli (RBAC) e può essere limitata a identità specifiche, come i Google Cloud service account.

Se l'agente è autorizzato a rappresentare l'identità richiesta, il server API esegue quindi i controlli di autorizzazione per il Google Cloud service account e gestisce la richiesta. Il log di controllo per la richiesta include sia l'identità dell'agente sia il service account rappresentato Google Cloud .

Sicurezza nel cluster

L'agente invia infine le richieste API Kubernetes al server API Kubernetes, come illustrato nel seguente diagramma.

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

Il server API Kubernetes autentica, autorizza e registra queste richieste, proprio come fa 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 attori di ottenere questo accesso e per 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 le autorizzazioni da applicare nella fase di autorizzazione. Come descritto in precedenza, la richiesta include le credenziali di un utente oppure le credenziali Kubernetes dell'agente e le intestazioni di rappresentazione.

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 il privilegio delle credenziali dell'agente.

Autorizzazione Kubernetes

Il server API Kubernetes verifica 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 dell'agente

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

L'agente è progettato con i seguenti principi fondamentali di sicurezza:

• 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 sottoposto a deployment in un' immagine container senza distribuzione. L'immagine dell'agente non include una 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 archiviato. Solo questo sistema di compilazione può eseguire il deployment delle immagini dell'agente in Container Registry. Google Cloud Gli sviluppatori non possono eseguire il deployment di nuove immagini autonomamente. Questa procedura consente di garantire che tutte le modifiche all'origine dell'agente possano essere ricondotte a un autore e a un revisore per il non ripudio.

L'agente viene eseguito come deployment standard in un cluster Kubernetes che viene sottoposto a deployment al momento della registrazione del 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 per rendere difficile la compromissione del container dell'agente. Tuttavia, l'accesso con privilegi al nodo dell'agente può comunque compromettere l'ambiente dell'agente; pertanto, è importante che gli amministratori seguano le linee guida standard di sicurezza 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 Google Cloud i servizi, indipendente da Identity and Access Management (IAM). Mentre IAM consente un controllo dell'accesso basato sull'identità granulare, i Controlli di servizio VPC consentono una sicurezza perimetrale basata sul contesto più ampia, che include il controllo dell'uscita dei dati dal perimetro. Ad esempio, puoi specificare che solo determinati progetti possono accedere ai tuoi dati BigQuery. Per saperne di più su come i Controlli di servizio VPC proteggono i tuoi dati, consulta la panoramica dei Controlli di servizio VPC Overview.

Puoi utilizzare i 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 i Controlli di servizio VPC, devi abilitare le seguenti API:

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

Devi anche configurare la connettività privata per l'accesso alle API pertinenti. Scopri come farlo in Configura la connettività privata.