Best practice per la sicurezza di Cloud Service Mesh

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

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

Il documento è organizzato come segue:

Introduzione

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

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

  • Attacchi di esfiltrazione di dati. come nel caso di attacchi che intercettano dati sensibili o credenziali provenienti 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 le comunicazioni tra i servizi.
  • Attacchi con escalation dei privilegi. Ad esempio, gli attacchi che usano 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 degli attacchi:

  • Attacchi di rete interna mesh. Attacchi finalizzati a manomettere, intercettare o eseguire lo spoofing delle comunicazioni interne del mesh tra servizi e piano di controllo.
  • Attacchi al piano di controllo. Attacchi volti a provocare il malfunzionamento del piano di controllo (come un attacco DoS) o l'esfiltrazione di dati sensibili dal piano di controllo.
  • Attacchi a spillo della rete mesh. Attacchi finalizzati a manomettere, intercettare o eseguire lo spoofing delle comunicazioni in entrata o in uscita dalla rete mesh.
  • Attacchi alle operazioni del mesh. Attacchi mirati alle operazioni del mesh. Gli aggressori potrebbero tentare di 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 della sicurezza incompleta. Un mesh di servizi non è stato configurato con criteri di autenticazione e autorizzazione per proteggerne la sicurezza. Ad esempio, per i servizi in un mesh non vengono definiti criteri di autenticazione o autorizzazione.
  • Eccezioni alle norme di sicurezza. Per soddisfare i propri casi d'uso specifici, gli utenti possono creare eccezioni ai criteri di sicurezza per un determinato traffico (interno o esterno) da escludere dai criteri di sicurezza di Cloud Service Mesh. Per gestire in modo sicuro questi casi, consulta la sezione Gestire in sicurezza le eccezioni alle norme.
  • Trascurato gli upgrade delle immagini. È possibile scoprire le vulnerabilità delle immagini utilizzate in un mesh. Il componente mesh e le immagini del carico di lavoro devono essere sempre aggiornati con le correzioni di vulnerabilità più recenti.
  • Mancanza di manutenzione (nessuna competenza o risorsa). Le configurazioni del software e dei criteri mesh richiedono una manutenzione regolare per poter usufruire dei più recenti meccanismi di protezione di sicurezza.
  • Mancanza di visibilità. Le configurazioni errate o non sicure dei criteri del mesh e il traffico/operazioni mesh anomali non vengono portati all'attenzione degli amministratori del 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 su diversi livelli del sistema mesh e delle sue applicazioni. L'intenzione generale della postura di sicurezza Cloud Service Mesh proposta è quella di proteggere una mesh di servizi attraverso l'integrazione di più meccanismi di sicurezza a diversi livelli, che conseguono la sicurezza complessiva del sistema nel 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 garantisce il controllo dell'accesso per il traffico esterno e protegge l'accesso esterno alle API esposte dai servizi nel mesh.
    • La sicurezza in uscita di Cloud Service Mesh regola il traffico in uscita dai carichi di lavoro interni.
    • L'autenticazione utente di Cloud Service Mesh 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 del gateway di Cloud Service Mesh protegge e ruota le chiavi private e i certificati X.509 utilizzati dai gateway in entrata e in uscita di Cloud Service Mesh utilizzando Certificate Authority Service.
    • Cloud Armor è in grado di difendere dagli attacchi DDoS (Distributed Denial-of-Service) esterni e dagli attacchi di livello 7. Funge da web application firewall (WAF) per proteggere il mesh dagli attacchi di rete. come ad esempio attacchi con iniezione ed esecuzione di codice in remoto.
    • I controlli di servizio VPC e VPC proteggono il perimetro del mesh tramite i controlli dell'accesso alla rete privata.
  • Sicurezza del cluster
    • Il protocollo TLS comune (mTLS) di Cloud Service Mesh applica la crittografia e l'autenticazione del traffico dai carichi di lavoro ai carichi di lavoro.
    • Le CA gestite, come l'autorità di certificazione Cloud Service Mesh e Certificate Authority Service, eseguono il provisioning e la gestione sicuri dei certificati utilizzati dai carichi di lavoro.
    • L'autorizzazione di Cloud Service Mesh applica il controllo dell'accesso ai servizi mesh in base alle loro identità e ad altri attributi.
    • La dashboard di 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 Kubernetes applica controllo dell'accesso ai pod in base a indirizzi IP, etichette dei pod, spazi dei nomi e altro ancora.
    • La sicurezza del piano di controllo protegge dagli attacchi al piano. Questa protezione impedisce agli utenti malintenzionati di modificare, sfruttare o perdere i dati di configurazione mesh e dei servizi.
  • 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 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 le credenziali o i dati sensibili tramite 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 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 Cloud Service Mesh con privilegi.
  • Sicurezza dell'operatore
    • Controllo dell'accesso basato su ruoli (RBAC) di Kubernetes limita l'accesso alle risorse Kubernetes e le autorizzazioni degli operatori per mitigare gli attacchi provenienti da operatori dannosi o il furto d'identità degli operatori.
    • GKE Enterprise Policy Controller convalida e controlla le configurazioni dei criteri nel mesh per prevenire le 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 Cloud Service Mesh.

diagramma di sicurezza flusso di traffico

Sicurezza del cluster

Attiva TLS reciproco rigoroso

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

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

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

Attiva i controlli dell'accesso

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

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

I criteri di autorizzazione di Cloud Service Mesh forniscono un modo flessibile per configurare i controlli dell'accesso per proteggere i servizi dagli accessi non autorizzati. I criteri di autorizzazione di Cloud Service Mesh devono essere applicati in base alle identità autenticate derivate 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 Cloud Service Mesh.

Applica i criteri di autenticazione di Cloud Service Mesh

JWT (JSON Web Token)

Oltre all'autenticazione mTLS, gli amministratori mesh possono richiedere un servizio per autenticare e autorizzare le richieste basate su JWT. Cloud Service Mesh non funge da provider JWT, ma autentica i JWT in base agli endpoint del set di chiavi web JSON (JWKS) configurato. 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 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 degli utenti Cloud Service Mesh

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

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 controllo dell'accesso'accesso in base alle identità effettive con cui vengono eseguiti i servizi, alle proprietà del traffico (ad esempio le intestazioni delle richieste) del livello di applicazione (ad esempio le intestazioni delle richieste) e alle proprietà del livello di rete (livello 3 e 4) come intervalli IP e porte.

I criteri di autorizzazione di Cloud Service Mesh devono essere applicati in base alle identità autenticate derivate dai risultati dell'autenticazione per difenderti da 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 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 a singoli percorsi di 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 indirizzi IP e porte sui pod Kubernetes e negli spazi dei nomi Kubernetes.

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

Per difenderti 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 bordo del mesh.

Una richiesta dall'esterno del mesh di 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 del token, un token esterno al mesh deve essere scambiato con un token interno del mesh di breve durata con un ambito limitato in ingresso del mesh. Il servizio mesh autentica un token interno mesh e autorizza la richiesta di accesso in base al token interno mesh.

Cloud Service Mesh supporta l'integrazione con Identity-Aware Proxy (IAP), che genera un RequestContextToken (un token interno al mesh di breve durata scambiato da un token esterno) utilizzato in Cloud Service Mesh per l'autorizzazione. Con lo scambio di token, i 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 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 esporre una determinata porta di rete al traffico di testo normale. Per soddisfare scenari di utilizzo specifici, a volte può essere necessario creare eccezioni per consentire l'esclusione di determinati tipi di traffico interno o esterno dai criteri di sicurezza di Cloud Service Mesh, creando problemi di sicurezza.

Potrebbero esserci ragioni legittime per bypassare i criteri di sicurezza di Cloud Service Mesh per alcune porte e intervalli IP. Puoi aggiungere annotazioni (ad esempio excludeInboundPorts, excludeOutboundPorts, excludeOutboundIPRanges) ai pod per impedire la gestione del traffico da parte del file collaterale di Envoy. Oltre alle annotazioni per escludere il traffico, puoi bypassare del tutto il mesh eseguendo il deployment di un'applicazione con l'inserimento di sidecar disabilitato. Ad esempio, aggiungendo l'etichetta sidecar.istio.io/inject="false" al pod dell'applicazione.

L'elusione dei criteri di sicurezza di Cloud Service Mesh ha un impatto negativo sulla sicurezza complessiva del sistema. Ad esempio, se il protocollo mTLS e i criteri di autorizzazione di Cloud Service Mesh vengono aggirati per una porta di rete mediante annotazioni, non ci sarà alcun controllo dell'accesso per il traffico sulla porta e potrebbero essere possibili intercettazioni o modifiche del traffico. Inoltre, l'esclusione dei criteri di Cloud Service Mesh influisce anche su criteri non di sicurezza, come i criteri di rete.

Se il criterio di sicurezza di Cloud Service Mesh viene ignorato per una porta o un IP (intenzionalmente o meno), dovrebbero essere in atto altre misure di sicurezza per proteggere il mesh e monitorare le eccezioni di sicurezza, potenziali scappatoie di sicurezza e lo stato generale dell'applicazione della sicurezza. Per proteggere il tuo mesh in questi scenari, puoi:

  • Assicurati che il traffico che aggira 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 al traffico solo di passare attraverso le porte con il criterio di sicurezza Cloud Service Mesh applicato.
  • Applica GKE Enterprise Policy Controller per convalidare automaticamente i criteri di Cloud Service Mesh. Ad esempio, puoi imporre che i file collaterali di Cloud Service Mesh vengano sempre inseriti nei carichi di lavoro.

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 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 file collaterale del servizio.

Per formare una security posture solida per un mesh di servizi, è necessario imporre il funzionamento congiunto dei meccanismi di sicurezza della piattaforma sottostante in modo congiunto con i criteri di sicurezza di Cloud 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 negli spazi dei nomi di Kubernetes. I criteri di rete Kubernetes possono essere applicati congiuntamente ai criteri Cloud Service Mesh per migliorare la sicurezza del mesh.

Ad esempio, l'amministratore del mesh può configurare i criteri di rete di Kubernetes in modo da consentire solo al traffico di utilizzare le porte con il criterio di sicurezza Cloud Service Mesh applicato. Se tutto il traffico deve essere applicato in modo forzato con mTLS di Cloud Service Mesh, l'amministratore può configurare un criterio di rete Kubernetes per consentire il traffico solo sulle porte configurate con il criterio mTLS di Cloud Service Mesh. L'amministratore del mesh può anche configurare i criteri di rete di 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 Cloud Service Mesh autentica tutti i client che si connettono. Pertanto, solo i chiamanti con credenziali valide (certificati Kubernetes JWT o X.509 emessi da CA consentite) possono accedere al piano di controllo Cloud Service Mesh. TLS cripta le connessioni tra i carichi di lavoro e il piano di controllo di Cloud Service Mesh.

Oltre al meccanismo di autenticazione, per Cloud Service Mesh nel cluster, è possibile eseguire il deployment dei criteri di rete di Kubernetes per isolare lo spazio dei nomi del sistema Cloud Service Mesh (istio-system per impostazione predefinita) dagli spazi dei nomi non gestiti e dai client al di fuori della 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, pertanto i criteri di isolamento della rete per i piani di controllo non sono necessari.

Forza l'applicazione dei limiti dello spazio dei nomi

Per impedire a un utente di un spazio dei nomi di accedere o aggiornare le risorse in uno 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, l'amministratore mesh deve eseguire il deployment di un criterio di rete Kubernetes che consente solo il traffico all'interno dello spazio dei nomi, senza 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 i criteri RBAC di Kubernetes per controllare chi è autorizzato ad accedere e aggiornare le risorse Kubernetes. Controllo dell'accesso di Kubernetes può ridurre i rischi per la sicurezza nel mesh. Ad esempio, agli utenti non autorizzati non deve essere consentito modificare i deployment Kubernetes e ignorare le applicazioni dei criteri di Cloud Service Mesh. I ruoli di un utente devono essere associati a uno spazio dei nomi in modo che l'utente non possa accedere ad altri spazi dei nomi di quelli a cui ha bisogno. Per guide dettagliate ed esempi sulla configurazione di RBAC, consulta la pagina 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 mesh

Poiché la maggior parte degli attacchi può anche provenire dall'esterno di un cluster, garantire la sicurezza sul perimetro 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 da fonti esterne. Gli amministratori della sicurezza dovrebbero sempre garantire che i servizi esposti al traffico esterno tramite i gateway in entrata siano sufficientemente sicuri da difendersi dagli attacchi.

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

  • Applica i 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 di sicurezza del gateway di Cloud Service Mesh, e i criteri di autenticazione e autorizzazione, 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 è in grado di difendere dagli attacchi provenienti dall'esterno del mesh che tentano di accedere a un servizio senza credenziali o autorizzazioni valide.
  • Utilizza Cloud Armor come web application firewall (WAF) per la difesa dagli attacchi basati sul web (ad esempio, gli attacchi di injection e gli attacchi di esecuzione remota). Per ulteriori informazioni, consulta Da perimetrale al mesh: esposizione delle applicazioni mesh di servizi tramite GKE Ingress.

Regola il traffico in uscita del cluster

La sicurezza in uscita dai cluster è fondamentale per la sicurezza del mesh poiché i criteri di sicurezza in uscita possono difendere dagli attacchi di esfiltrazione di dati, applicare filtri al traffico in uscita e applicare l'originazione TLS per il traffico in uscita. Gli amministratori della sicurezza 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 del mesh devono anche applicare i criteri di sicurezza in uscita per il cluster e configurare il traffico in uscita in modo che passi attraverso gateway in uscita.

I 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 lanciare attacchi DoS.

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

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

Oltre ad applicare i criteri di sicurezza in entrata e in uscita, blocca l'accesso esterno tramite cluster privato o Controlli di servizio VPC quando possibile. Mentre i criteri di sicurezza sono controllati dagli amministratori della sicurezza mesh, la configurazione cluster privato o i Controlli di servizio VPC possono essere applicati dagli amministratori della sicurezza dell'organizzazione.

È possibile applicare i Controlli di servizio VPC 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 difendersi dagli attacchi di esfiltrazione di dati e a impedire a utenti malintenzionati esterni di 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 delle richieste legittime. Cloud Armor può essere utilizzato per difenderti dagli attacchi DDoS. Cloud Armor protegge non solo dagli attacchi DDoS di rete (L3 e L4), ma anche dagli attacchi DDoS a livello delle applicazioni (L7).

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

È importante considerare la sicurezza per le operazioni amministrative e qualsiasi automazione creata attorno al tuo mesh, ad esempio CI/CD. Le seguenti pratiche 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 devono essere classificati in base ai loro ruoli. A ogni ruolo deve essere concesso solo l'insieme minimo di privilegi necessario.

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

Esistono diverse categorie di operatori. Ad esempio, gli operatori dei cluster e gli operatori dello spazio dei nomi. È importante impedire l'escalation dei privilegi da parte di un operatore, che potrebbe causare accessi illeciti a risorse non autorizzate.

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

Convalida automaticamente le configurazioni dei criteri

Gli operatori potrebbero configurare accidentalmente i criteri di Cloud Service Mesh in modo errato, il che può causare gravi incidenti di sicurezza. Per prevenire gli errori di configurazione e convalidare automaticamente i criteri di Cloud Service Mesh, gli amministratori del mesh possono utilizzare Policy Controller per applicare i vincoli alle configurazioni dei criteri.

Per evitare di riporre troppa fiducia nelle persone autorizzate ad aggiornare i criteri di sicurezza di Cloud Service Mesh e per automatizzare la convalida dei criteri di Cloud Service Mesh, gli amministratori del mesh devono implementare i vincoli relativi ai criteri di Cloud Service Mesh utilizzando Policy Controller.

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

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

Ecco alcuni esempi di applicazione dei criteri di sicurezza di GKE Enterprise Policy Controller:

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

  • Applica il livello mesh mTLS PeerAuthentication.
  • L'applicazione forzata di tutte le PeerAuthentications non può sovrascrivere il protocollo mTLS restrittivo.
  • Applica il criterio di autorizzazione default deny a livello di mesh.
  • Applica i pattern sicuri di AuthorizationPolicy.
  • 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 attendibilità. 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 la configurazione di sicurezza funzioni come previsto e monitorare eventuali eccezioni all'applicazione dei criteri di sicurezza. Ad esempio, un accesso che non è passato per file collaterali, ma che non ha credenziali valide ma ha raggiunto un servizio.

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

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 autorità di certificazione Cloud Service Mesh.

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 è 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 CA autogestita venga 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 per utilizzare l'autorità di certificazione Cloud Service Mesh o Certificate Authority Service (CA Service), che sono protetti e gestiti da Google. Rispetto all'autorità di certificazione Cloud Service Mesh, CA Service supporta le chiavi per cliente, la firma delle chiavi tramite Cloud KMS supportata da Cloud HSM. CA Service supporta anche carichi di lavoro regolamentati, al contrario dell'autorità di certificazione Cloud Service Mesh.

Sicurezza dei carichi di lavoro

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

Limita privilegi pod

Un pod Kubernetes può avere privilegi che influiscono su altri pod sul nodo o sul cluster. È importante applicare restrizioni di sicurezza sui pod dei carichi di lavoro per 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.
  • I pod Kubernetes in esecuzione in modalità con privilegi possono manipolare gli stack di rete e 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 configurare il reindirizzamento del traffico di iptables al sidecar. 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 del mesh possono invece enable il plug-in Istio CNI per configurare il reindirizzamento del traffico ai file collaterali.

Immagini container sicure

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

Mitigare contro le vulnerabilità del mesh

  • Container Analysis. Container Analysis può analizzare e individuare le vulnerabilità sui carichi di lavoro GKE.
  • Gestione delle vulnerabilità ed esposizioni comuni (CVE). Dopo aver rilevato una vulnerabilità in un'immagine container, gli amministratori della rete mesh devono risolvere la vulnerabilità il prima possibile. Per il Cloud Service Mesh gestito con il 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

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 di informazioni e non ripudio.

Monitora lo stato di 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, compresi i criteri di sicurezza applicati, le eccezioni di sicurezza e le potenziali lacune della sicurezza all'interno del mesh. È possibile utilizzare la dashboard di sicurezza di GKE Enterprise e i dati di telemetria per individuare e monitorare lo stato di sicurezza del mesh.

La telemetria monitora l'integrità e le prestazioni dei servizi in un mesh, consentendo agli amministratori di mesh di osservare i comportamenti dei servizi (ad esempio SLO, traffico anomalo, interruzione dei servizi 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 Kubernetes, criteri di Autorizzazione binaria e criteri di controllo dell'accesso ai servizi) e criteri di autenticazione (mTLS).

Sicurezza per credenziali e dati utente sensibili

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

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

Passaggi successivi