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 design siano consigliati, non è obbligatorio seguirli esattamente come descritto. Ogni universo GDC ha requisiti e considerazioni unici che devono essere soddisfatti caso per caso.

Configura un provider di identità per organizzazione

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

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 e controllare la combinazione di privilegi di un utente in più 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 collaborano in un'unica organizzazione. Valuta se il consolidamento delle identità utente in un unico provider di identità o il mantenimento di provider di identità separati funziona meglio con l'approccio della tua azienda alla gestione delle identità.

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

GDC si basa sulla tua piattaforma IAM per l'autenticazione, incluse impostazioni di sicurezza aggiuntive come l'autenticazione a più fattori. È consigliabile 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 i servizi 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 del marketplace devono prima essere abilitati per l'organizzazione.

Per negare l'accesso al servizio dai progetti, applica vincoli 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 Kubernetes Pod 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 gcloud CLI o kubectl CLI, potresti avere più file kubeconfig per svolgere le tue attività. Assicurati di accedere utilizzando le credenziali kubeconfig per il cluster appropriato per la tua attività.

Best practice per i service account Kubernetes

Per i service account Kubernetes, l'autorizzazione si basa su un token segreto. Per mitigare il rischio di token dell'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 riassegnazione 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 tuoi workload.
  • Ruota regolarmente le credenziali del account di servizio.

Considera il principio del privilegio minimo

Tieni presente il principio del privilegio minimo (PoLP) quando concedi binding dei ruoli agli utenti. In conformità al principio del privilegio minimo, 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 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 sé o ad altri ruoli aggiuntivi nel progetto.

Esegui regolarmente audit per verificare la presenza di privilegi eccessivi

Assicurati di esaminare i ruoli concessi all'interno della tua organizzazione ed esegui un audit per verificare l'eventuale presenza di 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 nei progetti non comportino un rischio di escalation o esfiltrazione.

Se la tua azienda utilizza più organizzazioni, sconsigliamo a un singolo utente di avere ruoli con privilegi elevati in più organizzazioni, in quanto ciò potrebbe violare il motivo per cui le organizzazioni sono state separate in primo luogo.