Best practice per la sicurezza di Cloud Service Mesh con le API Istio

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 eseguire il provisioning di Cloud Service Mesh e descrivono come utilizzare Cloud Service Mesh con altri prodotti e funzionalità per proteggersi dalle minacce alla sicurezza che le applicazioni in una mesh potrebbero affrontare. Google Cloud

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

Il documento è organizzato come segue:

Introduzione

Cloud Service Mesh fornisce funzionalità e strumenti che ti aiutano a osservare, gestire e proteggere i servizi in modo unificato. Adotta un approccio incentrato sulle applicazioni e utilizza identità di applicazioni attendibili anziché un approccio incentrato sull'IP di rete. Puoi eseguire il deployment di un mesh di servizi in modo trasparente senza dover modificare il codice dell'applicazione esistente. Cloud Service Mesh fornisce un controllo dichiarativo sul comportamento della rete, il che contribuisce a separare il lavoro dei team responsabili della distribuzione e del rilascio delle 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 della tua organizzazione, uno o più team o ruoli potrebbero essere responsabili dell'installazione e della configurazione di una mesh. Le impostazioni predefinite di Cloud Service Mesh sono scelte per proteggere le applicazioni, ma in alcuni casi potresti aver bisogno di configurazioni personalizzate o potresti dover concedere eccezioni escludendo determinate app, porte o indirizzi IP dalla partecipazione a un mesh. È importante disporre di controlli per gestire le configurazioni del mesh e le eccezioni di sicurezza.

Questo documento integra la documentazione sulle best practice di sicurezza di Istio, che include consigli dettagliati sulla configurazione per TLS reciproco (mTLS), norme di autorizzazione, gateway e altre configurazioni di sicurezza. Considera questi consigli come base da utilizzare insieme alle best practice descritte in questo documento. Questo documento descrive best practice aggiuntive per Cloud Service Mesh e in che modo le tecnologie in Google Cloud possono proteggere tutti i livelli, i componenti e i flussi di informazioni in una mesh.

Vettori di attacco e rischi per la sicurezza

Vettori d'attacco

La sicurezza di Cloud Service Mesh segue il modello di sicurezza Zero Trust, che presuppone che le minacce alla sicurezza provengano sia dall'interno che dall'esterno del perimetro di sicurezza di un'organizzazione. Di seguito sono riportati alcuni esempi di tipi di attacchi alla sicurezza che potrebbero minacciare le applicazioni in unmesh di servizih:

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

Gli attacchi possono anche essere classificati in base ai target:

  • Attacchi alla rete interna mesh. Attacchi volti a manomettere, intercettare o falsificare la comunicazione interna da servizio a servizio o da servizio a control plane del mesh.
  • Attacchi al control plane. Attacchi volti a causare il malfunzionamento del piano di controllo (ad esempio un attacco DoS) o a estrarre dati sensibili dal piano di controllo.
  • Attacchi perimetrali della mesh. Attacchi volti a manomettere, intercettare o falsificare la comunicazione in entrata o in uscita dalla rete mesh.
  • Attacchi di operazioni mesh. Attacchi mirati alle operazioni mesh. Gli autori degli attacchi potrebbero tentare di ottenere privilegi elevati per condurre operazioni dannose in una mesh, come la modifica delle relative norme di sicurezza e delle immagini dei workload.

Rischi per la sicurezza

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

  • Protezione di sicurezza incompleta. Una mesh di servizi non è stata configurata con criteri di autenticazione e autorizzazione per proteggere la sua sicurezza. Ad esempio, non sono definiti criteri di autenticazione o autorizzazione per i servizi in un mesh.
  • Eccezioni ai criteri di sicurezza. Per soddisfare i loro casi d'uso specifici, gli utenti potrebbero creare eccezioni ai criteri di sicurezza per determinati tipi di traffico (interno o esterno) da escludere dai criteri di sicurezza di Cloud Service Mesh. Per gestire in modo sicuro questi casi, consulta Gestire in modo sicuro le eccezioni alle norme, in questo documento.
  • Mancato aggiornamento delle immagini. Potrebbero essere rilevate vulnerabilità per le immagini utilizzate in una mesh. Devi mantenere aggiornati i componenti mesh e le immagini dei carichi di lavoro con le correzioni delle vulnerabilità più recenti.
  • Mancanza di manutenzione (nessuna competenza o risorse). Le configurazioni del software mesh e delle policy richiedono una manutenzione regolare per sfruttare i meccanismi di protezione della sicurezza più recenti.
  • Mancanza di visibilità. Errori di configurazione o configurazioni non sicure di criteri mesh e traffico o operazioni mesh anomali non vengono portati all'attenzione degli amministratori mesh.
  • Deriva della configurazione. La configurazione dei criteri in una mesh si discosta dalla fonte di riferimento.

Misure per proteggere un mesh di servizi

Questa sezione presenta un manuale operativo per proteggere i service mesh.

Architettura di sicurezza

La sicurezza di un mesh di servizi dipende dalla sicurezza dei componenti nei diversi livelli del sistema mesh e delle relative applicazioni. L'intenzione di alto livello della postura di sicurezza di Cloud Service Mesh proposta è quella di proteggere un service mesh integrando più meccanismi di sicurezza a diversi livelli, che insieme raggiungono la sicurezza complessiva del sistema secondo il modello di sicurezza Zero Trust. Il seguente diagramma mostra la postura di sicurezza proposta per Cloud Service Mesh.

postura di sicurezza di Cloud Service Mesh

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

  • Sicurezza edge della mesh
    • La sicurezza in entrata di Cloud 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 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 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 di ingresso e uscita di Cloud Service Mesh utilizzando Certificate Authority Service.
    • VPC e Controlli di servizio VPC proteggono il perimetro del mesh tramite i controlli di accesso alla rete privata.
  • Sicurezza del cluster
    • TLS reciproca (mTLS) di Cloud Service Mesh applica la crittografia e l'autenticazione del traffico da workload a workload.
    • L'autorità di certificazione Cloud Service Mesh esegue il provisioning e la gestione in modo sicuro dei certificati utilizzati dai workload.
    • L'autorizzazione Cloud Service Mesh applica controllo dell'accesso per i servizi mesh in base alle loro identità e ad altri attributi.
    • Il dashboard della sicurezza di GKE Enterprise fornisce il monitoraggio delle configurazioni dei criteri di sicurezza e delle NetworkPolicy di Kubernetes per i workload.
    • Controllo dell'accesso ai pod applicato dai criteri di rete Kubernetes in base a indirizzi IP, etichette dei pod, spazi dei nomi e altro ancora.
  • Sicurezza dei workload
    • Tieniti al passo con le release di sicurezza di Cloud Service Mesh per assicurarti che i binari di Cloud Service Mesh in esecuzione nel tuo mesh siano privi di vulnerabilità note pubblicamente.
    • Workload Identity Federation for GKE consente ai workload di ottenere le credenziali per chiamare in modo sicuro i servizi Google.
    • Cloud Key Management Service (Cloud KMS) protegge i dati o le credenziali sensibili tramite moduli di sicurezza hardware (HSM). Ad esempio, i carichi di lavoro possono utilizzare Cloud KMS per archiviare credenziali o altri dati sensibili. CA Service, che viene utilizzato per emettere certificati per i workload mesh, supporta chiavi di firma per cliente e basate su HSM gestite da Cloud KMS.
    • L'interfaccia di rete dei container (CNI) di Kubernetes impedisce attacchi di escalation dei privilegi eliminando la necessità di un contenitore init di Cloud Service Mesh con privilegi.
  • Sicurezza dell'operatore
    • Controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes limita l'accesso alle risorse Kubernetes e confina le autorizzazioni dell'operatore per mitigare gli attacchi provenienti da operatori dannosi o dall'impersonificazione di operatori.
    • Policy Controller di GKE Enterprise convalida e controlla le configurazioni dei criteri nel mesh per evitare errori di configurazione.
    • Google Cloud Autorizzazione binaria garantisce che le immagini dei workload nel mesh siano quelle autorizzate dagli amministratori.
    • Cloud Audit Logs esegue l'audit delle operazioni della mesh.

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

flusso di traffico di sicurezza

Sicurezza del cluster

Questa sezione descrive le best practice relative alla sicurezza del cluster.

Abilita mutual TLS rigoroso

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

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

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

Abilitare i controlli dell'accesso

Ti consigliamo di applicare le norme di sicurezza di Cloud Service Mesh (ad esempio norme di autenticazione e autorizzazione) a tutto il traffico in entrata e in uscita dal mesh, a meno che non esistano validi motivi per escludere un servizio o un pod dalle norme di sicurezza di Cloud Service Mesh. In alcuni casi, gli utenti potrebbero avere motivi legittimi per ignorare i criteri di sicurezza di Cloud Service Mesh per alcune porte e intervalli di indirizzi IP, ad esempio per stabilire connessioni native con servizi non gestiti da Cloud Service Mesh. Per proteggere Cloud Service Mesh con questi casi d'uso, consulta Gestire in modo sicuro le eccezioni ai criteri di Cloud Service Mesh.

Il controllo dell'accesso ai servizi è fondamentale per impedire l'accesso non autorizzato ai servizi. L'applicazione di mTLS cripta e autentica una richiesta, ma un mesh ha comunque bisogno di criteri di autorizzazione Cloud Service Mesh per applicare controllo dell'accesso dell'accesso ai servizi, ad esempio rifiutando 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 di accesso per proteggere i tuoi servizi da accessi non autorizzati. I criteri di autorizzazione di Cloud Service Mesh devono essere applicati in base alle identità autenticate derivate dai risultati dell'autenticazione. L'autenticazione basata su mTLS o JWT (JSON Web Token) può essere utilizzata insieme nell'ambito dei criteri di autorizzazione di Cloud Service Mesh.

Applica i criteri di autenticazione di Cloud Service Mesh

Quando prendi in considerazione le norme di autenticazione di Cloud Service Mesh, considera i seguenti punti.

JSON Web Token (JWT)

Oltre all'autenticazione mTLS, gli amministratori del mesh possono richiedere a un servizio di autenticare e autorizzare le richieste in base a JWT. Cloud Service Mesh non funge da provider JWT, ma autentica i JWT in base agli endpoint JWKS (JSON Web Key Set) configurati. L'autenticazione JWT può essere applicata ai gateway Ingress 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 viene chiamato per conto del chiamante finale. L'applicazione forzata dell'autenticazione JWT protegge dagli attacchi che accedono a un servizio senza credenziali valide e per conto di un utente finale reale.

Autenticazione utente di Cloud Service Mesh

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

Applicare i criteri di autorizzazione

I criteri di autorizzazione di Cloud Service Mesh controllano:

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

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

Ti consigliamo di applicare i criteri di autorizzazione di Cloud Service Mesh in base alle identità autenticate derivate dai risultati dell'autenticazione per proteggerti dall'accesso non autorizzato a servizi o dati.

Per impostazione predefinita, nega l'accesso a un servizio a meno che non sia 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 hanno lo scopo di limitare la fiducia il più possibile. Ad esempio, l'accesso a un servizio può essere definito in base ai singoli percorsi URL esposti da un servizio, in modo che solo il servizio A possa accedere al percorso /admin del servizio B.

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

Imporre lo scambio di token per accedere ai servizi mesh

Per difenderti dagli attacchi di replay dei token, che rubano i token e li riutilizzano per accedere ai servizi mesh, assicurati che un token in una richiesta proveniente dall'esterno della mesh venga scambiato con un token interno alla mesh di breve durata sul perimetro della mesh.

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

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

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

Potresti avere casi d'uso speciali per il tuo mesh di servizi. Ad esempio, potresti dover esporre una determinata porta di rete al traffico di testo normale. Per adattarsi a scenari di utilizzo specifici, a volte potrebbe essere necessario creare eccezioni per consentire l'esclusione di determinati traffici interni o esterni dalle norme di sicurezza di Cloud Service Mesh, il che crea problemi di sicurezza.

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

L'elusione delle policy di sicurezza di Cloud Service Mesh ha un impatto negativo sulla sicurezza complessiva del sistema. Ad esempio, se le norme di autorizzazione e mTLS di Cloud Service Mesh vengono ignorate per una porta di rete tramite annotazioni, non esiste un controllo dell'accesso per il traffico sulla porta e potrebbero essere possibili intercettazioni o modifiche del traffico. Inoltre, l'elusione dei criteri di Cloud Service Mesh influisce anche sui criteri non di sicurezza, come i criteri di rete.

Quando la norma di sicurezza di Cloud Service Mesh viene ignorata per una porta o un indirizzo IP (intenzionalmente o meno), ti consigliamo vivamente di adottare altre misure di sicurezza per proteggere il mesh e monitorare le eccezioni di sicurezza, le potenziali scappatoie di sicurezza e lo stato generale dell'applicazione della sicurezza. Per proteggere la mesh in questi scenari, puoi:

  • Assicurati che il traffico che bypassa i sidecar sia criptato e autenticato in modo nativo per impedire attacchi MITM.
  • Applica i criteri di rete Kubernetes per limitare la connettività delle porte con eccezioni ai criteri, ad esempio, limita una porta con eccezioni ai criteri in modo che consenta solo il traffico da un altro servizio nello stesso spazio dei nomi oppure consenta solo il traffico attraverso le porte a cui è applicato il criterio di sicurezza di Cloud Service Mesh.

Utilizzare un approccio GitOps con Config Sync per evitare la deviazione dalla configurazione

La deriva della configurazione si verifica quando la configurazione dei criteri in una mesh si discosta dalla relativa origine attendibile. Puoi utilizzare Config Sync per prevenire la deviazione dalla configurazione.

Applica Cloud Audit Logs e il monitoraggio

Consigliamo agli amministratori della rete mesh di monitorare quanto segue:

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

Sebbene il software di osservabilità open source (ad esempio, Prometheus) possa essere utilizzato con Cloud Service Mesh, consigliamo vivamente di utilizzare Google Cloud Observability. Questa soluzione di osservabilità integrata per Google Cloud fornisce logging, raccolta di metriche, monitoraggio e avvisi completamente gestiti.

Sicurezza dei carichi di lavoro

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

Limitare i privilegi del pod

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

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

  • I servizi di cui è stato eseguito il deployment in un mesh devono essere eseguiti con il minor numero possibile di privilegi.
  • Puoi configurare Cloud Service Mesh in modo che utilizzi un init container per configurare il reindirizzamento del traffico iptables al sidecar. Ciò richiede all'utente di creare deployment dei carichi di lavoro con privilegi 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 abilitare il plug-in Istio CNI per configurare il reindirizzamento del traffico ai sidecar.

Immagini container sicure

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

Mitigare le vulnerabilità della rete mesh

  • Artifact Analysis può analizzare e rilevare le vulnerabilità nei carichi di lavoro GKE.
  • Gestione delle vulnerabilità ed esposizioni comuni (CVE). Dopo che è stata scoperta una vulnerabilità in un'immagine container, gli amministratori del mesh possono risolverla il prima possibile. Google gestisce automaticamente l'applicazione di patch alle CVE che interessano le immagini mesh.

Utilizzare la federazione delle identità per i carichi di lavoro per GKE per accedere in modo sicuro ai servizi Google

La federazione delle identità per i carichi di lavoro per GKE è il modo consigliato per i 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 è altrettanto sicura a causa dei rischi di perdita di credenziali, escalation dei privilegi, divulgazione di informazioni e non ripudio.

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

Un mesh di servizi potrebbe presentare eccezioni di sicurezza e potenziali scappatoie. È fondamentale mostrare e monitorare lo stato di sicurezza di un mesh, che include i criteri di sicurezza applicati, le eccezioni di sicurezza e le potenziali lacune di sicurezza nel mesh. Puoi utilizzare la dashboard per la sicurezza di GKE Enterprise e la telemetria per visualizzare e monitorare lo stato di sicurezza del mesh.

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

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

Sicurezza per dati e credenziali utente sensibili

Se memorizzi dati o credenziali utente sensibili nell'archiviazione permanente del cluster, ad esempio secret Kubernetes o direttamente nei pod, i dati o le credenziali possono essere vulnerabili ad attacchi provenienti da pod o operazioni dannose. I dati sono anche vulnerabili agli attacchi di rete se vengono trasferiti sulla rete per l'autenticazione ai servizi.

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