Best practice per la sicurezza di Cloud Service Mesh

Questo documento descrive le best practice per stabilire e gestire una Cloud Service Mesh in esecuzione su Google Kubernetes Engine (GKE). Le linee guida nel documento va oltre le impostazioni utilizzate per configurare e installare Cloud Service Mesh e descrive come utilizzare Cloud Service Mesh con altri servizi Google Cloud prodotti e funzionalità per la protezione dalle minacce alla sicurezza che le applicazioni in una rete mesh.

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. La le misure di sicurezza descritte qui sono utili anche alle aziende che devono migliorare la sicurezza dei loro mesh di servizi per soddisfare i requisiti di conformità.

Il documento è organizzato come segue:

Introduzione

Cloud Service Mesh fornisce funzionalità e strumenti utili per osservare, gestire e sicuri in modo unificato. Prende un approccio incentrato sull'applicazione utilizza identità di applicazione attendibili piuttosto che 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. Cloud Service Mesh offre un controllo dichiarativo sulla rete il che aiuta a disaccoppiare il lavoro dei team responsabili la distribuzione e il rilascio di funzionalità dell'applicazione dalle responsabilità responsabili della sicurezza e del networking.

Cloud Service Mesh si basa sull'open source Mesh di servizi Istio, che consente di creare configurazioni e topologie sofisticate. In base alla struttura, dell'organizzazione, uno o più team o ruoli potrebbero l'installazione e la configurazione di un mesh. Vengono scelte le impostazioni predefinite di Cloud Service Mesh ma in alcuni casi potrebbe essere necessario configurazioni personalizzate o di concedere eccezioni escludendo determinate app, porte o indirizzi IP che partecipano a un mesh. Avere dei controlli in atto per governare le configurazioni mesh e le eccezioni di sicurezza.

Vettori d’attacco e rischi per la sicurezza

Vettori d'attacco

La sicurezza di Cloud Service Mesh segue il modello di sicurezza Zero Trust che presuppone le minacce alla sicurezza provengono sia dall’interno che dall’esterno perimetro di sicurezza. Esempi di tipi di attacchi alla sicurezza che potrebbero essere a rischio le applicazioni in un mesh di servizi includono:

  • Attacchi di esfiltrazione di dati. Ad esempio, attacchi che intercettano sensibili e credenziali o i dati o le credenziali dal traffico tra servizi.
  • Attacchi man in the middle. Ad esempio, un servizio dannoso che maschera la maschera come servizio legittimo per ottenere o modificare la comunicazione tra i servizi di machine learning.
  • Attacchi con escalation 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 botnet che tentano di compromettere e manipolare i servizi per avviarli ad altri servizi.

Gli attacchi possono essere classificati anche in base agli obiettivi degli attacchi:

  • Attacchi di rete interna mesh. Attacchi finalizzati a manomettere, intercettare o spoofing del mesh di servizi interni da service-to-service o service-to-control-plane comunicazione.
  • Attacchi al piano di controllo. Attacchi volti a far cadere il piano di controllo malfunzionamenti (come un attacco DoS) o esfiltrazione di dati sensibili dal piano di controllo.
  • Attacchi a spillo della rete mesh. Attacchi finalizzati a manomissioni, intercettazioni o spoofing le comunicazioni in entrata o in uscita dalla rete mesh.
  • Attacchi alle operazioni del mesh. Attacchi mirati alle operazioni del mesh. Gli aggressori potrebbero cercano di ottenere privilegi elevati per condurre operazioni dannose in un mesh, come la modifica dei criteri di sicurezza e delle immagini dei carichi di lavoro.

Rischi per la sicurezza

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

  • Protezione della sicurezza incompleta. Non è stato configurato un mesh di servizi con di autenticazione e autorizzazione per proteggerne la sicurezza. Per Ad esempio, non vengono definiti criteri di autenticazione e servizi in un mesh.
  • Eccezioni alle norme di sicurezza. Per venire incontro ai loro casi d'uso specifici, possono creare eccezioni alle norme di sicurezza per determinati tipi di traffico (interni esterne) per essere escluse dai criteri di sicurezza di Cloud Service Mesh. Per garantire la sicurezza gestire questi casi, consulta la sezione Gestire in modo sicuro le eccezioni ai criteri.
  • Trascurato gli upgrade delle immagini. Potrebbero essere scoperte le vulnerabilità delle immagini utilizzata in una mesh. Devi mantenere le immagini del componente mesh e del carico di lavoro con le ultime correzioni di vulnerabilità.
  • Mancanza di manutenzione (nessuna competenza o risorsa). Il software mesh e di configurazione dei criteri richiedono una manutenzione regolare per poter sfruttare i più recenti meccanismi di protezione della sicurezza.
  • Mancanza di visibilità. Errori di configurazione o configurazioni non sicure del mesh del traffico e le operazioni/attività di rete mesh anormali non vengono l'attenzione degli amministratori della rete mesh.
  • Deviazione dalla configurazione: La configurazione dei criteri in un 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 diversi livelli del sistema mesh e delle sue applicazioni. La configurazione di alto livello la strategia di sicurezza di Cloud Service Mesh proposta è proteggere un servizio mesh attraverso l'integrazione di più meccanismi di sicurezza a diversi livelli, raggiungere insieme la sicurezza complessiva del sistema nell'ambito del modello di sicurezza Zero Trust. Il seguente diagramma mostra la strategia di sicurezza di Cloud Service Mesh proposta.

security posture di Cloud Service Mesh

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

  • Sicurezza perimetrale mesh
    • La sicurezza in entrata di Cloud Service Mesh consente controllo dell'accesso per il traffico e protegge l'accesso esterno alle API esposte dai servizi nella rete.
    • La sicurezza in uscita di Cloud Service Mesh regola il traffico in uscita carichi di lavoro interni ed esterni.
    • Autorizzazione utente Cloud Service Mesh si integra con l'infrastruttura Google per autenticare le chiamate esterne dai browser ai servizi che eseguono le applicazioni web.
    • Gestione dei certificati gateway Cloud Service Mesh protegge e ruota le chiavi private e i certificati X.509 utilizzati Gateway in entrata e in uscita di Cloud Service Mesh utilizzando Certificate Authority Service.
    • Cloud Armor può difendere gli attacchi DDoS (Distributed Denial-of-Service) e di livello 7 esterni. it funge da web application firewall (WAF) per proteggere il mesh di attacchi di rete. Ad esempio, iniezione ed esecuzione di codice in remoto attacchi informatici.
    • Controlli di servizio VPC e VPC il perimetro della rete mesh tramite i controlli di accesso alla rete privata.
  • Sicurezza del cluster
    • Il protocollo TLS reciproco (mTLS) di Cloud Service Mesh applica il traffico dai carichi di lavoro ai carichi di lavoro la crittografia e l'autenticazione.
    • CA gestita, come l'autorità di certificazione Cloud Service Mesh e Certificate Authority Service, esegue il provisioning e la gestione dei certificati utilizzati in modo sicuro dai carichi di lavoro.
    • L'autorizzazione di Cloud Service Mesh applica controllo dell'accesso ai servizi mesh in base alla loro identità e ad altri attributi.
    • Dashboard per la sicurezza di GKE Enterprise monitora le configurazioni dei criteri di sicurezza e i criteri di rete Kubernetes per i carichi di lavoro.
    • Il criterio di rete di Kubernetes applica il controllo dell'accesso ai pod in base all'IP indirizzi IP, etichette pod, spazi dei nomi e altro ancora.
    • La sicurezza del piano di controllo protegge dagli attacchi al piano. Questa protezione impedisce agli utenti malintenzionati di modificare, sfruttare o perdita di dati dei servizi e della configurazione mesh.
  • Sicurezza dei carichi di lavoro
    • Resta al passo con le release di sicurezza di Cloud Service Mesh per assicurarti che I file binari di Cloud Service Mesh in esecuzione nel mesh sono privi di elementi noti pubblicamente le vulnerabilità.
    • Identità carico di lavoro 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 i moduli di sicurezza hardware (HSM). Ad esempio, i carichi di lavoro possono utilizzare Cloud KMS per archiviare credenziali o altri dati sensibili. CA Service: utilizzato per per emettere certificati per i carichi di lavoro mesh, supportando i Chiavi di firma supportate da HSM gestite da Cloud KMS.
    • Kubernetes CNI (Container Network Interface) impedisce il privilegio e la escalation degli attacchi, eliminando la necessità di un Container init di Cloud Service Mesh.
  • Sicurezza dell'operatore
    • Controllo dell'accesso basato su ruoli (RBAC) di Kubernetes limita l'accesso a le risorse Kubernetes e limita le autorizzazioni degli operatori per mitigare attacchi che hanno origine da operatori dannosi o impersonificazione degli operatori.
    • Controller dei criteri di GKE Enterprise convalida e verifica le configurazioni dei criteri nel mesh per evitare configurazioni errate.
    • Autorizzazione binaria Google Cloud garantisce che le immagini dei carichi di lavoro nel mesh siano quelle autorizzate per gli amministratori.
    • L'audit logging di Google Cloud controlla le operazioni della rete mesh.

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

diagramma di sicurezza flusso di traffico

Sicurezza del cluster

Attiva TLS reciproco rigoroso

Un attacco man in the middle (MitM) tenta di inserire un'entità dannosa tra due comunicano con le parti al fine di intercettare o manipolare la comunicazione. Cloud Service Mesh si difende dagli attacchi MitM e di esfiltrazione di dati applicando Autenticazione e crittografia mTLS per tutte le parti comunicative. La modalità permissiva utilizza mTLS quando entrambi i lati supportano ma consente connessioni senza mTLS. Al contrario, la modalità mTLS restrittiva richiede il traffico deve essere criptato e autenticato con mTLS e non consente il testo normale per via del traffico.

Cloud Service Mesh ti consente configurare la versione TLS minima per le connessioni TLS tra i carichi di lavoro in modo da soddisfare i requisiti di sicurezza di conformità.

Per ulteriori informazioni, vedi Cloud Service Mesh ad esempio: mTLS | Applicazione di mTLS a livello di mesh.

Attiva i controlli dell'accesso

Criteri di sicurezza di Cloud Service Mesh (come autenticazione e autorizzazione criteri) devono essere applicate a tutto il traffico in entrata e in uscita dal mesh, a meno che non sono giustificazioni solide per escludere un servizio o un pod da Cloud Service Mesh criteri di sicurezza. In alcuni casi, gli utenti potrebbero avere motivi legittimi per eludere 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. A proteggere Cloud Service Mesh in questi casi d'uso, consulta Gestisci in modo sicuro le eccezioni ai criteri di Cloud Service Mesh.

Controllo dell'accesso ai servizi è fondamentale per impedire l'accesso non autorizzato i servizi di machine learning. L'applicazione forzata di mTLS cripta e autentica una richiesta, ma la rete mesh esigenze Criteri di autorizzazione di Cloud Service Mesh per applicare controllo dell'accesso ai servizi. Ad esempio, il rifiuto di una richiesta da un client autenticato.

I criteri di autorizzazione di Cloud Service Mesh forniscono un modo flessibile per configurare l'accesso per difendere i servizi dagli accessi non autorizzati. Cloud Service Mesh i criteri di autorizzazione devono essere applicati in base alle identità autenticate derivata dai risultati dell'autenticazione: mTLS o JSON Web Token (JWT) basato le autenticazioni devono essere utilizzate insieme come parte dell'autorizzazione di Cloud Service Mesh criteri.

Applica i criteri di autenticazione di Cloud Service Mesh

JWT (JSON Web Token)

Oltre all'autenticazione mTLS, gli amministratori del mesh possono richiedere un servizio per autenticare e autorizzare le richieste in base al JWT. Cloud Service Mesh non agisce come provider JWT, ma autentica i JWT in base al degli endpoint JWKS (JSON Web Key Set). L'autenticazione JWT può essere applicata ai gateway in entrata per il traffico esterno o ai servizi interni per i servizi in-mesh per via del traffico. L'autenticazione JWT può essere combinata con l'autenticazione mTLS quando un modello JWT viene utilizzata come credenziale per rappresentare il chiamante finale e il servizio richiesto deve dimostrare che il chiamante sta ricevendo la chiamata per conto del chiamante finale. Applicazione L'autenticazione JWT difende dagli attacchi che accedono a un servizio senza e per conto di un utente finale reale.

Autenticazione degli utenti Cloud Service Mesh

Autenticazione degli utenti Cloud Service Mesh è una soluzione integrata per l'autenticazione e l'accesso degli utenti finali basati su browser dei carichi di lavoro. Integra un mesh di servizi con Identity esistenti Provider (IdP) per implementare un accesso OpenID Connect (OIDC) basato sul web standard e il flusso di consenso e utilizza i criteri di autorizzazione di Cloud Service Mesh per l'accesso controllo.

Applicare i criteri di autorizzazione

Controllo dei criteri di autorizzazione di Cloud 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 in base le identità effettive con cui vengono eseguiti i servizi, livello di applicazione (livello 7) le proprietà del traffico (ad esempio le intestazioni delle richieste) e il livello di rete (livello 3) e livello 4) come gli intervalli IP e le porte.

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

Per impostazione predefinita, l'accesso a un servizio dovrebbe essere negato a meno che non venga stabilito 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 negano le richieste di accesso.

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

I criteri di autorizzazione possono essere utilizzati insieme Criteri di rete di Kubernetes, che operano esclusivamente a livello di rete (livello 3 e 4) e che controllano accesso di rete per indirizzi IP e porte sui pod Kubernetes e Kubernetes spazi dei nomi.

Imporre lo scambio di token per l'accesso ai servizi mesh

Per difendersi dagli attacchi di ripetizione dei token che rubano i token e riutilizzano i token rubati per accedere ai servizi mesh, un token in una richiesta dall'esterno del mesh deve essere scambiato con un token interno del mesh di breve durata sul perimetro del mesh.

Una richiesta dall'esterno del mesh di accedere a un servizio mesh deve includere un come JWT o cookie, per essere autenticati e autorizzati dal un servizio mesh. Un token esterno al mesh può avere una lunga durata. Per difendersi attacchi di ripetizione di token, un token dall'esterno del mesh dovrebbe essere sostituito token interno al mesh di breve durata con un ambito limitato in ingresso del mesh. Il servizio mesh autentica un token interno mesh e autorizza l'accesso. basata sul token interno della rete mesh.

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

Gestisci in modo sicuro le eccezioni dei criteri di Cloud Service Mesh

Il tuo mesh di servizi potrebbe avere casi d'uso speciali. Ad esempio, potresti dover una determinata porta di rete al traffico di testo normale. Per soddisfare specifiche di utilizzo, a volte può essere necessario creare eccezioni per consentire traffico interno o esterno da escludere dalla sicurezza di Cloud Service Mesh di sicurezza, il che crea problemi di sicurezza.

Potresti avere motivi legittimi per bypassare i criteri di sicurezza di Cloud Service Mesh per alcune porte e intervalli IP. Puoi aggiungere annotazioni (ad es. excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) ai pod per escludere il traffico dalla gestione Sidecar di Envoy. Oltre alle annotazioni per escludere il traffico, puoi bypassare la rete mesh eseguendo il deployment di un'applicazione iniezione collaterale disattivata. Ad esempio, aggiungendo l'etichetta sidecar.istio.io/inject="false" alla un pod di applicazione.

L'elusione dei criteri di sicurezza di Cloud Service Mesh ha un impatto negativo in generale sicurezza del sistema. Ad esempio, se il protocollo mTLS e i criteri di autorizzazione di Cloud Service Mesh vengono bypassati per una porta di rete mediante annotazioni, non vi sarà alcun accesso controllo del traffico sulla porta e intercettazioni o modifica del traffico possibile. Inoltre, anche l'aggiramento dei criteri di Cloud Service Mesh influisce criteri non di sicurezza, come i criteri di rete.

Quando il criterio di sicurezza di Cloud Service Mesh viene ignorato per una porta o un IP ( intenzionalmente o involontariamente), dovrebbero essere presenti altre misure di sicurezza garantire la sicurezza della rete mesh e monitorare le eccezioni alla sicurezza, le potenziali le lacune e lo stato generale delle misure di sicurezza. Per proteggere la rete mesh in scenari in cui puoi:

  • Assicurati che il traffico che aggira i file collaterali sia criptato in modo nativo e autenticati 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 alle norme per consentire solo il traffico proveniente da un altro nello stesso spazio dei nomi) o di consentire solo al traffico di passare porte con il criterio di sicurezza Cloud Service Mesh applicato.
  • Applica GKE Enterprise Policy Controller a convalidare automaticamente i criteri di Cloud Service Mesh. Ad esempio, fai in modo che i file collaterali di Cloud Service Mesh vengano sempre inseriti carichi di lavoro con scale out impegnativi.

Applica i criteri di rete di Kubernetes

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

Per formare una solida postura di sicurezza per un mesh di servizi, i meccanismi di sicurezza la piattaforma sottostante deve essere imposta in modo da funzionare congiuntamente con Cloud Service Mesh criteri di sicurezza.

Criteri di rete di Kubernetes operano a livello di rete (L3 e L4) per indirizzi IP e porte e spazi dei nomi di 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 della rete mesh può configurare i criteri di rete di Kubernetes Consentire al traffico solo di utilizzare le porte con il criterio di sicurezza di Cloud Service Mesh applicato. Se tutto il traffico deve essere applicato in modo forzato con il protocollo mTLS di Cloud Service Mesh, l'amministratore può configurare un criterio di rete Kubernetes per consentire il traffico solo sulle porte configurato con il criterio mTLS di Cloud Service Mesh. L'amministratore della rete mesh può anche configura i criteri di rete di Kubernetes per limitare la connettività delle porte con un criterio eccezioni. Ad esempio, limita la connettività di queste porte in modo che sia all'interno di un nello spazio dei nomi.

Accesso sicuro al piano di controllo

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

Oltre al meccanismo di autenticazione, per Cloud Service Mesh nel cluster, Kubernetes è possibile eseguire il deployment dei criteri di rete per isolare lo spazio dei nomi di sistema di Cloud Service Mesh (per impostazione predefinita, istio-system) da spazi dei nomi non gestiti e client al di fuori del per consentire ai piani dati di accedere al piano di controllo. Regole firewall VPC può impedire al traffico esterno a un cluster di raggiungere Istiod. Con come misure di isolamento della rete, un utente malintenzionato dall'esterno del mesh non è in grado di accedere al piano di controllo, anche se l’aggressore dispone di credenziali valide. Per piani di controllo gestiti, Google gestisce la sicurezza dei piani di controllo e dell'isolamento della rete e i criteri per i piani di controllo.

Forza l'applicazione dei limiti dello spazio dei nomi

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

  • Imporre i controlli dell'accesso.
  • Applicare i criteri di rete di Kubernetes. Se i servizi in uno spazio dei nomi non hanno traffico al di fuori dello spazio dei nomi, amministratore mesh deve eseguire il deployment di un criterio di rete Kubernetes consente 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 delle applicazioni devono essere associati a uno spazio dei nomi.
    • Consenti solo agli amministratori mesh di avere ClusterRole.

Applica i criteri RBAC di Kubernetes

Gli amministratori della rete mesh devono applicare Criteri RBAC di Kubernetes e controllare chi è autorizzato ad accedere e aggiornare le risorse Kubernetes. Kubernetes controllo dell'accesso può ridurre i rischi per la sicurezza nel mesh. Ad esempio: a utenti non autorizzati non devono essere autorizzati a modificare i deployment Kubernetes bypassare le applicazioni dei criteri di Cloud Service Mesh. I ruoli di un utente devono essere è associato a uno spazio dei nomi in modo che l'utente non possa accedere ad altri spazi dei nomi. di quello a cui devono accedere. Per guide dettagliate ed esempi di configurazione di RBAC, consulta le Configurare il controllo degli accessi basato su ruoli Dopo aver abilitato Workload Identity, puoi anche consentire a un account di servizio Kubernetes di agire come account di servizio IAM.

Sicurezza perimetrale mesh

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

Controllo dell'accesso in entrata al cluster

Cloud Service Mesh riceve traffico esterno in entrata attraverso il gateway in entrata. I servizi esposti dal gateway in entrata potrebbero essere soggetti ad attacchi provenienti dall'esterno fonti. Gli amministratori della sicurezza devono sempre assicurarsi che i servizi esposti al traffico esterno tramite gateway in entrata siano sufficientemente sicuri da difendere contro gli attacchi.

L'accesso in entrata deve applicare l'autenticazione e l'autorizzazione per i servizi esposti a chiamanti esterni.

  • Applica i criteri di sicurezza in entrata del cluster. Quando il cluster deve ricevere traffico esterno, l'amministratore della rete mesh deve applicare la sicurezza in entrata tra cui Cloud Service Mesh TLS del gateway, i criteri di autenticazione e autorizzazione, per autenticare e verificare che le richieste esterne siano autorizzate ad accedere ai servizi esposto dal gateway in entrata. L'applicazione dei criteri di sicurezza in entrata difende contro gli attacchi provenienti dall'esterno del mesh che tentano di accedere a un servizio senza credenziali o autorizzazioni valide.
  • Utilizza Cloud Armor come servizio Application Firewall (WAF) per la difesa dagli attacchi basati sul web (ad esempio attacchi injection ed attacchi di esecuzione remota). Per ulteriori informazioni, vedi Da perimetrale al mesh: esposizione delle applicazioni mesh di servizi tramite GKE Ingress.

Regola il traffico in uscita del cluster

La sicurezza in uscita dal cluster è fondamentale per la sicurezza del mesh poiché la sicurezza del traffico in uscita in grado di difendersi da attacchi di esfiltrazione di dati, per il traffico in uscita e applicare l'originazione TLS per il traffico in uscita. Sicurezza gli amministratori devono regolare e controllare il traffico in uscita del cluster.

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

Criteri in uscita possono mitigare i seguenti attacchi:

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

I criteri di autorizzazione applicati ai gateway in uscita possono garantire che solo ai servizi autorizzati è consentito inviare traffico a determinati host al di fuori di la rete mesh. Nel frattempo, per il traffico che esce dal mesh, anziché gestire TLS l'origine in singoli sidecar, il TLS può provenire dai gateway in uscita. Questo fornisce un modo uniforme e più sicuro di origine del traffico TLS, in quanto i certificati client per mTLS possono essere isolati dagli spazi dei nomi in cui durante l'esecuzione delle applicazioni.

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

Oltre ad applicare criteri di sicurezza in entrata e in uscita, utilizzando un cluster privato Controlli di servizio VPC ovunque possibile. Mentre i criteri di sicurezza sono controllati dalla sicurezza mesh amministratori, la configurazione del cluster privato o i Controlli di servizio VPC 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:

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

I Controlli di servizio VPC aiutano a difenderti dagli attacchi di esfiltrazione di dati e a prevenire utenti malintenzionati esterni non riescono ad accedere ai servizi all'interno di un mesh.

Difenditi 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 difenderti dagli attacchi DDoS attacchi informatici. Cloud Armor protegge non solo dagli attacchi DDoS non solo a livello di rete (L3 e L4) ma anche attacchi DDoS a livello di applicazione (L7).

Sicurezza per l'amministrazione e l'automazione della rete mesh

È importante considerare la sicurezza per le operazioni amministrative e basata sull'automazione che crei attorno al tuo mesh, ad esempio CI/CD. Le seguenti mirano a garantire che il mesh possa essere utilizzato in sicurezza senza il rischio esponendo i 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 al loro ruolo. Ogni ruolo deve essere concesso l'insieme minimo di privilegi necessari per il ruolo.

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

Esistono diverse categorie di operatori. Ad esempio, gli operatori cluster con gli operatori dello spazio dei nomi. È importante impedire l'escalation dei privilegi che potrebbe comportare accesso illecito a risorse non autorizzate.

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

Convalida automaticamente le configurazioni dei criteri

Gli operatori potrebbero accidentalmente configurare erroneamente i criteri di Cloud Service Mesh, in gravi incidenti di sicurezza. Per prevenire errori di configurazione e convalidare i criteri di Cloud Service Mesh, gli amministratori mesh possono utilizzare Policy Controller a applicare vincoli sulle configurazioni dei criteri.

Per evitare di riporre troppa fiducia nelle persone che dispongono delle autorizzazioni di aggiornamento Criteri di sicurezza di Cloud Service Mesh e automatizzare la convalida di Cloud Service Mesh gli amministratori della rete mesh devono implementare vincoli su Cloud Service Mesh che utilizzano Policy Controller.

Policy Controller si basa sull'open source Gatekeeper e può essere eseguito come controller di ammissione Kubernetes per negare risorse non valide non vengano applicate o in modalità di controllo, per avvisare gli amministratori che violazioni delle norme. Policy Controller può convalidare automaticamente il deployment risorse nel mesh, come la convalida del fatto che le annotazioni su un deployment non bypassare i criteri di Cloud Service Mesh, verificando che i criteri di Cloud Service Mesh siano come previsto e verificare che un deployment non includa funzionalità root (ad es. NET_ADMIN e NET_RAW).

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

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

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

  • Applica il livello mesh mTLS rigido PeerAuthentication.
  • L'applicazione forzata di tutte le PeerAuthentications non può sovrascrivere il protocollo mTLS restrittivo.
  • Applica il livello mesh nega per impostazione predefinita AuthorizationPolicy.
  • Applica il criterio AuthorizationPolicy pattern di sicurezza.
  • Applica in modo forzato i file collaterali di Cloud Service Mesh che vengono sempre inseriti nei carichi di lavoro.

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

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

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

Applica l'audit logging e il monitoraggio

Gli amministratori della rete mesh devono monitorare quanto segue:

Queste risorse di osservabilità possono essere utilizzate per verificare che il livello funzioni come previsto e di monitorare eventuali eccezioni alla sicurezza dell'applicazione delle norme. Ad esempio, accesso che non è passato per file collaterali, che non disponeva di credenziali valide, ma ha raggiunto un servizio.

Mentre il software di osservabilità open source (ad esempio, Prometheus) può con Cloud Service Mesh, consigliamo vivamente di utilizzare Google Cloud Observability (in precedenza Stackdriver). La soluzione di osservabilità integrata per Google Cloud fornisce logging, raccolta, monitoraggio e avvisi delle metriche, che è completamente gestito e per gli utilizzi odierni.

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

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

Se utilizzi l'autorità di certificazione (CA) Istio non gestita, che è ospitata Nell'ambito di Istiod, la chiave di firma CA è archiviata in un secret Kubernetes accessibile agli operatori che hanno accesso alla risorsa secret nel istio-system. Questo è un rischio, perché un operatore potrebbe riuscire a usare la chiave CA indipendentemente dalla CA di Istiod e potenzialmente firmare il carico di lavoro certificati in modo indipendente. Esiste inoltre il rischio che una firma CA autogestita la chiave potrebbe 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 a utilizza l'autorità di certificazione Cloud Service Mesh Certificate Authority Service (CA Service), che sono protetti e gestiti da Google. Confrontato con l'autorità di certificazione Cloud Service Mesh, CA Service supporta per cliente, le chiavi di firma tramite Cloud KMS supportate da Cloud HSM. Servizio CA supporta anche carichi di lavoro regolamentati, al contrario dell'autorità di certificazione di Cloud Service Mesh.

Sicurezza dei carichi di lavoro

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

Limita privilegi pod

Un pod Kubernetes può avere privilegi che incidono su altri pod sul nodo in un cluster Kubernetes. È importante applicare restrizioni di sicurezza sui pod dei carichi di lavoro impedire che un pod compromesso avvii 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 dovrebbero essere eseguiti con il minor numero di privilegi possibile possibile.
  • I pod Kubernetes in esecuzione in modalità con privilegi possono manipolare gli stack di rete con altre funzionalità 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 in modo da utilizzare un container di inizializzazione per la configurazione reindirizzamento del traffico di iptables al file collaterale. Ciò richiede che l'utente di disporre dei privilegi necessari per il deployment di container NET_ADMIN e NET_RAW. Per evitare il rischio di eseguire container con privilegi elevati, gli amministratori della rete mesh possono invece enable il plug-in Istio CNI per configurare il reindirizzamento del traffico a file collaterali.

Immagini container sicure

Gli aggressori possono lanciare attacchi sfruttando immagini container vulnerabili. Gli amministratori devono applicare Autorizzazione binaria da verificare l'integrità delle immagini container e garantire che vengano eseguite solo immagini container attendibili di cui è stato eseguito il deployment nella mesh.

Mitigare contro le vulnerabilità del mesh

  • Container Analysis. Analisi dei container possono analizzare e individuare le vulnerabilità sui carichi di lavoro GKE.
  • Gestione delle vulnerabilità ed esposizioni comuni (CVE). Dopo una vulnerabilità viene rilevato in un'immagine container, gli amministratori della rete mesh devono la vulnerabilità il prima possibile. Per Cloud Service Mesh gestito con piano dati gestito, Google gestisce automaticamente le CVE con patch che influiscono sulle immagini mesh.

Utilizzare Workload Identity per accedere in modo sicuro ai servizi Google

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

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

Un mesh di servizi può presentare eccezioni di sicurezza e potenziali falle. È fondamentale per individuare e monitorare lo stato di sicurezza di una rete mesh, i criteri di sicurezza applicati, le eccezioni di sicurezza e i potenziali le falle nella rete. Dashboard per la sicurezza di GKE Enterprise per individuare e monitorare lo stato di sicurezza della rete mesh.

Telemetria monitora l'integrità e le prestazioni dei servizi in una rete mesh, consentendo agli amministratori di osservare i comportamenti dei servizi (come SLO, traffico, interruzione del servizio, 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, inclusi i criteri di controllo dell'accesso. (Criteri di rete di Kubernetes, criteri di Autorizzazione binaria e accesso al servizio criteri di controllo) e criteri di autenticazione (mTLS).

Sicurezza per credenziali e dati utente sensibili

Credenziali o dati utente sensibili possono essere vulnerabili ad attacchi provenienti da I pod o le operazioni dannose, se sono archiviati in un cluster di archiviazione, ad esempio usando secret di Kubernetes o direttamente nei pod. Sono inoltre disponibili vulnerabili agli attacchi di rete se vengono trasferiti sulla rete per di autenticazione ai servizi.

  • Se possibile, archivia le credenziali e i dati utente sensibili in uno spazio di archiviazione protetto, ad esempio Secret Manager e Cloud KMS.
  • Designare spazi dei nomi separati per i pod Kubernetes che accedono a dati sensibili e definire criteri Kubernetes per renderli inaccessibili da altri spazi dei nomi. Segmenta i ruoli e utilizzato per le operazioni applicare i limiti dello spazio dei nomi.
  • Applicare lo scambio di token per prevenire l’esfiltrazione di token con privilegi elevati di lunga durata.

Passaggi successivi