Configurare Dati live in Dati analitici sui contenitori

  • Articolo

Per visualizzare i dati in tempo reale in Dati analitici sui contenitori dai cluster del servizio Azure Kubernetes, configurare l'autenticazione per concedere l'autorizzazione ad accedere ai dati di Kubernetes. Questa configurazione di sicurezza consente l'accesso in tempo reale ai dati tramite l'API Kubernetes direttamente nel portale di Azure.

Tale funzionalità supporta i metodi seguenti per controllare l'accesso a log, eventi e metriche:

  • Servizio Azure Kubernetes senza autorizzazione del controllo degli accessi in base al ruolo (RBAC) abilitata
  • Servizio Azure Kubernetes con autorizzazione del controllo degli accessi in base al ruolo di Kubernetes abilitata
  • Servizio Azure Kubernetes abilitato con l'accesso Single Sign-On basato su SAML di Microsoft Entra

Queste istruzioni richiedono l'accesso amministrativo al cluster Kubernetes. Se si sta configurando l'uso di Microsoft Entra ID per l'autenticazione utente, è necessario anche l'accesso amministrativo a Microsoft Entra ID.

Questo articolo illustra come configurare l'autenticazione per controllare l'accesso alla funzionalità Dati live dal cluster:

  • Cluster del servizio Azure Kubernetes abilitato per il controllo degli accessi in base al ruolo di Kubernetes
  • Cluster del servizio Azure Kubernetes integrato di Microsoft Entra

Modello di autenticazione

La funzione Dati live usa l'API di Kubernetes, che è identica allo strumento da riga di comando kubectl. Gli endpoint dell'API Kubernetes usano un certificato autofirmato, che il browser non sarà in grado di convalidare. Questa funzionalità usa un proxy interno per convalidare il certificato con il servizio Azure Kubernetes, garantendo in tal modo l'attendibilità del traffico.

Il portale di Azure richiede di convalidare le credenziali di accesso per un cluster Microsoft Entra ID. In questo modo si viene reindirizzati alla registrazione del client impostata durante la creazione del cluster e, successivamente, riconfigurata in questo articolo. Questo comportamento è simile al processo di autenticazione richiesto da kubectl.

Nota

L'autorizzazione per il cluster viene gestita da Kubernetes e il modello di sicurezza con cui è configurato. È necessario che gli utenti che accedono a questa funzione dispongano dell'autorizzazione a scaricare la configurazione di Kubernetes, ovvero kubeconfig, che è simile all'esecuzione di az aks get-credentials -n {your cluster name} -g {your resource group}.

Il file di configurazione contiene il token di autorizzazione e autenticazione per il ruolo utente del cluster del servizio Azure Kubernetes, nel caso in cui i cluster del controllo degli accessi in base al ruolo di Azure e del servizio Azure Kubernetes senza l'autorizzazione del controllo degli accessi in base al ruolo di Kubernetes siano abilitati. Tale file contiene informazioni su Microsoft Entra ID e dettagli della registrazione client, nel caso in cui il servizio Azure Kubernetes sia abilitato con l'accesso Single Sign-On basato su Microsoft Entra SAML.

Gli utenti di questa funzionalità necessitano del ruolo utente del cluster di Azure Kubernetes per accedervi kubeconfig, in modo da poterla scaricare e usare. Gli utenti non necessitano dell'accesso al cluster da parte di un collaboratore per usare questa funzionalità.

Usare clusterMonitoringUser con cluster abilitati per il controllo degli accessi in base al ruolo di Kubernetes

Per evitare di dover applicare altre modifiche alla configurazione per consentire all’associazione di ruolo dell’utente di Kubernetes clusterUser di accedere alla funzionalità Dati live dopo aver autorizzato l’abilitazione del controllo degli accessi in base al ruolo di Kubernetes, il servizio Azure Kubernetes ha aggiunto una nuova associazione di ruolo del cluster Kubernetes denominata clusterMonitoringUser. L’associazione di ruolo del cluster dispone di tutte le autorizzazioni necessarie per accedere all'API Kubernetes e agli endpoint per l'uso della funzionalità Dati live.

Per usare la funzionalità Dati live con questo nuovo utente, è necessario essere membri del ruolo Utente del cluster del servizio Azure Kubernetes o Collaboratore nella risorsa del cluster del servizio Azure Kubernetes. Se abilitati, per impostazione predefinita, i dati analitici sui contenitori vengono configurati per l'autenticazione tramite clusterMonitoringUser. Se in un cluster non è presente l'associazione di ruolo clusterMonitoringUser, al suo posto viene usato clusterUser per l'autenticazione. Se presente, il collaboratore fornisce l’accesso a clusterMonitoringUser, mentre l'utente del cluster del servizio Azure Kubernetes consente di accedere a clusterUser. Uno di questi due ruoli fornisce l'accesso necessario per usare questa funzionalità.

Il servizio Azure Kubernetes ha rilasciato questa nuova associazione di ruolo nel gennaio 2020; pertanto, i cluster creati prima di questa data non ne dispongono. Se si dispone di un cluster creato prima del gennaio 2020, il nuovo clusterMonitoringUser può essere aggiunto a un cluster esistente eseguendo un'operazione PUT nel cluster. In alternativa, è possibile usare qualsiasi altra operazione che esegua un'operazione PUT nel cluster, ad esempio l'aggiornamento della versione del cluster.

Cluster Kubernetes senza controllo degli accessi in base al ruolo di Kubernetes abilitato

Se si dispone di un cluster Kubernetes non configurato con l'autorizzazione del controllo degli accessi in base al ruolo di Kubernetes oppure integrato con il Single Sign-On di Azure AD, non è necessario eseguire la procedura seguente. In una configurazione senza controllo degli accessi in base al ruolo, si dispone già di autorizzazioni amministrative per impostazione predefinita.

Configurare l'autorizzazione per il controllo degli accessi in base al ruolo di Kubernetes

Quando si abilita l'autorizzazione per il controllo degli accessi in base al ruolo di Kubernetes, clusterUser e clusterAdmin vengono usati per accedere all'API Kubernetes. Questa configurazione è simile all'esecuzione az aks get-credentials -n {cluster_name} -g {rg_name} senza l'opzione amministrativa. Per questo motivo, è necessario concedere a clusterUser l'accesso agli endpoint dell'API Kubernetes.

I passaggi di esempio seguenti illustrano come configurare l'associazione di ruolo del cluster da questo modello di configurazione YAML.

  1. Copiare e incollare il file YAML e salvarlo come LogReaderRBAC.yaml.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
   name: containerHealth-log-reader
rules:
    - apiGroups: ["", "metrics.k8s.io", "extensions", "apps"]
      resources:
         - "pods/log"
         - "events"
         - "nodes"
         - "pods"
         - "deployments"
         - "replicasets"
      verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
   name: containerHealth-read-logs-global
roleRef:
   kind: ClusterRole
   name: containerHealth-log-reader
   apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: clusterUser
  apiGroup: rbac.authorization.k8s.io

  2. Per aggiornare la configurazione, eseguire il comando kubectl apply -f LogReaderRBAC.yaml.

Nota

Se è stata applicata una versione precedente del file LogReaderRBAC.yaml al cluster, aggiornarla copiando e incollando il nuovo codice illustrato nel passaggio 1. Eseguire quindi il comando illustrato nel passaggio 2 per applicarlo al cluster.

Configurare l'autenticazione integrata di Microsoft Entra

Un cluster del servizio Azure Kubernetes configurato per l'uso di Microsoft Entra ID al fine dell'autenticazione utente usa le credenziali di accesso dell’utente che accede a questa funzionalità. In questa configurazione, è possibile accedere a un cluster del servizio Azure Kubernetes tramite un token di autenticazione di Microsoft Entra.

La registrazione del client di Microsoft Entra deve essere riconfigurata per consentire al portale di Azure di reindirizzare le pagine di autorizzazione come URL di reindirizzamento attendibile. Agli utenti di Microsoft Entra ID viene quindi concesso l'accesso diretto agli stessi endpoint dell’API Kubernetes tramite ClusterRoles e ClusterRoleBindings.

Per altre informazioni sulla configurazione avanzata della sicurezza in Kubernetes, rivedere la documentazione di Kubernetes.

Nota

Se si sta creando un nuovo cluster abilitato per il controllo degli accessi in base al ruolo di Kubernetes, vedere Integrare Microsoft Entra ID con il servizio Azure Kubernetes e seguire la procedura seguente per configurare l'autenticazione di Microsoft Entra. Durante i passaggi per la creazione dell'applicazione client, in una nota contenuta in questa sezione vengono evidenziati i due URL di reindirizzamento che è necessario creare per Dati analitici sui contenitori corrispondenti a quelli specificati nel passaggio 3.

Riconfigurazione della registrazione client

  1. Individuare la registrazione client per il cluster Kubernetes di Microsoft Entra ID in Microsoft Entra ID> Registrazioni app nel portale di Azure.

  2. Nel riquadro a sinistra, selezionare Autenticazione.

  3. Aggiungere due URL di reindirizzamento a questo elenco come tipi di applicazione Web. Il primo valore dell'URL di base deve essere https://afd.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html. Il secondo valore dell'URL di base deve essere https://monitoring.hosting.portal.azure.net/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html.

    Nota

    Se si usa questa funzionalità in Microsoft Azure gestita da 21Vianet, il primo valore dell'URL di base deve essere https://afd.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html. Il secondo valore dell'URL di base deve essere https://monitoring.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html.

  4. Dopo aver registrato gli URL di reindirizzamento, in Concessione implicita, selezionare le opzioni Token di accesso e Token ID. Salvare quindi le modifiche.

È possibile configurare l'autenticazione con Microsoft Entra ID per l'accesso Single Sign-On solo durante la distribuzione iniziale di un nuovo cluster del servizio Azure Kubernetes. Non è possibile configurare l'accesso Single Sign-On per un cluster del servizio Azure Kubernetes già distribuito.

Importante

Se si è riconfigurato Microsoft Entra ID per l'autenticazione degli utenti tramite l'URI aggiornato, cancellare la cache del browser per assicurarsi che il token di autenticazione aggiornato venga scaricato e applicato.

Concedere un'autorizzazione

È necessario concedere a ogni account di Microsoft Entra l'autorizzazione per le API appropriate in Kubernetes per accedere alla funzionalità Dati live. I passaggi per la concessione dell'account di Microsoft Entra sono simili a quelli descritti nella sezione Autenticazione del controllo degli accessi in base al ruolo di Kubernetes. Prima di applicare il modello di configurazione YAML al cluster, sostituire clusterUser in ClusterRoleBinding con l'utente desiderato.

Importante

Se l'utente a cui si concede l'associazione del controllo degli accessi in base al ruolo di Kubernetes si trova nello stesso tenant di Microsoft Entra, assegnare le autorizzazioni in base a userPrincipalName. Se l'utente si trova in un tenant di Microsoft Entra diverso, eseguire una query e usare la proprietà objectId.

Per altre informazioni sulla configurazione del cluster del servizio Azure Kubernetes ClusterRoleBinding, vedere Creare l'associazione del controllo degli accessi in base al ruolo di Kubernetes.

Passaggi successivi

Ora che è stata configurata l'autenticazione, è possibile visualizzare metriche ed eventi e log in tempo reale dal cluster.