Versione 1.13

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 non si limitano alle impostazioni utilizzate per configurare e installare Anthos Service Mesh e descrive come utilizzare Anthos Service Mesh con altri prodotti e funzionalità 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 Anthos Service Mesh e gli utenti che eseguono i servizi in un Anthos Service Mesh. Le misure di sicurezza descritte qui sono utili anche per le organizzazioni che devono migliorare la sicurezza dei loro mesh di servizi in modo da soddisfare i requisiti di conformità.

Il documento è organizzato come segue:

Introduzione

Anthos Service Mesh fornisce funzionalità e strumenti che ti consentono di osservare, gestire e proteggere i servizi in modo unificato. Adotta un approccio incentrato sulle applicazioni e utilizza identità di applicazioni attendibili, anziché un approccio incentrato sull'IP della 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 di 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 open source Istio Service Mesh, che consente configurazioni e topologie sofisticate. A seconda della struttura dell'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 sono scelte per proteggere le applicazioni, ma in alcuni casi potrebbero essere necessarie configurazioni personalizzate o concedere eccezioni escludendo alcune app, porte o indirizzi IP dall'utilizzo di un mesh. È importante disporre di controlli per gestire le configurazioni di rete e le eccezioni di sicurezza.

Attacca vettori e rischi per la sicurezza

Vettori di attacco

La sicurezza di Anthos Service Mesh segue il modello di sicurezza Zero Trust, in base al quale le minacce alla sicurezza provengono sia dall'interno che dall'esterno del perimetro di sicurezza di un'organizzazione. Ecco alcuni esempi di tipi di attacchi di sicurezza che potrebbero minacciare le applicazioni in un mesh di servizi:

  • Attacchi per esfiltrazione di dati. ad esempio attacchi che intercettano dati o credenziali sensibili dal traffico da servizio a servizio.
  • Attacchi man in the middle. Ad esempio, un servizio dannoso che si presenta come servizio legittimo per ottenere o modificare la comunicazione tra i servizi.
  • Attacchi per riassegnazione dei privilegi. Ad esempio, attacchi che utilizzano l'accesso illecito a privilegi elevati per eseguire operazioni in una rete.
  • Attacchi DoS (denial of service).
  • Attacchi tramite bot che tentano di compromettere e manipolare i servizi per lanciare attacchi su altri servizi.

Gli attacchi possono anche essere categorizzati in base ai target:

  • Attacchi di rete interni in mesh. Attacchi mirati a manomettere, intercettare o eseguire lo spoofing delle comunicazioni mesh da servizio a servizio interno o piano di controllo.
  • Attacchi aerei 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 mesh. Attacchi mirati a manomettere, intercettare o eseguire lo spoofing della comunicazione al traffico in entrata o in uscita della rete mesh.
  • Attacchi per operazioni mesh. Attacchi mirati alle operazioni mesh. Gli hacker potrebbero tentare di ottenere privilegi elevati per eseguire operazioni dannose in un mesh, ad esempio modificando i relativi criteri di sicurezza e le immagini dei carichi di lavoro.

Rischi per la sicurezza

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

  • Protezione incompleta per sicurezza. Un mesh di servizi non è stato configurato con criteri di autenticazione e autorizzazione per proteggerne la sicurezza. Ad esempio, per un servizio mesh non vengono definiti criteri di autenticazione o autorizzazione.
  • Eccezioni alle norme sulla sicurezza. Per soddisfare i loro casi d'uso specifici, gli utenti possono creare eccezioni ai 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 tali casi, consulta la sezione Gestire in modo sicuro le eccezioni ai criteri.
  • Negligenza degli upgrade delle immagini. Potrebbero essere rilevate vulnerabilità per le immagini utilizzate in una rete mesh. Devi mantenere aggiornate le immagini del componente mesh e del carico di lavoro con le correzioni di vulnerabilità più recenti.
  • Mancanza di manutenzione (nessuna competenza o risorsa). Il software mesh e le configurazioni dei criteri richiedono una manutenzione ordinaria per sfruttare i più recenti meccanismi di protezione della sicurezza.
  • Mancanza di visibilità. Gli errori di configurazione o i criteri non sicuri di criteri mesh e il traffico/operatività mesh non vengono portati all'attenzione degli amministratori mesh.
  • Deviazione configurazione. La configurazione dei criteri in un mesh devia dalla fonte di riferimento.

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 su diversi livelli del sistema mesh e dalle relative applicazioni. L'intenzione ad alto livello della strategia di sicurezza Anthos Service Mesh proposta è quella di proteggere una rete di servizio attraverso l'integrazione di più meccanismi di sicurezza su livelli diversi, che contemporaneamente raggiungono la sicurezza di sistema complessiva nel modello di sicurezza Zero Trust. Il seguente diagramma mostra la strategia di sicurezza proposta per Anthos Service Mesh.

livello di sicurezza di Anthos Service Mesh

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

  • Sicurezza mesh 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 User Mesh Auth si integra con l'infrastruttura Google per autenticare le chiamate esterne dai browser web ai servizi che eseguono applicazioni web.
    • La gestione dei certificati di gateway 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 denial of service (DDoS) e di livello 7 distribuiti esternamente. Funge da firewall (applicazione web) per proteggere il mesh da attacchi di rete. Ad esempio, attacchi di inserimento e inserimento di codice da remoto.
    • I Controlli di servizio VPC e VPC proteggono il bordo della rete mesh tramite i controlli di accesso di rete privati.
  • Sicurezza del cluster
    • La crittografia TLS condivisa (MTLS) di Anthos Service Mesh applica la crittografia e l'autenticazione del traffico tra i carichi di lavoro.
    • La CA gestita, come l'autorità di certificazione Mesh di Anthos Service (Mesh CA) e il servizio di autorità di certificazione, esegue il provisioning e la gestione dei certificati utilizzati dai carichi di lavoro in modo sicuro.
    • L'autorizzazione di Anthos Service Mesh applica il controllo dell'accesso per i servizi mesh in base alle loro identità e altri attributi.
    • La dashboard per la sicurezza di Anthos fornisce il monitoraggio delle configurazioni dei criteri di sicurezza e dei criteri di rete Kubernetes per i carichi di lavoro.
    • Il criterio di rete Kubernetes applica il 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 difende dagli attacchi al piano di controllo. Questa protezione impedisce agli utenti malintenzionati di modificare, sfruttare o cancellare i dati di configurazione dei servizi e delle reti mesh.
  • Sicurezza del carico di lavoro
    • Resta al passo con le release per la sicurezza di Anthos Service Mesh per assicurarti che i programmi binari di Anthos Service Mesh in esecuzione nel tuo mesh siano privi di vulnerabilità pubbliche.
    • Workload Identity consente ai carichi di lavoro di ottenere credenziali per chiamare in modo sicuro i servizi Google.
    • Cloud Key Management Service (Cloud KMS) protegge le credenziali o i dati 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. Il servizio CA, utilizzato per emettere certificati nei carichi di lavoro mesh, supporta le chiavi di firma supportate per cliente e HMS e gestite da Cloud KMS.
    • Kubernetes CNI (Container Network Interface) previene gli attacchi di escalation dei privilegi eliminando la necessità di un container init Anthos Service Mesh con privilegi.
  • Sicurezza dell'operatore
    • Il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes limita l'accesso alle risorse Kubernetes e limita le autorizzazioni degli operatori per mitigare gli attacchi derivanti da operatori dannosi o dalla rappresentazione dell'operatore.
    • Anthos Policy Controller convalida e verifica le configurazioni dei criteri nel mesh per evitare configurazioni errate.
    • Autorizzazione binaria di Google Cloud garantisce che le immagini del carico di lavoro nel mesh siano quelle autorizzate dagli amministratori.
    • L'audit logging di Google Cloud verifica le operazioni 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 del cluster

Abilita TLS reciproco rigoroso

Un attacco man-in-the-middle (MitM) cerca di inserire un'entità dannosa tra due persone che comunicano per comunicare o intercettare la comunicazione. Anthos Service Mesh difende da MitM e dagli attacchi di esfiltrazione di dati applicando l'autenticazione mTLS e la crittografia per tutte le parti comunicanti. La modalità permissiva utilizza mTLS quando entrambi i lati lo supportano, ma consentono connessioni senza mTLS. Al contrario, il protocollo mTLS in modalità retta richiede che il traffico sia criptato e autenticato con mTLS e non consente il traffico di testo normale.

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

Abilita controlli di accesso

I criteri di sicurezza di Anthos Service Mesh (come i criteri di autenticazione e autorizzazione) devono essere applicati a tutto il traffico in entrata e in uscita dalla rete, a meno che non ci siano giustificazioni solide 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 l'articolo Gestire in modo sicuro le eccezioni ai criteri di Anthos Service Mesh.

Il controllo dell'accesso ai servizi è fondamentale per impedire l'accesso non autorizzato ai servizi. L'applicazione forzata di mTLS cripta e autentica una richiesta, ma un mesh richiede comunque i criteri di autorizzazione di Anthos Service Mesh per applicare il controllo 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 una modalità flessibile per configurare i controlli di accesso per difendere i tuoi servizi dagli accessi non autorizzati. I criteri di autorizzazione di Anthos Service Mesh devono essere applicati in base alle identità autenticate derivate dai risultati di autenticazione: le autenticazioni basate su mTLS o JSON Web Token (JWT) devono essere utilizzate insieme come parte dei criteri di autorizzazione di Anthos Service Mesh.

Applica i criteri di autenticazione di Anthos Service Mesh

JSON Web Token (JWT)

Oltre all'autenticazione mTLS, gli amministratori mesh possono richiedere un servizio per autenticare e autorizzare le richieste in base a JWT. Anthos Service Mesh non agisce come provider JWT, ma autentica i JWT in base agli endpoint JWKS (Web Key Set) 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 una prova che venga chiamato per conto del chiamante finale. L'applicazione dell'autenticazione JWT difende dagli attacchi che accedono a un servizio senza credenziali valide e per conto di un utente finale reale.

Autenticazione utente di Anthos Service Mesh

L'autenticazione degli utenti di Anthos Service Mesh è una soluzione integrata per l'autenticazione degli utenti finali 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 web e utilizza i criteri di autorizzazione Anthos Service Mesh per il controllo degli accessi.

Applicare i criteri di autorizzazione

Controllo dei criteri di autorizzazione di Anthos Service Mesh:

  • 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 il controllo dell'accesso in base alle identità effettive utilizzate dai servizi, alle proprietà del livello di applicazione (Livello 7) del traffico (ad esempio le intestazioni delle richieste) e alle proprietà del livello di rete (Livello 3 e 4) quali gli intervalli IP e le porte.

I criteri di autorizzazione di Anthos Service Mesh devono essere applicati in base alle identità autenticate ricavate dai risultati di autenticazione per difendersi da accesso non autorizzato a dati o servizi.

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

I criteri di autorizzazione dovrebbero limitare il più possibile l'attendibilità. 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 di 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 di Kubernetes e sugli spazi dei nomi di Kubernetes.

Applicare uno scambio di token per l'accesso ai servizi mesh

Per difenderti dagli attacchi di replica dei token che rubano i token e riutilizzano i token rubati per accedere ai servizi mesh, un token in una richiesta esterna al mesh deve essere scambiato con un token mesh interno 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 autenticati e autorizzati dal servizio mesh. Un token esterno al mesh potrebbe durare a lungo. Per difenderti dagli attacchi di riproduzione di token, un token dall'esterno del mesh deve essere scambiato con un token interno di mesh di breve durata con un ambito limitato nel traffico in entrata del mesh. Il servizio mesh autentica un token interno mesh e autorizza la richiesta di accesso in base al token interno 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. La durata limitata del token scambiato riduce notevolmente le possibilità di un attacco di ripetizione del token.

Gestisci in modo sicuro le eccezioni ai criteri di Anthos Service Mesh

Potresti avere casi d'uso speciali per il mesh di servizi. Ad esempio, potresti dover esporre una determinata porta di rete al traffico di testo normale. Per soddisfare scenari specifici di utilizzo, a volte potresti dover creare eccezioni per consentire l'esclusione di determinati tipi di traffico interno o esterno dai criteri di sicurezza di Anthos Service Mesh, con conseguente rischio di sicurezza.

Potresti avere motivi legittimi per ignorare 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 escludere il traffico proveniente dalla sidecar Envoy. Oltre alle annotazioni per escludere il traffico, puoi aggirare il mesh se esegui il deployment di un'applicazione con l'inserimento collaterale disattivato. Ad esempio, aggiungendo un'etichetta sidecar.istio.io/inject="false" al pod dell'applicazione.

Ignorare i criteri di sicurezza di Anthos Service Mesh ha un impatto negativo sulla sicurezza complessiva del sistema. Ad esempio, se il protocollo mTLS e i criteri di autorizzazione di Anthos Service Mesh vengono ignorati per una porta di rete mediante annotazioni, non sarà possibile controllare il traffico sulla porta e potrebbe essere possibile intercettare o modificare il traffico. Inoltre, l'esclusione dei criteri di Anthos Service Mesh influisce anche sui criteri non di sicurezza, come i criteri di rete.

Quando il criterio di sicurezza di Anthos Service Mesh viene ignorato per una porta o un IP (intenzionale o non intenzionale), dovrebbero essere attive altre misure di sicurezza per proteggere il mesh e monitorare le eccezioni della sicurezza, potenziali buchi di sicurezza e stato generale dell'applicazione della sicurezza. Per proteggere il tuo mesh in scenari puoi:

  • Assicurati che il traffico che ignori le sidecar sia criptato in modo nativo e che sia autenticato per evitare 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 al traffico di passare attraverso le porte con il criterio di sicurezza Anthos Service Mesh applicato.
  • Applica Anthos Policy Controller per convalidare automaticamente i criteri di Anthos Service Mesh. Ad esempio, imporre che i sidecar di Anthos Service Mesh vengano sempre inseriti nei carichi di lavoro.

Applica i criteri di rete di Kubernetes

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

Per creare una solida strategia di sicurezza per un mesh di servizi, è necessario applicare i meccanismi di sicurezza della piattaforma sottostante per funzionare congiuntamente ai criteri di sicurezza di Anthos Service Mesh.

I criteri di rete di Kubernetes operano a livello di rete (L3 e L4) per gli indirizzi IP e le porte sui 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 mesh può configurare i criteri di rete di Kubernetes in modo da consentire al traffico solo l'utilizzo delle porte in cui è applicata la norma di sicurezza Anthos Service Mesh. Se tutto il traffico deve essere applicato con mTLS di 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 mesh può anche configurare i criteri di rete di Kubernetes per limitare la connettività delle porte con le eccezioni dei criteri. Ad esempio, limita la connettività di queste porte in 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. Pertanto, solo i chiamanti con credenziali valide (certificati JWT o X.509 Kubernetes emessi da CA consentite) 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 Kubernetes per isolare lo spazio dei nomi di sistema Anthos Service Mesh (per impostazione predefinita, istio-system) dagli spazi dei nomi e dai client non gestiti all'esterno della rete, consentendo ai piani dati di accedere al piano di controllo. Le regole firewall VPC possono impedire a traffico esterno a un cluster di raggiungere Istiod. Con queste misure di isolamento della rete, un utente esterno al mesh non potrà accedere al piano di controllo, anche se l'utente ha una credenziale valida. Per i piani di controllo gestiti da Google, Google gestisce la sicurezza per i piani di controllo e non sono necessari criteri di isolamento di rete per i piani di controllo.

Applica limiti 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:

  • Applicare i controlli di 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 mesh deve eseguire il deployment di un criterio di rete Kubernetes che consenta il traffico solo all'interno dello spazio dei nomi: nessun traffico in entrata o in uscita dallo spazio dei nomi.
  • Applica i criteri Kubernetes RBAC.
    • I ruoli degli amministratori delle applicazioni devono essere associati a uno spazio dei nomi.
    • Consenti solo agli amministratori mesh di avere ClusterRole.

Applicare i criteri di Kubernetes RBAC

Gli amministratori di mesh devono applicare i criteri RBAC di Kubernetes per controllare chi è autorizzato ad accedere alle risorse Kubernetes e ad aggiornarle. Il 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 ad aggirare le applicazioni 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 cui ha bisogno. Per guide dettagliate ed esempi di configurazione di RBAC, consulta l'articolo Configurare il controllo dell'accesso 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 mesh perimetrale

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

Controllo dell'accesso in entrata del cluster

Anthos Service Mesh riceve il traffico esterno in entrata attraverso il gateway in entrata. I servizi esposti dal gateway in entrata potrebbero subire attacchi da origini esterne. Gli amministratori della sicurezza devono sempre assicurarsi che i servizi esposti al traffico esterno tramite gateway in entrata siano sufficientemente protetti per difendersi dagli attacchi.

Ingress dovrebbe applicare autenticazione e autorizzazione per i servizi esposti a chiamanti esterni.

  • Applica criteri di sicurezza in entrata del cluster. Quando il cluster deve ricevere traffico esterno, l'amministratore mesh deve applicare i criteri di sicurezza in entrata, inclusi i criteri gateway TLS, Anthos e l'autenticazione TLS e mesh di servizi Anthos, per autenticare le richieste esterne e verificare che le richieste esterne siano autorizzate ad accedere ai servizi esposti dal gateway in entrata. L'applicazione di criteri di sicurezza in entrata difende dagli attacchi dall'esterno del mesh che tenta di accedere a un servizio senza credenziali o autorizzazioni valide.
  • Utilizzare Cloud Armor come web applicazione firewall (WAF) per la difesa dagli attacchi basati sul Web (ad esempio, attacchi di iniezione e attacchi di esecuzione remota). Per ulteriori informazioni, consulta la sezione Dall'inizio alla fase mesh: esposizione delle applicazioni mesh di servizi tramite GKE Ingress.

Regola traffico in uscita dal cluster

La sicurezza del traffico in uscita dal cluster è fondamentale per la sicurezza del mesh, perché i criteri di sicurezza in uscita possono difendersi dagli attacchi di esfiltrazione dei dati, applicare filtri del traffico in uscita e applicare l'origine TLS per il traffico in uscita. Gli amministratori della sicurezza devono regolare e controllare il traffico in uscita del cluster.

Oltre a utilizzare i firewall 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 per il passaggio attraverso i gateway in uscita.

I criteri in uscita possono mitigare i seguenti attacchi:

  • Attacchi per esfiltrazione di dati.
  • I pod di servizio possono essere sfruttati da utenti malintenzionati se i loro CVE non sono soggetti a patch. I pod compromessi possono diventare un botnet controllato da 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 siano autorizzati a inviare traffico a host specifici all'esterno del mesh. Allo stesso tempo, per il traffico che lascia il mesh, invece di gestire l'origine TLS su singoli file collaterali, TLS può provenire da gateway in uscita. Ciò fornisce un modo uniforme e più sicuro per generare traffico TLS, perché 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 i criteri di sicurezza in entrata e in uscita, blocca l'accesso esterno utilizzando il cluster privato o i controlli del servizio VPC laddove possibile. Mentre i criteri di sicurezza sono controllati dagli amministratori della sicurezza del mesh, la configurazione della cluster privata 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 in modo da:

  • Impedisci ai servizi di accedere alle risorse esterne.
  • Impedisci agli utenti esterni di accedere ai servizi in un perimetro di sicurezza.

I Controlli di servizio VPC aiutano a difendersi dagli attacchi di esfiltrazione di dati e da impedire a utenti esterni esterni di accedere ai servizi all'interno di un mesh.

Difenditi dagli attacchi DDoS esterni

Gli attacchi DDoS esterni possono sovraccaricare i gateway in entrata e i servizi di backend, impedendo la gestione delle richieste legittime. Cloud Armor può essere utilizzato per difendersi dagli attacchi DDoS. Cloud Armor si 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 mesh

È importante considerare la sicurezza per le operazioni amministrative e qualsiasi automatizzazione creata intorno al tuo mesh, ad esempio CI/CD. Le seguenti pratiche mirano a garantire che il mesh possa essere utilizzato in sicurezza senza il rischio di esporre servizi ad attacchi aggiuntivi.

Segmentare i ruoli utilizzati per le operazioni mesh

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

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

Esistono diverse categorie di operatori. Ad esempio, gli operatori di cluster e gli spazi dei nomi. È importante impedire la riassegnazione dei privilegi da parte di un operatore, causando l'accesso illecito alle 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 accidentalmente configurare in modo errato i criteri di Anthos Service Mesh, con conseguenti incidenti di sicurezza gravi. Per evitare errori di configurazione e convalidare automaticamente i criteri di Anthos Service Mesh, gli amministratori di mesh possono utilizzare Policy Controller per applicare i vincoli alle configurazioni dei criteri.

Per evitare di fidarsi troppo delle persone con le autorizzazioni per aggiornare i criteri di sicurezza di Anthos Service Mesh e per automatizzare la convalida dei criteri di Anthos Service Mesh, gli amministratori del mesh devono implementare vincoli sui criteri di Anthos 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 sulle violazioni. Policy Controller può convalidare automaticamente il deployment delle risorse nel mesh, ad esempio convalidare che le annotazioni in un deployment non bypassano i criteri di Anthos Service Mesh, convalidare che i criteri di Anthos Service Mesh siano come previsto e convalidare che un deployment non includa funzionalità root (come NET_ADMIN e NET_RAW).

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

Di seguito sono riportati alcuni esempi di applicazione dei criteri di sicurezza di Anthos Policy Controller:

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

  • Applica il livello peer strict mTLS a livello di rete mesh.
  • L'opzione Applica tutti i protocolli PeerAuthentication non può sovrascrivere il protocollo mTLS in modalità restrittiva.
  • Applica il criterio default allow AutorizzazionePolicy di livello mesh.
  • Applica i pattern sicuri di AuthorizationPolicy.
  • Applica i sidecar Anthos Service Mesh sempre inseriti nei carichi di lavoro.

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

Usa un approccio GitOps con Config Sync per impedire la deviazione della configurazione

La deviazione della configurazione si verifica quando la configurazione dei criteri in un mesh devia dalla sua fonte di verità. Config Sync può essere utilizzato per impedire le deviazioni dalla configurazione.

Applica audit logging e monitoraggio

Gli amministratori di 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, l'accesso che non è stato eseguito tramite file collaterali, l'accesso che non aveva credenziali valide ma ha raggiunto un servizio.

Anche se il software di osservabilità open source (ad esempio, Prometheus) può essere utilizzato con Anthos Service Mesh, consigliamo vivamente di utilizzare la suite operativa di Google Cloud (in precedenza Stackdriver). La soluzione integrata di osservabilità per Google Cloud fornisce logging, raccolta delle metriche, monitoraggio e avvisi, completamente gestiti e facili 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, chiamata autorità di certificazione Anthos Service Mesh (Mesh CA).

Se utilizzi l'autorità di certificazione (CA) Istio non gestita, ospitata come parte di Istiod, la chiave di firma della CA è 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, dal momento che un operatore potrebbe essere in grado di utilizzare la chiave CA indipendentemente dalla CA di Istiod e di firmare potenzialmente i certificati dei carichi di lavoro in modo indipendente. Esiste inoltre il rischio che una chiave di firma di CA autogestita possa essere divulgata accidentalmente a causa di un errore operativo.

Per proteggere la chiave di firma della CA, l'amministratore della rete mesh può eseguire l'upgrade del mesh per utilizzare Mesh CA o Servizio dell'autorità di certificazione (CA Service), che sono protetti e gestiti da Google (come la rotazione della chiave della CA). Rispetto a Mesh CA, il servizio CA supporta le chiavi di firma supportate per cliente e HSM tramite Cloud KMS supportato da Cloud HSM.

Sicurezza del carico di lavoro

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

Limita i privilegi di pod

Un pod di Kubernetes può avere privilegi che incidono su altri pod del nodo o del cluster. È importante applicare limitazioni della sicurezza ai pod dei carichi di lavoro per evitare che un pod compromesso possa avviare attacchi contro il 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 devono essere eseguiti con il minor numero di privilegi possibile.
  • I pod Kubernetes in esecuzione in modalità privilegiata possono manipolare stack di rete e altre funzionalità del kernel nell'host. Anthos Policy Controller può essere utilizzato per impedire l'esecuzione dei pod con container con privilegi.
  • Anthos Service Mesh può essere configurato in modo da utilizzare un container init per configurare il reindirizzamento del traffico degli IPtables alla sidecar. L'utente deve eseguire i deployment del carico di lavoro per disporre dei privilegi necessari per il deployment dei container con funzionalità NET_ADMIN e NET_RAW. Per evitare il rischio di eseguire container con privilegi più elevati, gli amministratori di mesh possono invece attivare il plug-in CNI di Istio per configurare il reindirizzamento del traffico sulle sidecar.

Immagini container sicure

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

Riduci le vulnerabilità mesh

  • Container Analysis. Container Analysis può analizzare e identificare vulnerabilità sui carichi di lavoro GKE.
  • Gestione di CVE (vulnerabilità ed esposizioni comuni). Quando viene rilevata una vulnerabilità in un'immagine container, gli amministratori di mesh devono risolvere il problema nel più breve tempo possibile. Per Anthos Service Mesh gestito da Google con piano dati gestito da Google, Google gestisce automaticamente l'applicazione di patch ai CVE che incidono sulle immagini mesh.

Utilizzare Workload Identity per accedere in modo sicuro 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 all'archiviazione di una chiave dell'account di servizio in un secret Kubernetes e all'uso della chiave dell'account di servizio per accedere ai servizi Google non è sicura a causa dei rischi di fuga di credenziali, escalation dei privilegi, divulgazione di informazioni e non repudiazione.

Monitorare lo stato di sicurezza tramite la dashboard per la sicurezza e la telemetria

Un mesh di servizi può presentare eccezioni di sicurezza e potenziali scappatoie. È fondamentale identificare e monitorare lo stato della sicurezza di un mesh, inclusi i criteri di sicurezza applicati, le eccezioni alla sicurezza e i potenziali errori. È possibile utilizzare la dashboard per la sicurezza di Anthos e la telemetria per individuare e monitorare lo stato di sicurezza del mesh.

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

La dashboard per la sicurezza di Anthos 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 (criteri di rete Kubernetes, criteri di autorizzazione binaria e criteri di controllo dell'accesso ai servizi) e criteri di autenticazione (mTLS).

Sicurezza per dati utente e credenziali sensibili

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

  • Se possibile, archivia i dati utente e le credenziali sensibili in uno spazio di archiviazione protetto, come Secret Manager e Cloud KMS.
  • Designa spazi dei nomi separati per i pod Kubernetes che accedono ai 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 limiti degli spazi dei nomi.
  • Applica scambio di token per impedire l'esfiltrazione di token con privilegi a lunga durata.

Passaggi successivi