Condividi tramite

Considerazioni sulla gestione di identità e accessi per il servizio Azure Kubernetes

  • Articolo

Questo articolo fornisce considerazioni sulla progettazione e consigli per la gestione delle identità e degli accessi quando si usa servizio Azure Kubernetes (servizio Azure Kubernetes). Esistono diversi aspetti della gestione delle identità e degli accessi, tra cui identità del cluster, identità del carico di lavoro e accesso degli operatori.

Considerazioni relative alla progettazione

  • Decidere quale identità del cluster usare (identità gestita o entità servizio).
  • Decidere come autenticare l'accesso al cluster: in base ai certificati client o tramite Microsoft Entra ID.
  • Decidere se usare un cluster multi-tenancy e come configurare il controllo degli accessi in base al ruolo in Kubernetes.
    • Scegliere un metodo per l'isolamento. I metodi includono spazio dei nomi, criteri di rete (consentiti solo da Azure CNI), calcolo (pool di nodi) e cluster.
    • Determinare i ruoli controllo degli accessi in base al ruolo di Kubernetes e l'allocazione di calcolo per ogni team dell'applicazione, per l'isolamento.
    • Decidere se i team dell'applicazione possono leggere altri carichi di lavoro nei cluster o in altri cluster.
  • Determinare le autorizzazioni per i ruoli di controllo degli accessi in base al ruolo di Azure personalizzati per la zona di destinazione del servizio Azure Kubernetes.
    • Decidere quali autorizzazioni sono necessarie per il ruolo SRE (Site Reliability Engineering) per consentire a tale ruolo di amministrare e risolvere i problemi dell'intero cluster.
    • Decidere quali autorizzazioni sono necessarie per SecOps.
    • Decidere quali autorizzazioni sono necessarie per il proprietario della zona di destinazione.
    • Decidere quali autorizzazioni dovranno essere distribuite dal team dell'applicazione nel cluster.
  • Decidere se sono necessarie identità del carico di lavoro (ID dei carichi di lavoro di Microsoft Entra). Potrebbero essere necessari per servizi come l'integrazione di Azure Key Vault e Azure Cosmos DB.

Suggerimenti per la progettazione

  • Identità del cluster.
    • Usare la propria identità gestita per il cluster del servizio Azure Kubernetes.
    • Definire ruoli personalizzati di controllo degli accessi in base al ruolo di Azure per l'area di destinazione del servizio Azure Kubernetes per semplificare la gestione delle autorizzazioni necessarie per l'identità gestita dal cluster.
  • Accesso al cluster.
    • Usare il controllo degli accessi in base al ruolo di Kubernetes con Microsoft Entra ID per limitare i privilegi e ridurre al minimo i privilegi di amministratore. In questo modo è possibile proteggere l'accesso alla configurazione e ai segreti.
    • Usare l'integrazione di Microsoft Entra gestita dal servizio Azure Kubernetes in modo da poter usare Microsoft Entra ID per l'autenticazione e l'operatore e l'accesso per sviluppatori.
  • Definire i ruoli di controllo degli accessi in base al ruolo e le associazioni di ruolo necessari in Kubernetes.
    • Usare i ruoli e le associazioni di ruolo di Kubernetes ai gruppi di Microsoft Entra per l'ingegneria dell'affidabilità del sito (SRE), SecOps e l'accesso per sviluppatori.
    • Prendere in considerazione l'uso del controllo degli accessi in base al ruolo di Azure per Kubernetes, che consente la gestione unificata e il controllo di accesso tra risorse di Azure, servizio Azure Kubernetes e risorse Kubernetes. Quando il controllo degli accessi in base al ruolo di Azure per Kubernetes è abilitato, non è necessario gestire separatamente identità utente e credenziali per Kubernetes. Le entità di sicurezza di Microsoft Entra verranno convalidate esclusivamente dal controllo degli accessi in base al ruolo di Azure, ma gli utenti e gli account del servizio Kubernetes normali verranno convalidati esclusivamente dal controllo degli accessi in base al ruolo di Kubernetes.
  • Concedere a SRE l'accesso completo JUST-in-time, in base alle esigenze.
  • Usare ID dei carichi di lavoro di Microsoft Entra per Kubernetes. Quando si implementa questa federazione, gli sviluppatori possono usare gli account del servizio Kubernetes nativi e la federazione per accedere alle risorse gestite dall'ID Microsoft Entra, ad esempio Azure e Microsoft Graph.