Versione 1.16

Versioni disponibili

1.20 (più recente)
1,19
1,18
1,17
1,16
1,15
1,14
1.13
1.12
1.12

Best practice per la sicurezza di Anthos Service Mesh

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

Il pubblico di destinazione di questo documento include gli amministratori che gestiscono i criteri in un Anthos Service Mesh e gli utenti che eseguono servizi in un Anthos 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
Vettori di attacco e rischi per la sicurezza
- Vettori di attacco
- Rischi per la sicurezza
Misure per proteggere un mesh di servizi

Introduzione

Anthos Service Mesh fornisce funzionalità e strumenti che ti consentono di osservare, gestire e proteggere i servizi in modo unificato. Ha un approccio incentrato sull'applicazione e utilizza identità applicazione 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. Anthos Service Mesh fornisce un controllo dichiarativo sul comportamento della rete, che aiuta a disaccoppiare il lavoro dei team responsabili della distribuzione e del rilascio delle funzionalità delle applicazioni dalle responsabilità degli amministratori responsabili della sicurezza e del networking.

Anthos Service Mesh si basa sul mesh di servizi IBM 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 un mesh. Le impostazioni predefinite di Anthos Service Mesh vengono scelte per proteggere le applicazioni, ma in alcuni casi potrebbero essere necessarie configurazioni personalizzate o concedere eccezioni escludendo determinate app, porte o indirizzi IP dalla partecipazione a un mesh. Disporre di controlli per gestire le configurazioni mesh e le eccezioni di sicurezza è importante.

Vettori di attacco e rischi per la sicurezza

Vettori di attacco

La sicurezza di Anthos Service Mesh segue il modello di sicurezza Zero Trust che presuppone che le minacce alla sicurezza provengano sia dall'interno che dall'esterno del perimetro di sicurezza di un'organizzazione. Esempi di tipi di attacchi alla sicurezza che possono minacciare applicazioni in un mesh di servizi includono:

Attacchi di esfiltrazione di dati. Ad esempio, attacchi che intercettano dati o credenziali sensibili 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 con escalation dei privilegi. Ad esempio, gli attacchi che utilizzano l'accesso illecito a privilegi elevati per condurre operazioni in una rete.
Attacchi DoS (Denial of Service).
Attacchi botnet che tentano di compromettere e manipolare i servizi per lanciare attacchi ad altri servizi.

Gli attacchi possono essere classificati anche in base agli obiettivi di attacco:

Attacchi alla rete interna mesh. Attacchi mirati a manomissioni, intercettazioni o spoofing della comunicazione interna da servizio a servizio o da servizio a piano di controllo della rete mesh.
Attacchi su piani di controllo. Attacchi mirati a causare il malfunzionamento del piano di controllo (ad esempio un attacco DoS) o l'esfiltrazione di dati sensibili dal piano di controllo.
Attacchi al perimetro della rete mesh. Attacchi mirati a manomettere, intercettare o effettuare lo spoofing della comunicazione in entrata o in uscita dal mesh.
Attacchi con operazioni mesh. Attacchi mirati alle operazioni mesh. Gli utenti malintenzionati potrebbero provare a ottenere privilegi elevati per eseguire operazioni dannose in un mesh, ad esempio modificando i criteri di sicurezza e le immagini dei carichi di lavoro.

Rischi per la sicurezza

Oltre agli attacchi alla sicurezza, un mesh deve affrontare anche altri rischi per la sicurezza. Il seguente elenco descrive alcuni possibili rischi per la sicurezza:

Protezione di sicurezza incompleta. Un mesh di servizi non è stato configurato con criteri di autenticazione e autorizzazione per proteggerne la sicurezza. Ad esempio, non vengono definiti criteri di autenticazione o di autorizzazione per i servizi in un mesh.
Eccezioni dei criteri di sicurezza. Per soddisfare i propri casi d'uso specifici, gli utenti possono creare eccezioni dei criteri di sicurezza per determinati tipi di traffico (interno o esterno) da escludere dai criteri di sicurezza di Anthos Service Mesh. Per gestire in modo sicuro questi casi, consulta la sezione Gestire le eccezioni alle norme in modo sicuro.
Trascurato per gli upgrade delle immagini. Possono essere rilevate vulnerabilità per le immagini utilizzate in un mesh. Devi mantenere il componente mesh e le immagini del carico di lavoro aggiornati con le correzioni delle vulnerabilità più recenti.
Mancanza di manutenzione (nessuna competenza o risorsa). Le configurazioni dei criteri e del software mesh richiedono una manutenzione regolare per poter sfruttare i meccanismi di protezione della sicurezza più recenti.
Mancanza di visibilità. La configurazione errata o le configurazioni non sicure dei criteri mesh e le operazioni/il traffico mesh anomalo non vengono portati all'attenzione degli amministratori del mesh.
Deviazione della configurazione. La configurazione dei criteri in un mesh si discosta dalla fonte dei dati.

Misure per proteggere un mesh di servizi

Questa sezione presenta un manuale operativo per proteggere i mesh di servizi.

Architettura di sicurezza

La sicurezza di un mesh di servizi dipende dalla sicurezza dei componenti nei diversi livelli del sistema mesh e delle sue applicazioni. L'intenzione generale della strategia di sicurezza Anthos Service Mesh proposta è quella di proteggere una rete mesh di servizi integrando più meccanismi di sicurezza su livelli diversi, ottenendo congiuntamente la sicurezza generale del sistema nell'ambito del modello di sicurezza Zero Trust. Il seguente diagramma mostra la strategia di sicurezza di Anthos Service Mesh proposta.

strategia di sicurezza di Anthos Service Mesh

Anthos Service Mesh fornisce sicurezza su più livelli, tra cui:

Sicurezza perimetrale della rete mesh
- La sicurezza in entrata di Anthos Service Mesh 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 Anthos Service Mesh regola il traffico in uscita dai carichi di lavoro interni.
- Anthos Service Mesh User Auth si integra con l'infrastruttura Google per autenticare le chiamate esterne dai browser web ai servizi che eseguono le applicazioni web.
- La gestione dei certificati gateway di Anthos Service Mesh protegge e ruota le chiavi private e i certificati X.509 utilizzati dai gateway in entrata e in uscita di Anthos Service Mesh utilizzando Certificate Authority Service.
- Cloud Armor può difendersi dagli attacchi esterni Distributed Denial of Service (DDoS) e di livello 7. Serve come Web Application Firewall (WAF) per proteggere il mesh dagli attacchi di rete. ad esempio attacchi di iniezione ed esecuzione di codice da remoto.
- I Controlli di servizio VPC e VPC proteggono il perimetro della rete mesh tramite i controlli di accesso alla rete privata.
Sicurezza dei cluster
- Anthos Service Mesh mTLS (mutuo TLS) applica la crittografia e l'autenticazione del traffico dai carichi di lavoro ai carichi di lavoro.
- Una CA gestita, come l'autorità di certificazione Anthos Service Mesh (Mesh CA) e Certificate Authority Service, esegue il provisioning e la gestione in modo sicuro dei certificati utilizzati dai carichi di lavoro.
- L'autorizzazione di Anthos Service Mesh applica il controllo dell'accesso ai servizi mesh in base alle loro identità e ad altri attributi.
- La dashboard per la sicurezza di GKE Enterprise fornisce il monitoraggio delle configurazioni dei criteri di sicurezza e dei criteri di rete di Kubernetes per i carichi di lavoro.
- Il criterio di rete di Kubernetes applica controllo dell'accesso ai pod in base a indirizzi IP, etichette pod, spazi dei nomi e altro ancora.
- La sicurezza del piano di controllo protegge dagli attacchi al piano di controllo. Questa protezione impedisce a utenti malintenzionati di modificare, sfruttare o diffondere i dati di configurazione del servizio e della rete mesh.
Sicurezza dei carichi di lavoro
- Rimani al corrente con le release di sicurezza di Anthos Service Mesh per assicurarti che i programmi binari di Anthos Service Mesh in esecuzione nel tuo mesh siano privi di vulnerabilità note pubblicamente.
- Workload Identity consente ai carichi di lavoro di ottenere le credenziali per chiamare in modo sicuro i servizi Google.
- Cloud Key Management Service (Cloud KMS) protegge i dati o le credenziali sensibili tramite i moduli di sicurezza hardware (HSM). Ad esempio, i carichi di lavoro possono utilizzare Cloud KMS per archiviare le credenziali o altri dati sensibili. CA Service, utilizzato per emettere certificati per i carichi di lavoro mesh, supporta chiavi di firma per cliente e supportate da HSM gestite da Cloud KMS.
- Kubernetes CNI (Container Network Interface) previene gli attacchi con escalation dei privilegi eliminando la necessità di un container init Anthos Service Mesh con privilegi.
Sicurezza dell'operatore
- Controllo dell'accesso basato su ruoli (RBAC) di Kubernetes limita l'accesso alle risorse Kubernetes e limita le autorizzazioni degli operatori per mitigare gli attacchi provenienti da operatori dannosi o furto d'identità di operatori.
- GKE Enterprise Policy Controller convalida e verifica le configurazioni dei criteri nel mesh per evitare configurazioni errate.
- Autorizzazione binaria di Google Cloud garantisce che le immagini dei carichi di lavoro nel mesh siano quelle autorizzate dagli amministratori.
- L'audit logging di Google Cloud controlla le operazioni della rete mesh.

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

diagramma di sicurezza flusso di traffico

Sicurezza dei cluster

Abilita TLS reciproco restrittivo

Un attacco man in the middle (MitM) tenta di inserire un'entità dannosa tra due parti comunicanti per intercettare o manipolare la comunicazione. Anthos Service Mesh ti difende dagli attacchi di esfiltrazione di dati e MitM applicando l'autenticazione e la crittografia mTLS per tutte le parti comunicanti. La modalità permissiva utilizza mTLS quando è supportata da entrambe le parti, ma consente connessioni senza mTLS. Al contrario, la modalità mTLS restrittiva richiede che il traffico venga criptato e autenticato con mTLS e non consente il traffico di testo normale.

Anthos Service Mesh ti consente di configurare la versione TLS minima per le connessioni TLS tra i tuoi carichi di lavoro al fine di soddisfare i requisiti di sicurezza e conformità.

Per maggiori informazioni, vedi Anthos Service Mesh con l'esempio: mTLS | Applicazione di mTLS a livello di mesh.

Attiva i controlli dell'accesso

I criteri di sicurezza di Anthos Service Mesh (come quelli di autenticazione e autorizzazione) devono essere applicati a tutto il traffico in entrata e in uscita dal mesh, a meno che non ci siano solide giustificazioni per escludere un servizio o un pod dai criteri di sicurezza di Anthos Service Mesh. In alcuni casi, gli utenti potrebbero avere motivi legittimi per ignorare i criteri di sicurezza di Anthos Service Mesh per alcune porte e intervalli IP. Ad esempio, per stabilire connessioni native con servizi non gestiti da Anthos Service Mesh. Per proteggere Anthos Service Mesh in questi casi d'uso, consulta Gestire in modo sicuro le eccezioni dei criteri di Anthos 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 dei criteri di autorizzazione di Anthos Service Mesh per applicare controllo dell'accesso dell'accesso ai servizi. Ad esempio, rifiutare una richiesta non autorizzata proveniente da un client autenticato.

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

Applica i criteri di autenticazione di Anthos Service Mesh

JWT (JSON Web Token)

Oltre all'autenticazione mTLS, gli amministratori di mesh possono richiedere a un servizio di autenticare e autorizzare le richieste basate su JWT. Anthos Service Mesh non agisce come provider JWT, ma autentica i JWT in base agli endpoint del set di chiavi web JSON (JWKS) configurati. L'autenticazione JWT può essere applicata ai gateway in entrata 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 il chiamante finale e il servizio richiesto richiede la prova di essere chiamato per conto del chiamante finale. L'applicazione dell'autenticazione JWT protegge dagli attacchi che accedono a un servizio senza credenziali valide e per conto di un utente finale reale.

Autenticazione utente Anthos Service Mesh

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

Applicare i criteri di autorizzazione

Controllo dei criteri di autorizzazione di Anthos Service Mesh:

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

I criteri di autorizzazione sono un modo versatile per configurare il controllo dell'accesso'accesso in base alle identità effettive che vengono eseguiti come i servizi, alle proprietà del traffico del livello applicazione (livello 7) e alle proprietà del livello di rete (livello 3 e 4) come gli intervalli IP e le porte.

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

Per impostazione predefinita, l'accesso a un servizio deve essere negato, a meno che non venga definito esplicitamente un criterio di autorizzazione per consentire l'accesso al servizio. Consulta le best practice relative ai criteri di autorizzazione per alcuni esempi di criteri di autorizzazione che negano le richieste di accesso.

I criteri di autorizzazione dovrebbero limitare il più possibile l'attendibilità. Ad esempio, l'accesso a un servizio può essere definito in base a 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 gli indirizzi IP e le porte sui pod Kubernetes e negli spazi dei nomi di Kubernetes.

Imporre lo scambio di token per accedere ai servizi mesh

Per difenderti dagli attacchi di riproduzione dei token che rubano i token e riutilizzano quelli rubati per accedere ai servizi mesh, un token in una richiesta esterna al mesh deve essere scambiato con un token interno mesh di breve durata a livello perimetrale.

Una richiesta dall'esterno del mesh per accedere a un servizio mesh deve includere un token, come JWT o cookie, per poter essere autenticata e autorizzata dal servizio mesh. Un token esterno al mesh può avere una lunga durata. Per difenderti dagli attacchi di ripetizione dei token, un token esterno al mesh deve essere scambiato con un token interno mesh di breve durata con un ambito limitato in entrata nel mesh. Il servizio mesh autentica un token interno del mesh e autorizza la richiesta di accesso in base al token interno del mesh.

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

Gestisci in sicurezza le eccezioni dei criteri di Anthos 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 soddisfare scenari di utilizzo specifici, a volte potrebbe essere necessario creare eccezioni per consentire l'esclusione di determinati traffico interno o esterno dai criteri di sicurezza di Anthos Service Mesh, creando problemi di sicurezza.

Potresti avere motivi legittimi per bypassare i criteri di sicurezza di Anthos Service Mesh per alcune porte e intervalli IP. Puoi aggiungere annotazioni (ad esempio excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) ai pod per impedire che il traffico venga gestito dal file collaterale di Envoy. Oltre alle annotazioni per escludere il traffico, puoi bypassare il mesh del tutto eseguendo il deployment di un'applicazione con l'inserimento dei sidecar disabilitato. Ad esempio, aggiungendo un'etichetta sidecar.istio.io/inject="false" al pod di applicazione.

L'elusione dei criteri di sicurezza di Anthos Service Mesh ha un impatto negativo sulla sicurezza complessiva del sistema. Ad esempio, se mTLS e criteri di autorizzazione di Anthos Service Mesh vengono ignorati per una porta di rete tramite annotazioni, non ci sarà alcun controllo di accesso al traffico sulla porta e potrebbero essere possibili intercettazioni o modifiche del traffico. Inoltre, l'esclusione dei criteri di Anthos Service Mesh influisce anche sui criteri non di sicurezza, come quelli di rete.

Quando il criterio di sicurezza di Anthos Service Mesh viene ignorato (intenzionalmente o involontariamente) per una porta o un IP, dovrebbero essere in atto altre misure di sicurezza per proteggere il mesh e monitorare le eccezioni di sicurezza, i potenziali fallimenti di sicurezza e lo stato complessivo dell'applicazione della sicurezza. Per proteggere la rete mesh in situazioni simili, puoi:

Assicurati che il traffico che bypassa i file collaterali sia criptato e autenticato in modo nativo per prevenire gli attacchi MitM.
Applica i criteri di rete di 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 per cui è applicato il criterio di sicurezza Anthos Service Mesh.
Applica GKE Enterprise Policy Controller per convalidare automaticamente i criteri di Anthos Service Mesh. Ad esempio, fai in modo che i file collaterali Anthos Service Mesh vengano sempre inseriti nei carichi di lavoro.

Applicare i criteri di rete di Kubernetes

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

Per formare una solida strategia di sicurezza per un mesh di servizi, è necessario applicare i meccanismi di sicurezza della piattaforma sottostante in modo che funzionino congiuntamente ai criteri di sicurezza di Anthos Service Mesh.

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

Ad esempio, l'amministratore del mesh può configurare i criteri di rete Kubernetes per consentire al traffico di utilizzare le porte solo in cui è applicato il criterio di sicurezza Anthos Service Mesh. Se tutto il traffico deve essere applicato con mTLS Anthos Service Mesh, l'amministratore può configurare un criterio di rete Kubernetes per consentire solo il traffico sulle porte configurate con il criterio mTLS di Anthos 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 in modo che sia all'interno di uno spazio dei nomi.

Accesso sicuro al piano di controllo

Il piano di controllo di Anthos Service Mesh autentica tutti i client che si connettono. Di conseguenza, solo i chiamanti con credenziali valide (certificati Kubernetes JWT o X.509 emessi dalle CA autorizzate) possono accedere al piano di controllo di Anthos Service Mesh. TLS cripta le connessioni tra i carichi di lavoro e il piano di controllo Anthos Service Mesh.

Oltre al meccanismo di autenticazione, per Anthos Service Mesh nel cluster è possibile eseguire il deployment dei criteri di rete di Kubernetes per isolare lo spazio dei nomi di sistema Anthos Service Mesh (per impostazione predefinita istio-system) da spazi dei nomi non gestiti e client esterni al mesh, consentendo ai piani dati di accedere al piano di controllo. Le regole firewall VPC possono impedire al traffico esterno a un cluster di raggiungere Istiod. Con queste misure di isolamento della rete, un utente malintenzionato esterno al mesh non sarà in grado di accedere al piano di controllo, anche se dispone di una credenziale valida. Per i piani di controllo gestiti, Google gestisce la sicurezza dei piani di controllo e tali criteri di isolamento della rete non sono necessari.

Applica limiti dello spazio dei nomi

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

Applica i controlli dell'accesso.
Applica i criteri di rete di Kubernetes. Se i servizi in uno spazio dei nomi non hanno traffico al di fuori dello spazio dei nomi, l'amministratore di mesh deve eseguire il deployment di 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 di Kubernetes RBAC.
- I ruoli degli amministratori delle applicazioni devono essere associati a uno spazio dei nomi.
- Consenti solo agli amministratori del mesh di avere ClusterRole.

Applicare i criteri di Kubernetes RBAC

Gli amministratori del mesh devono applicare i criteri di Kubernetes RBAC per controllare chi è autorizzato ad accedere alle risorse Kubernetes e ad aggiornarle. Controllo dell'accesso di Kubernetes può mitigare i rischi per la sicurezza nel mesh. Ad esempio, gli utenti non autorizzati non devono essere autorizzati a modificare i deployment Kubernetes e ignorare l'applicazione dei criteri di Anthos Service Mesh. I ruoli di un utente devono essere associati a uno spazio dei nomi, in modo che l'utente non possa accedere a più spazi dei nomi di quelli a cui deve accedere. Per guide dettagliate ed esempi sulla configurazione di RBAC, consulta Configurare il controllo degli accessi basato sui ruoli. Dopo aver abilitato Workload Identity, puoi anche consentire a un account di servizio Kubernetes di agire come account di servizio IAM.

Sicurezza perimetrale della rete mesh

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

Controllo dell'accesso in entrata al cluster

Anthos Service Mesh riceve il traffico esterno in entrata tramite il gateway in entrata. I servizi esposti dal gateway in entrata potrebbero essere soggetti ad attacchi da origini esterne. Gli amministratori della sicurezza dovrebbero sempre assicurarsi che i servizi esposti al traffico esterno tramite gateway in entrata siano sufficientemente sicuri da difendersi dagli attacchi.

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

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

Regola il traffico in uscita del cluster

La sicurezza del traffico in uscita dai cluster è fondamentale per la sicurezza della rete mesh, perché i criteri di sicurezza in uscita possono difendersi 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 della sicurezza dovrebbero regolare e controllare il traffico in uscita dei cluster.

Oltre a utilizzare i firewall VPC per limitare il traffico in uscita, gli amministratori di mesh devono anche applicare 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 in uscita possono mitigare i seguenti attacchi:

Attacchi di esfiltrazione di dati.
I pod di servizio possono essere sfruttati da utenti malintenzionati se non vengono applicate patch alle loro CVE. I pod compromessi possono diventare una botnet controllata da utenti malintenzionati per inviare spam o avviare attacchi DoS.

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

Usa il cluster privato o il Controllo di servizio VPC per bloccare gli accessi esterni

Oltre ad applicare criteri di sicurezza in entrata e in uscita, blocca l'accesso esterno utilizzando un cluster privato o i Controlli di servizio VPC, ove possibile. Mentre i criteri di sicurezza sono 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.

È possibile applicare i Controlli di servizio VPC alla definizione di un perimetro di sicurezza per i servizi al fine di:

Limita l'accesso dei servizi alle risorse esterne.
Impedisci agli utenti esterni di accedere ai servizi in un perimetro di sicurezza.

I Controlli di servizio VPC contribuiscono a difenderti dagli attacchi di esfiltrazione di dati e a impedire a utenti malintenzionati esterni di accedere ai servizi all'interno di un mesh.

Difendersi dagli attacchi DDoS esterni

Gli attacchi DDoS esterni possono sovraccaricare i gateway e i servizi di backend in entrata, impedendo la gestione di richieste legittime. Cloud Armor può essere utilizzato per difendersi dagli attacchi DDoS. Cloud Armor difende 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 considerare la sicurezza per le operazioni amministrative e per qualsiasi automazione che crei sul tuo mesh, ad esempio CI/CD. Le pratiche seguenti mirano a garantire che il mesh possa essere utilizzato in modo sicuro senza il rischio di esporre i servizi ad altri attacchi.

Segmentare i ruoli utilizzati per le operazioni mesh

Seguendo lo stesso principio del controllo dell'accesso basato sui ruoli, gli utenti di un mesh dovrebbero essere classificati in base ai loro ruoli. A ogni ruolo deve essere concesso solo l'insieme minimo di privilegi richiesti dal ruolo.

Ad esempio, l'insieme di utenti che eseguono deployment di servizi non deve disporre dei privilegi per l'aggiornamento dei 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 causare l'accesso illegale a risorse non autorizzate.

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

Convalida automaticamente le configurazioni dei criteri

Gli operatori potrebbero configurare in modo errato i criteri di Anthos Service Mesh, causando gravi incidenti di sicurezza. Per evitare errori di configurazione e convalidare automaticamente i criteri di Anthos Service Mesh, gli amministratori di mesh possono utilizzare Policy Controller per applicare vincoli alle configurazioni dei criteri.

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

Policy Controller è basato sul progetto open source Gatekeeper e può essere eseguito come controller di ammissione Kubernetes per negare l'applicazione di risorse non valide oppure 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 verificando che le annotazioni su un deployment non ignorino i criteri di Anthos Service Mesh, verificando che i criteri di Anthos Service Mesh siano come previsto e verificando che un deployment non includa funzionalità di base (come NET_ADMIN e NET_RAW).

Policy Controller può anche verificare le risorse Anthos Service Mesh esistenti in base ai vincoli per rilevare configurazioni errate dei criteri.

Di seguito sono riportati alcuni esempi di GKE Enterprise Policy Controller che applica i criteri di sicurezza:

La libreria dei 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 di Anthos Service Mesh predefinito per applicare specifiche best practice per la sicurezza di Anthos Service Mesh, ad esempio criteri di autenticazione, autorizzazione e traffico. Di seguito sono riportati alcuni vincoli di esempio inclusi nel pacchetto:

Applica il livello mesh mTLS stretto.
L'applicazione forzata di tutti i metodi PeerAuthentications non può sovrascrivere la modalità mTLS restrittiva.
Applica il criterio di autorizzazione default deny a livello di mesh.
Applica i pattern sicuri di AuthorizationPolicy.
Applica i sidecar di Anthos Service Mesh vengono sempre inseriti nei carichi di lavoro.

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

Escludi uno spazio dei nomi dall'applicazione forzata del webhook di ammissione di Policy Controller, ma eventuali violazioni vengono comunque segnalate nel audit.
Imposta il vincolo spec.enforcementAction su prova di prova. Il webhook di ammissione non impedirà le modifiche, ma eventuali violazioni vengono comunque segnalate nell'audit. Security Command Center può essere utilizzato per rendere visibili le violazioni dei controlli ai team di sicurezza.
Aggiungi la logica di esenzione al modello di vincolo (esempio).

Utilizza un approccio GitOps con Config Sync per evitare la deriva della configurazione

La deviazione della configurazione si verifica quando la configurazione dei criteri in un mesh si discosta dalla propria fonte di riferimento. Config Sync può essere utilizzato per prevenire le deviazioni della configurazione.

Applica audit logging e monitoraggio

Gli amministratori del mesh devono monitorare quanto segue:

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

Sebbene il software di osservabilità open source (ad esempio Prometheus) possa essere utilizzato con Anthos Service Mesh, consigliamo vivamente di utilizzare la suite operativa di Google Cloud (in precedenza Stackdriver). La soluzione di osservabilità integrata per Google Cloud fornisce logging, raccolta delle metriche, monitoraggio e generazione di avvisi, il tutto completamente gestito e facile da usare.

Proteggi l'autorità di certificazione per i certificati nel cluster

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

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

Per proteggere la chiave di firma della CA, l'amministratore del mesh può eseguire l'upgrade del mesh per utilizzare Mesh CA o Certificate Authority Service (CA Service), che sono protetti e gestiti da Google. Rispetto a Mesh CA, CA Service supporta la firma delle chiavi per cliente tramite Cloud KMS supportata da Cloud HSM. A differenza di Mesh CA, CA Service supporta anche i carichi di lavoro regolamentati.

Sicurezza dei carichi di lavoro

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

Limita privilegi pod

Un pod Kubernetes può disporre di privilegi che influiscono su altri pod sul nodo o sul cluster. È importante applicare limitazioni di sicurezza ai pod dei carichi di lavoro per impedire che un pod compromesso avvii attacchi al cluster.

Per applicare il principio del privilegio minimo per i carichi di lavoro su un pod:

I servizi di cui è stato eseguito il deployment in un mesh dovrebbero essere eseguiti con il minor numero di privilegi possibile.
I pod Kubernetes in esecuzione in modalità con privilegi possono manipolare gli stack di rete e altre funzionalità del kernel sull'host. Puoi utilizzare GKE Enterprise Policy Controller per impedire ai pod di eseguire container con privilegi.
Anthos Service Mesh può essere configurato in modo da utilizzare un container di inizializzazione per configurare il reindirizzamento del traffico iiptables al file collaterale. Ciò richiede che l'utente che esegue i deployment dei carichi di lavoro disponga dei privilegi necessari per il deployment di container con funzionalità NET_ADMIN e NET_RAW. Per evitare il rischio di eseguire container con privilegi elevati, gli amministratori di mesh possono invece enable il plug-in CNI Istio per configurare il reindirizzamento del traffico ai file collaterali.

Immagini container sicure

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

Mitiga le vulnerabilità del mesh

Container Analysis. Container Analysis può analizzare e individuare le vulnerabilità nei carichi di lavoro GKE.
Gestione delle vulnerabilità ed esposizioni comuni (CVE). Dopo aver rilevato una vulnerabilità in un'immagine container, gli amministratori del mesh devono correggere la vulnerabilità il prima possibile. Per Anthos Service Mesh gestito con un piano dati gestito, Google gestisce automaticamente l'applicazione di patch delle CVE che interessano le immagini mesh.

Usa Workload Identity per accedere in sicurezza ai servizi Google

Workload Identity è il metodo consigliato per consentire ai carichi di lavoro mesh di accedere in modo sicuro ai servizi Google. L'alternativa di archiviare una chiave dell'account di servizio in un secret Kubernetes e utilizzare la chiave dell'account di servizio per accedere ai servizi Google non è così sicura a causa dei rischi di fuga di credenziali, escalation dei privilegi, divulgazione delle informazioni e non ripudio.

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

Un mesh di servizi può presentare eccezioni di sicurezza e potenziali falle. È fondamentale individuare e monitorare lo stato di sicurezza di un mesh, che include i criteri di sicurezza applicati, le eccezioni di sicurezza e i potenziali loop di sicurezza nel mesh. La dashboard di 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, come SLO, traffico anomalo, interruzioni del servizio e topologia.

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

Sicurezza delle credenziali e dei dati utente sensibili

Le credenziali o i dati utente sensibili possono essere vulnerabili agli attacchi provenienti dai pod o da operazioni dannose se vengono archiviati nell'archiviazione permanente del cluster, ad esempio tramite 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 dati utente e credenziali sensibili in uno spazio di archiviazione protetto, ad esempio Secret Manager e Cloud KMS.
Specifica spazi dei nomi separati per i pod Kubernetes che accedono a dati sensibili e definisci i criteri di Kubernetes per renderli inaccessibili da altri spazi dei nomi. Segmenta i ruoli utilizzati per le operazioni e applica limiti dello spazio dei nomi.
Applica lo scambio di token per impedire l'esfiltrazione di token di lunga durata con privilegi elevati.