Impatto del modello di controllo degli accessi in base al ruolo di Kubernetes sugli utenti e sugli account del servizio che gestiscono SQL Server 2019 cluster Big Data

  • Articolo

Importante

Il componente aggiuntivo per i cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e fino a quel momento il software continuerà a ricevere aggiornamenti cumulativi di SQL Server. Per altre informazioni, vedere il post di blog relativo all'annuncio e Opzioni per i Big Data nella piattaforma Microsoft SQL Server.

Questo articolo descrive i requisiti di autorizzazione per gli utenti che gestiscono i cluster Big Data e la semantica per l'account del servizio predefinito e l'accesso a Kubernetes dall'interno del cluster Big Data.

Nota

Per altre risorse sul modello di controllo degli accessi in base al ruolo di Kubernetes, vedere Using RBAC Authorization - Kubernetes (Uso dell'autorizzazione di controllo degli accessi in base al ruolo - Kubernetes) e Using RBAC to define and apply permissions - OpenShift (Uso del controllo degli accessi in base al ruolo per definire e applicare le autorizzazioni - OpenShift).

Ruolo necessario per la distribuzione

SQL Server 2019 cluster Big Data usa gli account del servizio (ad esempio sa-mssql-controller o master) per orchestrare il provisioning dei pod, dei servizi, della disponibilità elevata, del monitoraggio del cluster e così via. Quando viene avviata la distribuzione del cluster BDC (ad esempio, azdata bdc create), CLI dati di Azure (azdata) esegue le operazioni seguenti:

  1. Verifica se lo spazio dei nomi specificato esiste.
  2. Se non esiste, ne crea uno e applica l'etichetta MSSQL_CLUSTER.
  3. Crea l'account del servizio sa-mssql-controller.
  4. Crea un ruolo <namespaced>-admin con autorizzazioni complete per lo spazio dei nomi o il progetto ma non con autorizzazioni a livello di cluster.
  5. Crea un'assegnazione di tale account del servizio al ruolo.

Una volta completati questi passaggi, viene effettuato il provisioning dei pod del piano di controllo e l'account del servizio distribuisce la parte restante del cluster Big Data. 

Di conseguenza, l'utente che esegue la distribuzione deve avere le autorizzazioni per:

  • Elencare gli spazi dei nomi nel cluster (1).
  • Applicare una patch allo spazio dei nomi nuovo o esistente con l'etichetta (2).
  • Creare l'account del servizio sa-mssql-controller, il ruolo <namespaced>-admin e l'associazione di ruolo (3-5).

Il ruolo admin predefinito non dispone di queste autorizzazioni, pertanto l'utente che distribuisce il cluster Big Data deve disporre almeno delle autorizzazioni di amministratore a livello di spazio dei nomi.

Ruolo del cluster necessario per la raccolta di metriche di pod e nodi

A partire da SQL Server 2019 CU5, Telegraf richiede un account del servizio con autorizzazioni di ruolo a livello di cluster per raccogliere le metriche relative a pod e nodi. Durante la distribuzione (o l'aggiornamento delle distribuzioni esistenti), viene effettuato un tentativo di creare l'account del servizio e il ruolo del cluster necessari. Se tuttavia l'utente che distribuisce il cluster o esegue l'aggiornamento non dispone di autorizzazioni sufficienti, la distribuzione (o l'aggiornamento) verrà comunque completata con un avviso. In questo caso, le metriche di pod e nodi non verranno raccolte. L'utente che distribuisce il cluster deve rivolgersi a un amministratore del cluster per creare il ruolo e l'account del servizio (prima o dopo la distribuzione o l'aggiornamento). Una volta creati, vengono usati dal cluster BDC.

Di seguito sono descritti i passaggi per creare gli artefatti necessari:

  1. Creare un file metrics-role.yaml con il contenuto seguente. Assicurarsi di sostituire i segnaposto <clusterName> con il nome del cluster Big Data.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <clusterName>:cr-mssql-metricsdc-reader
rules:
- apiGroups:
  - '*'
  resources:
  - pods
  - nodes/stats
  - nodes/proxy
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <clusterName>:crb-mssql-metricsdc-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: <clusterName>:cr-mssql-metricsdc-reader
subjects:
- kind: ServiceAccount
  name: sa-mssql-metricsdc-reader
  namespace: <clusterName>

  2. Creare il ruolo del cluster e l'associazione del ruolo del cluster:

    kubectl create -f metrics-role.yaml

L'account del servizio, il ruolo del cluster e l'associazione del ruolo del cluster possono essere creati prima o dopo la distribuzione del cluster BDC. Kubernetes aggiorna automaticamente l'autorizzazione per l'account del servizio Telegraf. Se questi artefatti vengono creati come una distribuzione di pod, verrà visualizzato un ritardo di pochi minuti nelle metriche di pod e nodi raccolte.

Nota

SQL Server 2019 CU5 ha introdotto due opzioni di funzionalità per controllare la raccolta di metriche di pod e nodi. Per impostazione predefinita, questi parametri sono impostati su true in tutte le destinazioni dell'ambiente, ad eccezione di OpenShift, in cui viene eseguito l'override del valore predefinito.

È possibile personalizzare queste impostazioni nella sezione relativa alla sicurezza del file di configurazione della distribuzione control.json:

  "security": {
    ...
    "allowNodeMetricsCollection": false,
    "allowPodMetricsCollection": false
  }

Se queste impostazioni sono impostate su false, il flusso di lavoro di distribuzione del cluster BDC non tenterà di creare l'account del servizio, il ruolo del cluster e l'associazione per Telegraf.

Uso dell'account del servizio predefinito dall'interno di un pod del cluster Big Data

Per un modello di sicurezza più rigoroso, SQL Server 2019 CU5 ha disabilitato il montaggio tramite le credenziali predefinite per l'account del servizio Kubernetes predefinito nei pod BDC. Questo vale per le distribuzioni nuove e aggiornate in CU5 o versioni successive. Il token delle credenziali all'interno dei pod può essere usato per accedere al server API Kubernetes e il livello di autorizzazioni dipende dalle impostazioni dei criteri di autorizzazione Kubernetes. Se sono presenti casi d'uso specifici che richiedono il ripristino del comportamento precedente di CU5, in CU6 verrà introdotta una nuova opzione della funzionalità in modo che sia possibile attivare il montaggio automatico solo in fase di distribuzione. L'operazione può essere eseguita usando il file di distribuzione della configurazione control.json e impostando automountServiceAccountToken su true. Eseguire questo comando per aggiornare questa impostazione nel file di configurazione personalizzato control.json usando l'interfaccia della riga di comando di Azure (azdata):

azdata bdc config replace -c custom-bdc/control.json -j "$.security.automountServiceAccountToken=true"

Contenuto correlato