Best practice per la sicurezza di Cloud Service Mesh

Questo documento descrive le best practice per stabilire e governare una configurazione sicura di Cloud Service Mesh in esecuzione su Google Kubernetes Engine (GKE). Le indicazioni riportate nel documento vanno oltre le impostazioni utilizzate per configurare e installare Cloud Service Mesh e descrivono come utilizzare Cloud Service Mesh con altri prodotti e funzionalità di Google Cloud per proteggerti dalle minacce alla sicurezza che le applicazioni in un mesh potrebbero dover affrontare.

Il pubblico di destinazione di questo documento include gli amministratori che gestiscono i criteri in un Cloud Service Mesh e gli utenti che eseguono servizi in un Cloud Service Mesh. Le misure di sicurezza descritte qui sono utili anche per le organizzazioni che devono migliorare la sicurezza dei propri mesh di servizi per soddisfare i requisiti di conformità.

Il documento è organizzato come segue:

Introduzione

Cloud Service Mesh fornisce funzionalità e strumenti che ti aiutano a osservare, gestire e difendere i servizi in modo unificato. Adotta un approccio incentrato sulle applicazioni e utilizza identità delle applicazioni attendibili anziché un approccio incentrato sull'IP di rete. Puoi eseguire il deployment di un mesh di servizi in modo trasparente senza dover modificare il codice dell'applicazione esistente. Cloud Service Mesh fornisce un controllo dichiarativo sul comportamento della rete, il che consente di disaccoppiare il lavoro dei team responsabili della pubblicazione e del rilascio delle funzionalità dell'applicazione dalle responsabilità degli amministratori responsabili della sicurezza e del networking.

Cloud Service Mesh si basa sul mesh di servizi Istio open source, che consente configurazioni e topologie sofisticate. A seconda della struttura della tua organizzazione, uno o più team o ruoli potrebbero essere responsabili dell'installazione e della configurazione di una mesh. Le impostazioni predefinite di Cloud Service Mesh vengono scelte per proteggere le applicazioni, ma in alcuni casi potresti aver bisogno di configurazioni personalizzate o di concedere eccezioni escludendo determinate app, porte o indirizzi IP dalla partecipazione a un mesh. È importante disporre di controlli per gestire le configurazioni mesh e le eccezioni di sicurezza.

Vettori di attacco e rischi per la sicurezza

Vettori di attacco

La sicurezza di Cloud Service Mesh segue il modello di sicurezza Zero Trust, che presuppone che le minacce alla sicurezza provengano sia dall'interno sia dall'esterno del perimetro di sicurezza di un'organizzazione. Ecco alcuni esempi di tipi di attacchi alla sicurezza che possono rappresentare una minaccia per le applicazioni in un mesh di servizi:

  • Attacchi di esfiltrazione di dati. Ad esempio, attacchi che intercettano dati sensibili o credenziali dal traffico tra servizi.
  • Attacchi man-in-the-middle. Ad esempio, un servizio dannoso che si spaccia per un servizio legittimo per ottenere o modificare la comunicazione tra i servizi.
  • Attacchi di escalation dei privilegi. Ad esempio, attacchi che utilizzano l'accesso illecito a privilegi elevati per eseguire operazioni in una rete.
  • Attacchi Denial of Service (DoS).
  • Attacchi di botnet che tentano di compromettere e manipolare i servizi per lanciare attacchi su altri servizi.

Gli attacchi possono essere classificati anche in base ai target:

  • Attacchi alla rete interna mesh. Attacchi volti a manomettere, intercettare o falsificare la comunicazione da servizio a servizio o da servizio a piano di controllo interna al mesh.
  • Attacchi al piano di controllo. Attacchi volti a causare il malfunzionamento del piano di controllo (ad esempio un attacco DoS) o a esfiltrare dati sensibili dal piano di controllo.
  • Attacchi ai bordi della maglia. Attacchi volti a manomettere, intercettare o falsificare la comunicazione all'ingresso o all'uscita della rete mesh.
  • Attacchi alle operazioni di Mesh. Attacchi mirati alle operazioni del mesh. Gli utenti malintenzionati possono tentare di ottenere privilegi elevati per eseguire operazioni dannose in un mesh, ad esempio modificare i criteri di sicurezza e le immagini dei carichi di lavoro.

Rischi per la sicurezza

Oltre agli attacchi alla sicurezza, una rete mesh presenta anche altri rischi per la sicurezza. L'elenco seguente descrive alcuni possibili rischi per la sicurezza:

  • Protezione di sicurezza incompleta. Non è stato configurato un mesh di servizi con criteri di autenticazione e autorizzazione per proteggerne la sicurezza. Ad esempio, non sono definiti criteri di autenticazione o autorizzazione per i servizi in un mesh.
  • Eccezioni ai criteri di sicurezza. Per soddisfare i loro casi d'uso specifici, gli utenti possono creare eccezioni ai criteri di sicurezza per escludere determinati tipi di traffico (interno o esterno) dai criteri di sicurezza di Cloud Service Mesh. Per gestire in modo sicuro questi casi, consulta la sezione Gestire in modo sicuro le eccezioni alle norme.
  • Mancata attenzione agli upgrade delle immagini. Potrebbero essere rilevate vulnerabilità per le immagini utilizzate in una mesh. Devi mantenere aggiornate le immagini del componente mesh e del carico di lavoro con le correzioni delle vulnerabilità più recenti.
  • Mancanza di manutenzione (nessuna competenza o risorse). Il software e le configurazioni dei criteri della rete mesh richiedono una manutenzione regolare per sfruttare i meccanismi di protezione della sicurezza più recenti.
  • Mancanza di visibilità. Le configurazioni errate o non sicure dei criteri di mesh e le operazioni/il traffico anomalo del mesh non vengono portate all'attenzione degli amministratori di mesh.
  • Spostamento della configurazione. La configurazione dei criteri in una mesh si discosta dalla fonte attendibile.

Misure per proteggere un mesh di servizi

Questa sezione presenta un manuale operativo per la protezione dei mesh di servizi.

Architettura di sicurezza

La sicurezza di un mesh di servizi dipende dalla sicurezza dei componenti a diversi livelli del sistema mesh e delle relative applicazioni. L'intenzione di alto livello della postura di sicurezza proposta di Cloud Service Mesh è proteggere un servizio mesh tramite l'integrazione di più meccanismi di sicurezza a diversi livelli, che garantiscono congiuntamente la sicurezza complessiva del sistema in base al modello di sicurezza Zero Trust. Il seguente diagramma mostra la posizione di sicurezza proposta di Cloud Service Mesh.

la postura di sicurezza di Cloud Service Mesh

Cloud Service Mesh fornisce sicurezza a più livelli, tra cui:

  • Sicurezza perimetrale del mesh
    • La sicurezza di Cloud Service Mesh Ingress fornisce il controllo dell'accesso per il traffico esterno e protegge l'accesso esterno alle API esposte dai servizi nel mesh.
    • La sicurezza in uscita di Cloud Service Mesh regola il traffico in uscita dai workload interni.
    • L'autenticazione utente di Cloud Service Mesh si integra con l'infrastruttura di Google per autenticare le chiamate esterne dai browser web ai servizi che eseguono applicazioni web.
    • La gestione dei certificati dei gateway di Cloud Service Mesh protegge e ruota le chiavi private e i certificati X.509 utilizzati dai gateway di ingresso e di uscita di Cloud Service Mesh utilizzando Certificate Authority Service.
    • Cloud Armor può difendere da attacchi DDoS (Distributed Denial of Service) esterni e di livello 7. Funge da web application firewall (WAF) per proteggere il mesh dagli attacchi alla rete. Ad esempio, attacchi di esecuzione di codice remoto e di attacco di inserimento.
    • VPC e Controlli di servizio VPC proteggono il confine del mesh tramite i controlli di accesso alla rete privata.
  • Sicurezza del cluster
    • TLS reciproco (mTLS) di Cloud Service Mesh applica la crittografia e l'autenticazione del traffico da workload a workload.
    • L'autorità di certificazione gestita, come l'autorità di certificazione Cloud Service Mesh e Certificate Authority Service, esegue il provisioning e la gestione in sicurezza dei certificati utilizzati dai workload.
    • L'autorizzazione Cloud Service Mesh applica controllo dell'accesso per i servizi mesh in base alle loro identità e ad altri attributi.
    • La dashboard della sicurezza di GKE Enterprise consente di monitorare le configurazioni dei criteri di sicurezza e dei criteri di rete Kubernetes per i carichi di lavoro.
    • La policy di rete Kubernetes applica controllo dell'accesso ai pod in base a indirizzi IP, etichette dei pod, spazi dei nomi e altro ancora.
    • La sicurezza del piano di controllo protegge dagli attacchi al piano di controllo. Questa protezione impedisce agli utenti malintenzionati di modificare, sfruttare o divulgare i dati di configurazione del servizio e del mesh.
  • Sicurezza del carico di lavoro
    • Mantieni aggiornate le release di sicurezza di Cloud Service Mesh per assicurarti che i file binari di Cloud Service Mesh in esecuzione nel tuo mesh siano privi di vulnerabilità note pubblicamente.
    • Workload Identity Federation for GKE consente ai carichi di lavoro di ottenere le credenziali per chiamare in modo sicuro i servizi Google.
    • Cloud Key Management Service (Cloud KMS) protegge le credenziali o i dati sensibili tramite moduli di sicurezza hardware (HSM). Ad esempio, i carichi di lavoro possono utilizzare Cloud KMS per archiviare credenziali o altri dati sensibili. Il servizio CA, utilizzato per emettere certificati per i carichi di lavoro mesh, supporta chiavi di firma per cliente e basate su HSM gestite da Cloud KMS.
    • CNI (Container Network Interface) di Kubernetes impedisce gli attacchi di escalation dei privilegi eliminando la necessità di un contenitore di inizializzazione Cloud Service Mesh con privilegi.
  • Sicurezza dell'operatore
    • Controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes limita l'accesso alle risorse Kubernetes e confina le autorizzazioni degli operatori per mitigare gli attacchi provenienti da operatori malintenzionati o da furti d'identità di operatori.
    • Policy Controller di GKE Enterprise convalida e controlla le configurazioni dei criteri nel mesh per evitare configurazioni errate.
    • Autorizzazione binaria di Google Cloud garantisce che le immagini del workload nel mesh siano quelle autorizzate dagli amministratori.
    • L'audit logging di Google Cloud controlla le operazioni del mesh.

Il diagramma seguente mostra i flussi di comunicazione e configurazione con le soluzioni di sicurezza integrate in Cloud Service Mesh.

security diagram traffic flow

Sicurezza del cluster

Attivare TLS reciproco rigoroso

Un attacco man in the middle (MitM) tenta di inserire un'entità dannosa tra due parti in comunicazione per intercettare o manipolare la comunicazione. Cloud Service Mesh protegge dagli attacchi man in the middle e di esfiltrazione di dati applicando l'autenticazione e la crittografia mTLS per tutte le parti che comunicano. La modalità permissiva utilizza mTLS se entrambe le parti lo supportano, ma consente le connessioni senza mTLS. Al contrario, mTLS restrittivo richiede che il traffico sia criptato e autenticato con mTLS e non consente il traffico in testo normale.

Cloud Service Mesh ti consente di configurare la versione TLS minima per le connessioni TLS tra i tuoi workload per soddisfare i tuoi requisiti di sicurezza e conformità.

Per saperne di più, consulta Cloud Service Mesh tramite esempi: mTLS | Applicazione di mTLS a livello di mesh.

Attivare i controlli di accesso

I criteri di sicurezza di Cloud Service Mesh (ad esempio i criteri di autenticazione e autorizzazione) devono essere applicati a tutto il traffico in entrata e in uscita dal mesh, a meno che non esistano giustificazioni valide per escludere un servizio o un pod dai criteri di sicurezza di Cloud Service Mesh. In alcuni casi, gli utenti potrebbero avere motivi legittimi per bypassare i criteri di sicurezza di Cloud Service Mesh per alcune porte e intervalli IP. Ad esempio, per stabilire connessioni native con servizi non gestiti da Cloud Service Mesh. Per difendere Cloud Service Mesh in questi casi d'uso, consulta Gestire in modo sicuro le eccezioni ai criteri di Cloud Service Mesh.

Il controllo dell'accesso ai servizi è fondamentale per impedire l'accesso non autorizzato ai servizi. L'applicazione di mTLS cripta e autentica una richiesta, ma un mesh ha comunque bisogno di criteri di autorizzazione Cloud Service Mesh per applicare controllo dell'accesso dell'accesso ai servizi. Ad esempio, il rifiuto di una richiesta non autorizzata proveniente da un client autenticato.

I criteri di autorizzazione di Cloud Service Mesh offrono un modo flessibile per configurare i controlli di accesso in modo da proteggere i tuoi servizi da accessi non autorizzati. I criteri di autorizzazione di Cloud Service Mesh devono essere applicati in base alle identità autenticate ricavate dai risultati di autenticazione. Le autenticazioni basate su mTLS o token JWT (JSON Web Token) devono essere utilizzate insieme nell'ambito dei criteri di autorizzazione di Cloud Service Mesh.

Applica i criteri di autenticazione di Cloud Service Mesh

JSON Web Token (JWT)

Oltre all'autenticazione mTLS, gli amministratori della rete mesh possono richiedere a un servizio di autenticare e autorizzare le richieste in base a JWT. Cloud Service Mesh non agisce come provider JWT, ma autentica i JWT in base agli endpoint JWKS (JSON Web Key Set) configurati. L'autenticazione JWT può essere applicata ai gateway di ingresso per il traffico esterno o ai servizi interni per il traffico in-mesh. L'autenticazione JWT può essere combinata con l'autenticazione mTLS quando un JWT viene utilizzato come credenziale per rappresentare l'utente chiamante finale e il servizio richiesto richiede la prova che viene chiamato per conto dell'utente chiamante finale. L'applicazione forzata dell'autenticazione JWT protegge dagli attacchi che accedono a un servizio senza credenziali valide e per conto di un utente finale reale.

Autenticazione utente di Cloud Service Mesh

L'autenticazione utente di Cloud Service Mesh è una soluzione integrata per l'autenticazione degli utenti finali basata su browser e il controllo accessi ai tuoi carichi di lavoro. Integra un mesh di servizi con i provider di identità (IdP) esistenti per implementare un flusso di accesso e consenso OpenID Connect (OIDC) web standard e utilizza i criteri di autorizzazione di Cloud Service Mesh per il controllo dell'accesso.

Applicare i criteri di autorizzazione

I criteri di autorizzazione di Cloud Service Mesh controllano:

  • Chi o cosa è autorizzato ad accedere a un servizio.
  • A quali risorse è possibile accedere.
  • Quali operazioni possono essere eseguite sulle risorse consentite.

I criteri di autorizzazione sono un modo versatile per configurare controllo dell'accesso dell'accesso in base alle identità effettive con cui vengono eseguiti i servizi, alle proprietà del livello di applicazione (livello 7) del traffico (ad esempio le intestazioni delle richieste) e alle proprietà del livello di rete (livelli 3 e 4) come intervalli IP e porte.

I criteri di autorizzazione di Cloud Service Mesh devono essere applicati in base alle identità autenticate ricavate dai risultati dell'autenticazione per proteggersi dall'accesso non autorizzato a servizi o dati.

Per impostazione predefinita, l'accesso a un servizio deve essere negato, a meno che non sia definito esplicitamente un criterio di autorizzazione per consentire l'accesso al servizio. Consulta Best practice per i criteri di autorizzazione per esempi di criteri di autorizzazione che rifiutano le richieste di accesso.

I criteri di autorizzazione devono limitare la fiducia il più possibile. Ad esempio, l'accesso a un servizio può essere definito in base ai singoli percorsi URL esposti da un servizio in modo che solo un servizio A possa accedere al percorso /admin di un servizio B.

I criteri di autorizzazione possono essere utilizzati insieme ai criteri di rete Kubernetes, che operano solo a livello di rete (livello 3 e 4) e controllano l'accesso alla rete per indirizzi IP e porte su pod Kubernetes e spazi dei nomi Kubernetes.

Applicare lo scambio di token per accedere ai servizi mesh

Per difendersi dagli attacchi di replay dei token che rubano i token e li riutilizzano per accedere ai servizi del mesh, un token in una richiesta dall'esterno del mesh deve essere scambiato con un token interno al mesh di breve durata all'estremità del mesh.

Una richiesta dall'esterno del mesh per accedere a un servizio mesh deve includere un token, ad esempio JWT o cookie, per essere autenticata e autorizzata dal servizio mesh. Un token esterno alla mesh potrebbe essere di lunga durata. Per difendersi dagli attacchi di ripetizione dei token, un token esterno al mesh deve essere scambiato con un token interno al mesh di breve durata con un ambito limitato all'ingresso del mesh. Il servizio mesh autentica un token interno al mesh e autorizza la richiesta di accesso in base al token interno al mesh.

Cloud Service Mesh supporta l'integrazione con Identity-Aware Proxy (IAP), che genera un RequestContextToken (un token interno al mesh di breve durata scambiato da un token esterno) utilizzato in Cloud Service Mesh per l'autorizzazione. Con lo scambio di token, gli utenti malintenzionati non possono utilizzare un token rubato nella mesh per accedere ai servizi. L'ambito e la durata limitati del token scambiato riducono notevolmente la possibilità di un attacco di replay del token.

Gestire in modo sicuro le eccezioni ai criteri di Cloud Service Mesh

Potresti avere casi d'uso speciali per il tuo mesh di servizi. Ad esempio, potresti dover esporre una determinata porta di rete al traffico in testo normale. Per supportare scenari di utilizzo specifici, a volte potrebbe essere necessario creare eccezioni per consentire l'esclusione di determinati tipi di traffico interno o esterno dai criteri di sicurezza di Cloud Service Mesh, il che crea problemi di sicurezza.

Potresti avere motivi legittimi per bypassare le norme di sicurezza di Cloud Service Mesh per alcune porte e intervalli IP. Puoi aggiungere annotations (ad esempio excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) ai pod per escludere il traffico dalla gestione da parte del sidecar Envoy. Oltre alle annotazioni per escludere il traffico, puoi bypassare completamente la mesh implementando un'applicazione con l'iniezione di sidecar disattivata. Ad esempio, aggiungendo un'etichetta sidecar.istio.io/inject="false" al pod di applicazioni.

Il bypass dei criteri di sicurezza di Cloud Service Mesh ha un impatto negativo sulla sicurezza complessiva del sistema. Ad esempio, se i criteri di autorizzazione e mTLS di Cloud Service Mesh vengono ignorati per una porta di rete tramite annotazioni, non verrà applicato alcun controllo di accesso per il traffico sulla porta e potrebbero essere possibili intercettazioni o modifiche del traffico. Inoltre, il bypass dei criteri di Cloud Service Mesh influisce anche su criteri non di sicurezza, come i criteri di rete.

Quando il criterio di sicurezza di Cloud Service Mesh viene aggirato per una porta o un indirizzo IP (intenzionalmente o involontariamente), devono essere presenti altre misure di sicurezza per proteggere il mesh e monitorare le eccezioni di sicurezza, le potenziali lacune di sicurezza e lo stato di applicazione della sicurezza complessiva. Per proteggere la tua mesh in questi scenari, puoi:

  • Assicurati che il traffico che aggira i sidecar sia criptato e autenticato in modo nativo per evitare attacchi MITM.
  • Applica i criteri di rete Kubernetes per limitare la connettività delle porte con eccezioni ai criteri (ad esempio, limitare una porta con eccezioni ai criteri per consentire solo il traffico da un altro servizio nello stesso spazio dei nomi) o per consentire il passaggio del traffico solo attraverso le porte con i criteri di sicurezza di Cloud Service Mesh applicati.
  • Applica il controller dei criteri GKE Enterprise per convalidare automaticamente i criteri di Cloud Service Mesh. Ad esempio, puoi imporre che i sidecar di Cloud Service Mesh vengano sempre iniettati nei carichi di lavoro.

Applicare i criteri di rete Kubernetes

Cloud Service Mesh si basa sulla piattaforma di base (ad esempio Kubernetes). Pertanto, la sicurezza di Cloud Service Mesh dipende dalla sicurezza della piattaforma di base. Ad esempio, senza il controllo su chi può aggiornare le risorse Kubernetes, un utente potrebbe modificare il deployment Kubernetes di un servizio per bypassare il sidecar del servizio.

Per creare una security posture solida per un mesh di servizi, i meccanismi di sicurezza della piattaforma di base devono essere applicati in modo da funzionare insieme ai criteri di sicurezza di Cloud Service Mesh.

I criteri di rete Kubernetes operano a livello di rete (L3 e L4) per gli indirizzi IP e le porte su gli spazi dei nomi e i pod Kubernetes. I criteri di rete Kubernetes possono essere applicati in combinazione con i criteri di Cloud Service Mesh per migliorare la sicurezza del mesh.

Ad esempio, l'amministratore del mesh può configurare i criteri di rete di Kubernetes per consentire al traffico di utilizzare solo le porte con il criterio di sicurezza di Cloud Service Mesh applicato. Se tutto il traffico deve essere applicato con mTLS di Cloud Service Mesh, l'amministratore può configurare un criterio di rete Kubernetes per consentire il traffico solo sulle porte configurate con il criterio mTLS di Cloud Service Mesh. L'amministratore del mesh può anche configurare i criteri di rete Kubernetes per limitare la connettività delle porte con eccezioni ai criteri. Ad esempio, limita la connettività di queste porte a un ambito.

Accesso sicuro al control plane

Il piano di controllo di Cloud Service Mesh autentica tutti i client che si connettono. Pertanto, solo gli utenti chiamanti con credenziali valide (JWT di Kubernetes o certificati X.509 emessi da CA consentite) possono accedere al control plane di Cloud Service Mesh. TLS cripta le connessioni tra i carichi di lavoro e il piano di controllo di Cloud Service Mesh.

Oltre al meccanismo di autenticazione, per Cloud Service Mesh all'interno del cluster, è possibile implementare i criteri di rete Kubernetes per isolare lo spazio dei nomi di sistema Cloud Service Mesh (per impostazione predefinita istio-system) dagli spazi dei nomi e dai client non gestiti al di fuori della mesh, consentendo al contempo ai data plane di accedere al control plane. Le regole del firewall VPC possono impedire al traffico esterno a un cluster di raggiungere Istiod. Con queste misure di isolamento della rete, un malintenzionato esterno al mesh non potrà accedere al control plane, anche se dispone di credenziali valide. Per i control plane gestiti, Google gestisce la sicurezza dei control plane e non sono necessari questi criteri di isolamento della rete per i control plane.

Applicare i confini dello spazio dei nomi

Per impedire a un utente di uno spazio dei nomi di accedere/aggiornare le risorse in uno spazio dei nomi non autorizzato:

  • Applica i controlli dell'accesso.
  • Applica i criteri di rete Kubernetes. Se i servizi in uno spazio dei nomi non hanno traffico al di fuori dello spazio dei nomi, l'amministratore del mesh deve implementare un criterio di rete Kubernetes che consenta solo il traffico all'interno dello spazio dei nomi: nessun traffico in entrata o in uscita dallo spazio dei nomi.
  • Applica i criteri RBAC di Kubernetes.
    • I ruoli degli amministratori dell'applicazione devono essere associati a uno spazio dei nomi.
    • Consenti solo agli amministratori del mesh di avere ClusterRole.

Applicare i criteri RBAC di Kubernetes

Gli amministratori del mesh devono applicare criteri RBAC di Kubernetes per controllare chi è autorizzato ad accedere e aggiornare le risorse Kubernetes. Controllo dell'accesso Kubernetes può mitigare i rischi per la sicurezza nel mesh. Ad esempio, gli utenti non autorizzati non devono essere autorizzati a modificare i deployment di Kubernetes e aggirare l'applicazione dei criteri di Cloud Service Mesh. I ruoli di un utente devono essere legati a uno spazio dei nomi in modo che l'utente non possa accedere a più spazi dei nomi di quelli di cui ha bisogno. Per guide dettagliate ed esempi di configurazione del RBAC, consulta Configurare il controllo degli accessi basato sui ruoli. Dopo aver attivato la federazione delle identità per i carichi di lavoro per GKE, puoi anche consentire a un account di servizio Kubernetes di agire come account di servizio IAM.

Sicurezza perimetrale del mesh

Poiché la maggior parte degli attacchi può provenire anche dall'esterno di un cluster, è fondamentale garantire la sicurezza all'esterno della mesh.

Controllo dell'accesso all'ingresso del cluster

Cloud Service Mesh riceve il traffico esterno in entrata tramite il gateway di ingresso. I servizi esposti dal gateway in entrata potrebbero essere soggetti ad attacchi provenienti da fonti esterne. Gli amministratori della sicurezza devono sempre assicurarsi che i servizi esposti al traffico esterno tramite i gateway di ingresso siano sufficientemente sicuri per difendersi dagli attacchi.

Ingress deve applicare l'autenticazione e l'autorizzazione per i servizi esposti a chiamanti esterni.

  • Applica i criteri di sicurezza di ingresso del cluster. Quando il cluster deve ricevere traffico esterno, l'amministratore del mesh deve applicare i criteri di sicurezza di ingresso, inclusi i criteri di autenticazione e autorizzazione, nonché il gateway TLS di Cloud Service Mesh, per autenticare le richieste esterne e verificare che siano autorizzate ad accedere ai servizi esposti dal gateway di ingresso. L'applicazione dei criteri di sicurezza in entrata protegge dall'esterno del mesh gli attacchi che tentano di accedere a un servizio senza credenziali o autorizzazioni valide.
  • Utilizza Cloud Armor come WAF (Web Application Firewall) per difenderti dagli attacchi basati sul web (ad esempio, attacchi di attacco e di esecuzione remota). Per maggiori informazioni, consulta Da dispositivi periferici a mesh: esposizione delle applicazioni di mesh di servizi mediante GKE Ingress.

Regola il traffico in uscita del cluster

La sicurezza in uscita del cluster è fondamentale per la sicurezza del mesh perché le norme di sicurezza in uscita possono difendere dagli attacchi di esfiltrazione di dati, applicare il filtro del traffico in uscita e applicare l'originazione TLS per il traffico in uscita. Gli amministratori di sicurezza devono regolamentare e controllare il traffico in uscita del cluster.

Oltre a utilizzare i firewall VPC per limitare il traffico in uscita, gli amministratori del mesh devono anche applicare i criteri di sicurezza in uscita per il cluster e configurare il traffico in uscita in modo che passi attraverso i gateway in uscita.

I criteri di uscita possono mitigare i seguenti attacchi:

  • Attacchi di esfiltrazione di dati.
  • I pod di servizio possono essere sfruttati dagli attaccanti se le relative CVE non sono corrette. I pod compromessi possono diventare una botnet controllata dagli utenti malintenzionati per inviare spam o lanciare attacchi DoS.

I criteri di autorizzazione applicati ai gateway in uscita possono garantire che solo i servizi autorizzati possano inviare traffico a determinati host esterni alla mesh. Nel frattempo, per il traffico in uscita dal mesh, anziché gestire l'origine TLS nei singoli sidecar, TLS può essere generato nei gateway di uscita. Questo fornisce un modo uniforme e più sicuro per generare traffico TLS, in quanto i certificati client per mTLS possono essere isolati dagli spazi dei nomi in cui vengono eseguite le applicazioni.

Utilizza un cluster privato o i Controlli di servizio VPC per bloccare gli accessi esterni

Oltre ad applicare i criteri di sicurezza in entrata e in uscita, blocca l'accesso esterno utilizzando un cluster privato o Controlli di servizio VPC, ove possibile. Sebbene i criteri di sicurezza siano controllati dagli amministratori della sicurezza del mesh, la configurazione del cluster privato o i Controlli di servizio VPC possono essere applicati dagli amministratori della sicurezza dell'organizzazione.

I Controlli di servizio VPC possono essere applicati per definire un perimetro di sicurezza per i servizi al fine di:

  • Impedire ai servizi di accedere a risorse esterne.
  • Impedire agli estranei di accedere ai servizi in un perimetro di sicurezza.

I Controlli di servizio VPC aiutano a difendersi dagli attacchi di esfiltrazione di dati e impediscono agli hacker esterni di accedere ai servizi all'interno di un mesh.

Difesa contro gli attacchi DDoS esterni

Gli attacchi DDoS esterni possono sovraccaricare i gateway di ingresso e i servizi di backend, impedendo la gestione delle richieste legittime. Cloud Armor può essere utilizzato per difendersi dagli attacchi DDoS. Cloud Armor protegge non solo dagli attacchi DDoS a livello di rete (L3 e L4), ma anche dagli attacchi DDoS a livello di applicazione (L7).

Sicurezza per l'amministrazione e l'automazione del mesh

È importante prendere in considerazione la sicurezza per le operazioni amministrative e per qualsiasi automazione che crei intorno al tuo mesh, ad esempio CI/CD. Le seguenti pratiche hanno lo scopo di garantire che la rete mesh possa essere utilizzata in sicurezza senza il rischio di esporre i servizi ad attacchi aggiuntivi.

Segmenta i ruoli utilizzati per le operazioni del mesh

Seguendo lo stesso principio del controllo dell'accesso basato su ruoli, gli utenti di una mesh devono essere classificati in base ai loro ruoli. A ogni ruolo deve essere concesso solo l'insieme minimo di privilegi necessari.

Ad esempio, l'insieme di utenti che eseguono i deployment dei servizi non deve disporre di privilegi per aggiornare i criteri di autenticazione e autorizzazione.

Esistono diverse categorie di operatori. Ad esempio, operatori di cluster e operatori di spazio dei nomi. È importante impedire l'escalation dei privilegi da parte di un operatore, che potrebbe comportare l'accesso illecito a risorse non autorizzate.

I criteri RBAC di Kubernetes consentono agli amministratori del mesh di limitare l'accesso alle risorse solo agli utenti autorizzati.

Convalida automaticamente le configurazioni dei criteri

Gli operatori potrebbero configurare erroneamente i criteri di Cloud Service Mesh, il che può comportare gravi incidenti di sicurezza. Per evitare configurazioni errate e convalidare automaticamente i criteri di Cloud Service Mesh, gli amministratori del mesh possono utilizzare Policy Controller per applicare vincoli alle configurazioni dei criteri.

Per evitare di affidarsi troppo a persone con autorizzazioni per aggiornare i criteri di sicurezza di Cloud Service Mesh e per automatizzare la convalida dei criteri di Cloud Service Mesh, gli amministratori del mesh devono implementare vincoli sui criteri di Cloud Service Mesh utilizzando Policy Controller.

Policy Controller si basa sul progetto open source Gatekeeper e può essere eseguito come controller di ammissione Kubernetes per impedire l'applicazione di risorse non valide o in modalità di controllo in modo che gli amministratori possano ricevere avvisi in caso di violazioni. Policy Controller può convalidare automaticamente il deployment delle risorse nel mesh, ad esempio convalidare che le annotazioni di un deployment non aggirino i criteri di Cloud Service Mesh, convalidare che i criteri di Cloud Service Mesh siano come previsto e convalidare che un deployment non includa funzionalità di root (ad esempio NET_ADMIN e NET_RAW).

Policy Controller può anche controllare le risorse Cloud Service Mesh esistenti rispetto ai vincoli per rilevare le configurazioni errate dei criteri.

Di seguito sono riportati alcuni esempi di applicazione dei criteri di sicurezza da parte di GKE Enterprise Policy Controller:

La libreria di modelli di vincolo fornita con Policy Controller contiene un insieme di modelli di vincolo che possono essere utilizzati con il pacchetto di vincoli di sicurezza Cloud Service Mesh predefinito per applicare specifiche best practice di sicurezza di Cloud Service Mesh, ad esempio criteri di autenticazione, autorizzazione e traffico. Di seguito sono riportati alcuni vincoli di esempio inclusi nel bundle:

  • Applica la modalità mTLS restrittiva PeerAuthentication a livello di mesh.
  • L'applicazione di tutte le autenticazioni peer non può sovrascrivere la modalità mTLS restrittiva.
  • Applica il criterio AuthorizationPolicy default deny a livello di mesh.
  • Applica i pattern sicuri di AuthorizationPolicy.
  • Imposta che i sidecar di Cloud Service Mesh vengano sempre iniettati nei carichi di lavoro.

Per gestire le eccezioni e le situazioni di emergenza, l'amministratore del mesh può:

Utilizzare un approccio GitOps con Config Sync per evitare deviazioni dalla configurazione

Il drift della configurazione si verifica quando la configurazione dei criteri in una rete mesh si discosta dalla relativa fonte attendibile. Config Sync può essere utilizzato per evitare la deriva della configurazione.

Applicare il monitoraggio e gli audit log

Gli amministratori della mesh devono monitorare quanto segue:

Queste risorse di osservabilità possono essere utilizzate per verificare che la configurazione di sicurezza funzioni come previsto e per monitorare eventuali eccezioni all'applicazione dei criteri di sicurezza. Ad esempio, l'accesso che non è passato dai sidecar, l'accesso che non aveva credenziali valide, ma ha raggiunto un servizio.

Sebbene il software di osservabilità open source (ad esempio Prometheus) possa essere utilizzato con Cloud Service Mesh, ti consigliamo vivamente di utilizzare Google Cloud Observability (in precedenza Stackdriver). La soluzione di observability integrata per Google Cloud fornisce logging, raccolta delle metriche, monitoraggio e avvisi, ed è completamente gestita e facile da usare.

Proteggi l'autorità di certificazione per i certificati all'interno del cluster

Per impostazione predefinita, Cloud Service Mesh utilizza un'autorità di certificazione (CA) gestita da Google chiamata Autorità di certificazione Cloud Service Mesh.

Se utilizzi l'autorità di certificazione (CA) Istio non gestita, ospitata come parte di Istiod, la chiave di firma della CA è archiviata in un segreto Kubernetes ed è accessibile agli operatori che hanno accesso alla risorsa segreta nello spazio dei nomi istio-system. Si tratta di un rischio, poiché un operatore potrebbe essere in grado di utilizzare la chiave della CA indipendentemente dalla CA di Istiod e potenzialmente firmare i certificati del carico di lavoro in modo indipendente. Esiste anche il rischio che una chiave di firma CA gestita autonomamente possa essere divulgata accidentalmente a causa di un errore operativo.

Per proteggere la chiave di firma CA, l'amministratore del mesh può eseguire l'upgrade del mesh in modo da utilizzare l'autorità di certificazione Cloud Service Mesh o Certificate Authority Service (servizio CA), che sono protetti e gestiti da Google. Rispetto alla CA di Cloud Service Mesh, il servizio CA supporta le chiavi di firma per cliente tramite Cloud KMS con il supporto di Cloud HSM. CA Service supporta anche i workload regolamentati, mentre l'autorità di certificazione Cloud Service Mesh no.

Sicurezza dei carichi di lavoro

La sicurezza dei carichi di lavoro protegge dagli attacchi che compromettono i pod dei carichi di lavoro e poi utilizzano i pod compromessi per lanciare attacchi contro il cluster (ad esempio, attacchi di botnet).

Limitare i privilegi del pod

Un pod Kubernetes potrebbe avere privilegi che influiscono su altri pod sul nodo o sul cluster. È importante applicare restrizioni di sicurezza ai pod di workload per impedire a un pod compromesso di lanciare attacchi contro il cluster.

Per applicare il principio del privilegio minimo ai workload su un pod:

  • I servizi di cui è stato eseguito il deployment in un mesh devono essere eseguiti con il minor numero di privilegi possibile.
  • I pod Kubernetes in esecuzione in modalità privilegiata possono manipolare gli stack di rete e altre funzionalità del kernel sull'host. GKE Enterprise Policy Controller può essere utilizzato per impedire ai pod di eseguire container con privilegi.
  • Cloud Service Mesh può essere configurato per utilizzare un contenitore init per configurare il reindirizzamento del traffico iptables al sidecar. Ciò richiede che l'utente che esegue i deployment dei carichi di lavoro disponga dei privilegi per il deployment dei contenitori con funzionalità NET_ADMIN e NET_RAW. Per evitare il rischio di eseguire contenitori con privilegi elevati, gli amministratori del mesh possono invece abilitare il plug-in CNI Istio per configurare il reindirizzamento del traffico ai sidecar.

Immagini container sicure

Gli aggressori potrebbero lanciare attacchi sfruttando le immagini container vulnerabili. Gli amministratori devono applicare Autorizzazione binaria per verificare l'integrità delle immagini container e garantire che nel mesh venga eseguito il deployment solo di immagini container attendibili.

Mitiga le vulnerabilità del mesh

  • Container Analysis. Container Analysis può analizzare e rilevare le vulnerabilità nei carichi di lavoro GKE.
  • Gestione delle vulnerabilità ed esposizioni comuni (CVE). Dopo che viene rilevata una vulnerabilità in un'immagine container, gli amministratori del mesh devono correggerla il prima possibile. Per Cloud Service Mesh gestito con piano dati gestito, Google gestisce automaticamente le patch delle CVE che influiscono sulle immagini del mesh.

Utilizza Workload Identity Federation for GKE per accedere in sicurezza ai servizi Google

Workload Identity Federation for GKE è il metodo consigliato per consentire ai carichi di lavoro mesh di accedere in sicurezza ai servizi Google. L'alternativa di archiviare una chiave dell'account di servizio in un segreto Kubernetes e utilizzarla per accedere ai servizi Google non è altrettanto sicura a causa dei rischi di fuga di credenziali, escalation dei privilegi, divulgazione di informazioni e non ripudio.

Monitora lo stato della sicurezza tramite la dashboard per la sicurezza e la telemetria

Un mesh di servizi potrebbe avere eccezioni di sicurezza e potenziali scappatoie. È fondamentale rilevare e monitorare lo stato di sicurezza di un mesh, che include i criteri di sicurezza applicati, le eccezioni di sicurezza e le potenziali vulnerabilità di sicurezza nel mesh. La dashboard per la sicurezza di GKE Enterprise e la telemetria possono essere utilizzate per visualizzare e monitorare lo stato della sicurezza del mesh.

La telemetria monitora l'integrità e le prestazioni dei servizi in un mesh, consentendo agli amministratori del mesh di osservare i comportamenti dei servizi (ad esempio SLO, traffico anomalo, interruzione del servizio, topologia).

La dashboard di sicurezza di GKE Enterprise analizza e visualizza i criteri di sicurezza applicati a un carico di lavoro in un mesh di servizi, inclusi i criteri di controllo dell'accesso dell'accesso (criteri di rete Kubernetes, criteri di autorizzazione binaria e criteri di controllo dell'accesso ai servizi) e i criteri di autenticazione (mTLS).

Sicurezza per dati utente e credenziali sensibili

Le credenziali o i dati utente sensibili possono essere vulnerabili ad attacchi provenienti da pod o operazioni dannose se sono archiviati nello spazio di archiviazione permanente del cluster, ad esempio utilizzando i secret di Kubernetes o direttamente nei pod. Sono inoltre vulnerabili agli attacchi di rete se vengono trasferiti sulla rete per l'autenticazione ai servizi.

  • Se possibile, archivia le credenziali e i dati utente sensibili in uno spazio di archiviazione protetto, come Secret Manager e Cloud KMS.
  • Designa spazi dei nomi separati per i pod Kubernetes che accedono a dati sensibili e definisci i criteri Kubernetes per renderli inaccessibili da altri spazi dei nomi. Segmenta i ruoli utilizzati per le operazioni e applica i confini dello spazio dei nomi.
  • Applica lo scambio di token per impedire l'esfiltrazione di token di lunga durata e con privilegi elevati.

Passaggi successivi