Procedure consigliate per l'autenticazione e l'autorizzazione nel servizio Azure Kubernetes (AKS)

Quando si distribuiscono e si gestiscono cluster in servizio Azure Kubernetes (AKS), si implementano modi per gestire l'accesso a risorse e servizi. Senza questi controlli:

  • Gli account potrebbero avere accesso a risorse e servizi non necessari.
  • Il rilevamento del set di credenziali usato per apportare modifiche potrebbe risultare difficile.

Questo articolo sulle procedure consigliate è incentrato su come un operatore del cluster può gestire l'accesso e l'identità per i cluster servizio Azure Kubernetes. In questo articolo vengono illustrate le operazioni seguenti:

  • Autenticare gli utenti del cluster del servizio Azure Active Directory.
  • Controllare l'accesso alle risorse con il controllo degli accessi in base al ruolo di Kubernetes.
  • Usare il controllo degli accessi in base al ruolo di Azure per controllare in modo granulare l'accesso alla risorsa servizio Azure Kubernetes, all'API Kubernetes su larga scala e a kubeconfig .
  • Usare un'identità gestita per autenticare i pod stessi con altri servizi.

Usare Azure Active Directory (Azure AD)

Indicazioni sulle procedure consigliate

Distribuire cluster del servizio AKS con Azure AD integrazione. L'uso di Azure AD consente di centralizzare il componente di gestione delle identità. Qualsiasi modifica all'account utente o allo stato del gruppo viene aggiornata automaticamente nell'accesso al cluster servizio Azure Kubernetes. Impostare l'ambito di utenti o gruppi sulla quantità minima di autorizzazioni usando Ruoli, Ruoli Cluster o Associazioni.

Gli sviluppatori del cluster Kubernetes e i proprietari delle applicazioni devono accedere a risorse diverse. Kubernetes non dispone di una soluzione di gestione delle identità per controllare le risorse con cui gli utenti possono interagire. In alternativa, in genere si integra il cluster con una soluzione di gestione delle identità esistente. Immettere Azure AD: una soluzione di gestione delle identità pronta per l'organizzazione che si integra con i cluster del servizio Web Del servizio Web Diaks.

Con Azure AD cluster integrati nel servizio AKS, si creano ruoli o ruoli cluster che definiscono le autorizzazioni di accesso alle risorse. Si associano quindi i ruoli a utenti o gruppi da Azure AD. Per altre informazioni su questi controllo degli accessi in base al ruolo di Kubernetes, vedere la sezione successiva. Azure AD'integrazione e la modalità di controllo dell'accesso alle risorse sono disponibili nel diagramma seguente:

Autenticazione a livello di cluster per l'integrazione di Azure Active Directory con servizio Azure Kubernetes

  1. Lo sviluppatore viene autenticato con Azure AD.
  2. L'endpoint di emissione del token di Azure AD emette il token di accesso.
  3. Lo sviluppatore esegue un'azione usando Azure AD token, ad esempio kubectl create pod .
  4. Kubernetes convalida il token con Azure AD e recupera le appartenenze ai gruppi dello sviluppatore.
  5. Vengono applicati il controllo degli accessi in base al ruolo di Kubernetes e i criteri del cluster.
  6. La richiesta dello sviluppatore ha esito positivo in base alla convalida precedente Azure AD appartenenza al gruppo e al controllo degli accessi in base al ruolo e ai criteri di Kubernetes.

Per creare un cluster AKS che usa Azure AD, vedere Integrare Azure Active Directory con il servizio Azure Kubernetes.

Usare il controllo degli accessi in base al ruolo di Kubernetes (controllo degli accessi in base al ruolo di Kubernetes)

Indicazioni sulle procedure consigliate

Definire le autorizzazioni utente o gruppo per le risorse del cluster con il controllo degli accessi in base al ruolo di Kubernetes. Creare ruoli e associazioni che assegnano il numero minimo di autorizzazioni richieste. L'integrazione con Azure AD per aggiornare automaticamente lo stato utente o la modifica dell'appartenenza ai gruppi e mantenere aggiornato l'accesso alle risorse del cluster.

In Kubernetes si fornisce il controllo granulare degli accessi alle risorse del cluster. Le autorizzazioni vengono definite a livello di cluster o a spazi dei nomi specifici. È possibile determinare quali risorse possono essere gestite e con quali autorizzazioni. Questi ruoli vengono quindi applicati a utenti o gruppi con un'associazione. Per altre informazioni su ruoli, ClusterRole e associazioni, vedere Opzioni di accesso e identità per il servizio Azure Kubernetes.

Ad esempio, si crea un ruolo con accesso completo alle risorse nello spazio dei nomi denominato finance-app, come illustrato nel manifesto YAML di esempio seguente:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Creare quindi un roleBinding e associare l'Azure AD utente developer1 @ contoso.com roleBinding, come illustrato nel manifesto YAML seguente:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Quando developer1 @ contoso.com viene autenticato nel cluster del servizio App Del servizio App, ha le autorizzazioni complete per le risorse nello spazio dei nomi finance-app. In questo modo, l'accesso alle risorse viene separato e controllato logicamente. Usare il controllo degli accessi in base al ruolo di Kubernetes in combinazione con Azure AD-integration.

Per informazioni su come usare i gruppi Azure AD per controllare l'accesso alle risorse Kubernetes usando il controllo degli accessi in base al ruolo di Kubernetes, vedere Controllare l'accesso alle risorse del clusterusando il controllo degli accessi in base al ruolo e le identità Azure Active Directory nel servizio Azure Kubernetes.

Usare il controllo degli accessi in base al ruolo di Azure

Indicazioni sulle procedure consigliate

Usare il controllo degli accessi in base al ruolo di Azure per definire le autorizzazioni minime necessarie per utenti e gruppi per le risorse del servizio AzureKs in una o più sottoscrizioni.

Esistono due livelli di accesso necessari per il funzionamento completo di un cluster del servizio AKS:

  1. Accedere alla risorsa servizio AzureKs nella sottoscrizione di Azure.

    Questo livello di accesso consente di:

    • Controllare il ridimensionamento o l'aggiornamento del cluster usando le API del servizio Web Disatteso
    • Eseguire il pull di kubeconfig .

    Per informazioni su come controllare l'accesso alla risorsa del servizio Web Disattesa e kubeconfig , vedere Limitare l'accesso al file di configurazione del cluster.

  2. Accesso all'API Kubernetes.

    Questo livello di accesso è controllato da:

    Per informazioni su come concedere in modo granulare le autorizzazioni all'API Kubernetes usando il controllo degli accessi in base al ruolo di Azure, vedere Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione kubernetes.

Usare identità gestite da pod

Indicazioni sulle procedure consigliate

Non usare credenziali fisse all'interno di pod o immagini del contenitore, perché sono a rischio di esposizione o abuso. Usare invece le identità dei pod per richiedere automaticamente l'accesso usando una soluzione Azure AD identity.

Nota

Le identità dei pod sono destinate all'uso solo con i pod Linux e le immagini dei contenitori. Il supporto delle identità gestite da pod per Windows contenitori sarà presto disponibile.

Per accedere ad altri servizi di Azure, ad esempio Cosmos database, Key Vault o blob Archiviazione, il pod deve avere le credenziali di accesso. È possibile definire le credenziali di accesso con l'immagine del contenitore o inserirle come segreto Kubernetes. In entrambi i modi, è necessario crearli e assegnarli manualmente. In genere, queste credenziali vengono riutilizzate tra i pod e non vengono ruotate regolarmente.

Con le identità gestite da pod per le risorse di Azure, si richiede automaticamente l'accesso ai servizi tramite Azure AD. Le identità gestite da pod sono ora disponibili in anteprima per il servizio AzureKs. Per iniziare, vedere la documentazione Azure Active Directory usare Azure Active Directory gestite da pod in servizio Azure Kubernetes (anteprima).

Anziché definire manualmente le credenziali per i pod, le identità gestite dal pod richiedono un token di accesso in tempo reale, usandolo per accedere solo ai servizi assegnati. Nel servizio AzureKs sono disponibili due componenti che gestiscono le operazioni per consentire ai pod di usare identità gestite:

  • Il server NMI (Node Management Identity) è un pod che viene eseguito come DaemonSet su ogni nodo nel cluster servizio Azure Kubernetes. Il server NMI ascolta le richieste del pod ai servizi di Azure.
  • Il provider di risorse di Azure esegue una query sul server API Kubernetes e verifica la presenza di un mapping di identità di Azure corrispondente a un pod.

Quando i pod richiedono l'accesso a un servizio di Azure, le regole di rete reindirizzano il traffico al server NMI.

  1. Server NMI:
    • Identifica i pod che richiedono l'accesso ai servizi di Azure in base al relativo indirizzo remoto.
    • Esegue una query sul provider di risorse di Azure.
  2. Il provider di risorse di Azure controlla i mapping delle identità di Azure nel cluster del servizio AzureKs.
  3. Il server NMI richiede un token di accesso Azure AD in base al mapping delle identità del pod.
  4. Azure AD fornisce l'accesso al server NMI, che viene restituito al pod.
    • Questo token di accesso può essere quindi usato dal pod per richiedere l'accesso ai servizi di Azure.

Nell'esempio seguente uno sviluppatore crea un pod che usa un'identità gestita per richiedere l'accesso database SQL di Azure:

Le identità del pod consentono a un pod di richiedere automaticamente l'accesso ad altri servizi

  1. L'operatore cluster crea un account del servizio per eseguire il mapping delle identità quando i pod richiedono l'accesso ai servizi.
  2. Il server NMI viene distribuito per inoltrare eventuali richieste di pod, insieme al provider di risorse di Azure, per i token di accesso Azure AD.
  3. Uno sviluppatore distribuisce un pod con un'identità gestita che richiede un token di accesso tramite il server NMI.
  4. Il token viene restituito al pod e usato per accedere database SQL di Azure

Nota

Le identità gestite dal pod sono attualmente in stato di anteprima.

Per usare le identità gestite da pod, vedere Usare Azure Active Directory identità gestite da pod in servizio Azure Kubernetes (anteprima).

Passaggi successivi

Questo articolo sulle procedure consigliate ha illustrato l'autenticazione e l'autorizzazione per il cluster e le risorse. Per implementare alcune di queste procedure consigliate, vedere gli articoli seguenti:

Per altre informazioni sulle operazioni cluster in servizio Azure Kubernetes, vedere le procedure consigliate seguenti: