Модель Kubernetes RBAC и влияние на пользователей и учетные записи служб, управляющих кластерами больших данных SQL Server 2019

  • Статья

Важно!

Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, и программное обеспечение будет продолжать поддерживаться с помощью накопительных обновлений SQL Server до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.

В этой статье описываются требования к разрешениям для пользователей, управляющих кластерами больших данных, а также семантика учетной записи службы по умолчанию и доступ к Kubernetes из кластера больших данных.

Примечание.

Дополнительные материалы по модели RBAC Kubernetes см. в разделах Использование авторизации RBAC — Kubernetes и Использование RBAC для определения и применения разрешений — OpenShift.

Роль, необходимая для развертывания

SQL Server 2019 Кластеры больших данных использует учетные записи служб (напримерsa-mssql-controller, илиmaster) для оркестрации подготовки модулей pod кластера, служб, высокого уровня доступности, мониторинга и т. д. При запуске развертывания кластера больших данных (например, azdata bdc createAzure Data CLIazdata) выполняет следующие действия:

  1. Проверяет, существует ли указанное пространство имен.
  2. Если оно не существует, создает его и применяет метку MSSQL_CLUSTER.
  3. Создает учетную запись службы sa-mssql-controller.
  4. Создает роль <namespaced>-admin с полными разрешениями на пространство имен или проект, но не разрешениями уровня кластера.
  5. Создает назначение роли этой учетной записи службы для роли.

После выполнения этих шагов подготавливаются объекты pod уровня управления, а учетная запись службы развертывает оставшуюся часть кластера больших данных. 

В конечном итоге осуществляющий развертывание пользователь должен иметь разрешения на выполнение следующих задач:

  • Вывод списка пространств имен в кластере (1).
  • Исправление нового или существующего пространства имен с меткой (2).
  • Создайте учетную запись sa-mssql-controllerслужбы, <namespaced>-admin роль и привязку роли (3-5).

Роль по умолчанию admin не имеет таких разрешений, поэтому пользователь, развертывающий кластер больших данных, должен иметь по меньшей мере разрешения администратора на уровне пространства имен.

Роль кластера, необходимая для сбора метрик объектов pod и узлов

Начиная с накопительного пакета обновления 5 для SQL Server 2019 для сбора метрик объектов pod и узлов Telegraf требует учетную запись службы с разрешениями роли в масштабе кластера. Во время развертывания (или обновления существующих развертываний) мы пытаемся создать необходимую учетную запись службы и роль кластера, но если пользователь, развертывающий кластер или осуществляющий обновление, не обладает достаточными разрешениями, развертывание или обновление продолжится с предупреждением и завершится успешно. В этом случае метрики объектов pod и узлов собираться не будут. Пользователь, развертывающий кластер, должен попросить администратора кластера создать роль и учетную запись службы (до или после развертывания или обновления). После создания их использует кластер больших данных.

Ниже демонстрируется создание необходимых артефактов.

  1. Создайте файл metrics-role.yaml с приведенным ниже содержимым. Не забудьте заменить заполнители <clusterName> именем кластера больших данных.

    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. Создайте роль кластера и привязку роли кластера:

    kubectl create -f metrics-role.yaml

Учетную запись службы, роль кластера и привязку роли кластера можно создать либо до, либо после развертывания кластера больших данных. Kubernetes автоматически обновляет разрешение для учетной записи службы Telegraf. Если эти данные создаются в качестве развертывания объекта pod, то в собираемых метриках объектов pod и узлов будет наблюдаться задержка в несколько минут.

Примечание.

Накопительный пакет обновления 5 для SQL Server 2019 представляет два параметра для управления сбором метрик объектов pod и узлов. По умолчанию для этих параметров задано значение true во всех целевых объектах среды, кроме OpenShift, где значение по умолчанию переопределено.

Эти параметры можно настроить в разделе безопасности в файле конфигурации развертывания control.json:

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

Если для этих параметров задано значение false, рабочий процесс развертывания кластера больших данных не будет пытаться создать учетную запись службы, роль кластера и привязку для Telegraf.

Использование учетной записи службы по умолчанию из модуля pod кластера больших данных

Для более надежной модели безопасности в SQL Server 2019 CU5 по умолчанию отключено подключение учетных данных в модулях BDC для учетной записи службы Kubernetes по умолчанию. Это относится как к новым, так и к обновленным развертываниям в CU5 или более поздних версиях. Токен учетных данных внутри модулей Pod можно использовать для доступа к серверу API Kubernetes, а уровень разрешений зависит от параметров политики авторизации Kubernetes. В случае особых вариантов использования, требующих возврата к предыдущему поведению CU5, в CU6 мы представляем новый переключатель, чтобы вы могли включить автоматическое подключение только на время развертывания. Это можно сделать с помощью файла развертывания конфигурации и установив для параметра automountServiceAccountToken значение true. Выполните следующую команду, чтобы обновить этот параметр в пользовательском файле конфигурации control.json с помощью Azure Data CLI (azdata):

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

Связанный контент