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

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

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

Кластеры больших данных 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. Создает назначение учетной записи службы для этой роли.

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

Следовательно, развертывающий пользователь должен иметь разрешения на следующие действия:

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

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

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

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

Ниже приведены инструкции по созданию необходимых артефактов:

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
   

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

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

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

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

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

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

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

Related content

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