Configurazione delle autorizzazioni di progettazione

Questo documento descrive le best practice per la progettazione delle autorizzazioni in un universo air-gapped di Google Distributed Cloud (GDC). Vengono trattati i seguenti argomenti:

Sebbene i seguenti progetti siano consigliati, non è necessario seguirli esattamente come prescritto. Ogni universo GDC ha requisiti e considerazioni unici che devono essere soddisfatti caso per caso.

Configurare un provider di identità per organizzazione

Un operatore deve configurare uno o più provider di identità per organizzazione. Un amministratore si connette quindi a un provider di identità per gestire i servizi di autenticazione per le applicazioni nell' universo GDC.

Potresti avere uno scenario in cui la tua azienda ha più reparti con organizzazioni separate e ogni organizzazione si connette allo stesso provider di identità per l'autenticazione. In questo caso, è tua responsabilità comprendere ed eseguire l'audit della combinazione di privilegi di un utente tra le organizzazioni. Assicurati che un utente con privilegi in più organizzazioni non violi i requisiti per la separazione dei carichi di lavoro in organizzazioni distinte.

In alternativa, potresti avere uno scenario in cui diversi gruppi di utenti utilizzano provider di identità diversi per l'autenticazione all'interno di una singola organizzazione, ad esempio quando più team di fornitori lavorano insieme in una singola organizzazione. Valuta se il consolidamento delle identità utente in un singolo provider di identità o il mantenimento di provider di identità separati funziona meglio con l'approccio della tua azienda alla gestione delle identità.

Configurare l'autenticazione a più fattori per il provider di identità

GDC si basa sulla piattaforma IAM per l'autenticazione, incluse le impostazioni di sicurezza aggiuntive come l'autenticazione a più fattori. È una best practice configurare l'autenticazione a più fattori con una chiave fisica per qualsiasi utente che potrebbe potenzialmente accedere a risorse sensibili.

Limitare i servizi gestiti e di marketplace

Potresti preferire bloccare alcuni progetti da determinati servizi, per limitare la potenziale superficie di attacco in un progetto o evitare l'utilizzo di servizi non approvati. Per impostazione predefinita, i servizi gestiti come l'intelligenza artificiale e il machine learning sono disponibili per l'utilizzo in qualsiasi progetto. Rispetto ai servizi gestiti, i servizi di marketplace devono essere prima abilitati per l'organizzazione.

Per negare l'accesso ai servizi dai progetti, applica i vincoli di Gatekeeper alla definizione di risorsa personalizzata di un servizio e a un elenco di spazi dei nomi. L'approccio per negare l'accesso con Gatekeeper si applica ai servizi gestiti e di marketplace.

Gestire i file kubeconfig per più cluster

Diverse attività operative richiedono una connessione a cluster diversi. Ad esempio, esegui attività come l'associazione di un ruolo IAM a un progetto e attività come il deployment di una risorsa Pod Kubernetes su un cluster Kubernetes.

Quando utilizzi la console GDC, non devi sapere quale cluster sottostante esegue un'attività, poiché la console GDC astrae le operazioni di basso livello come la connessione a un cluster.

Tuttavia, quando lavori con la CLI gdcloud o la CLI kubectl, potresti avere più file kubeconfig per completare le attività. Assicurati di accedere utilizzando le credenziali kubeconfig per il cluster appropriato per l'attività.

Best practice per i service account Kubernetes

Per i service account Kubernetes, l'autorizzazione si basa su un token secret. Per ridurre il rischio di token dei account di servizio, prendi in esame le seguenti best practice:

  • Evita di scaricare le credenziali del account di servizio persistenti per l'utilizzo al di fuori di GDC.
  • Tieni presente i percorsi di escalation di Kubernetes per gli utenti o i service account che hanno la possibilità di creare e modificare i pod.
  • Imposta il campo expirationSeconds su un breve periodo di tempo per la proiezione del token del service account dei carichi di lavoro.
  • Ruota regolarmente le credenziali del account di servizio.

Considerare il principio del privilegio minimo

Tieni conto del principio del privilegio minimo (PoLP) quando concedi le associazioni di ruoli a gli utenti. In conformità con il PoLP, valuta la possibilità di assegnare solo i privilegi necessari per completare un'attività.

Ad esempio, concedi il ruolo Amministratore IAM progetto all'interno di un singolo progetto a un utente, in modo che questo utente deleghi l'autorità per concedere i ruoli all'interno di quel progetto. Questo utente concede quindi ruoli granulari ad altri sviluppatori del progetto in base ai servizi specifici che utilizzano. Il ruolo Amministratore IAM progetto deve essere limitato a un lead attendibile perché questo ruolo potrebbe essere utilizzato per aumentare i privilegi, concedendo a se stessi o ad altri ruoli aggiuntivi nel progetto.

Eseguire regolarmente l'audit per i privilegi eccessivi

Assicurati di esaminare i ruoli concessi all'interno della tua organizzazione ed esegui l'audit per i privilegi eccessivi. Devi assicurarti che i ruoli concessi siano necessari a un singolo utente per completare il proprio lavoro e che le combinazioni di ruoli tra i progetti non comportino un rischio di escalation o esfiltrazione.

Se la tua azienda utilizza più organizzazioni, non è consigliabile che un singolo utente abbia ruoli con privilegi elevati in più organizzazioni, in quanto ciò potrebbe violare il motivo per cui le organizzazioni sono state separate in primo luogo.