Поделиться через

Использование единого входа Active Directory для безопасного подключения к серверу API Kubernetes в AKS на Windows Server

Область применения: AKS на Windows Server

Вы можете создать безопасное подключение к серверу API Kubernetes в AKS на Windows Server с помощью учетных данных единого входа Active Directory (AD).

Обзор Active Directory в AKS на Windows Server

Без проверки подлинности Active Directory необходимо полагаться на файл kubeconfig, основанный на сертификате, при подключении к серверу API с помощью команды kubectl. Файл kubeconfig содержит такие секреты, как закрытые ключи и сертификаты, которые должны быть тщательно распределены, что может быть значительным риском безопасности.

В качестве альтернативы использованию kubeconfig на основе сертификатов можно использовать учетные данные единого входа AD в качестве безопасного способа подключения к серверу API. Интеграция AD с AKS Arc позволяет пользователям на компьютере, присоединенном к домену Windows, подключаться к серверу API через kubectl, используя учетные данные SSO. Это удаляет необходимость управлять файлами kubeconfig на основе сертификатов и распространять их, содержащие закрытые ключи.

Интеграция AD использует AD kubeconfig, которая отличается от файлов kubeconfig на основе сертификатов и не содержит секретов. Однако файл kubeconfig на основе сертификатов можно использовать для резервного копирования, например для устранения неполадок при подключении с использованием учетных данных Active Directory.

Еще одним преимуществом безопасности интеграции AD является то, что пользователи и группы хранятся в качестве идентификаторов безопасности (SID). В отличие от имен групп, идентификаторы siD являются неизменяемыми и уникальными и поэтому не имеют конфликтов именования.

Примечание.

Подключение AD однофакторной аутентификации поддерживается только для кластеров для рабочих нагрузок.

Примечание.

Использование вложенных групп AD (создание группы AD в другой группе AD) не поддерживается.

В этой статье описано, как настроить Active Directory в качестве поставщика удостоверений и включить единый вход с помощью kubectl:

Прежде чем начать

Прежде чем приступить к настройке учетных данных единого входа Active Directory, необходимо убедиться, что у вас есть следующие элементы:

  • Установлен последний модуль Aks-Hci PowerShell . Если вам нужно установить его, см. скачивание и установку модуля AksHci PowerShell.

  • Узел AKS установлен и настроен. Если необходимо развернуть хост, выполните действия по настройке развертывания.

  • Файл keytab доступен для использования. Если учетная запись недоступна, выполните действия, чтобы создать учетную запись AD сервера API и файл keytab.

    Примечание.

    Необходимо создать файл keytab для определенного имени субъекта-службы(SPN), и это имя субъекта-службы должно соответствовать учетной записи AD сервера API для кластера рабочей нагрузки. Кроме того, необходимо убедиться, что в процессе проверки подлинности AD используется тот же SPN (имя субъекта-службы). Файл keytab должен называться current.keytab.

  • Одна учетная запись AD сервера API доступна для каждого кластера рабочей нагрузки AKS.

  • Клиентский компьютер должен быть компьютером, присоединенным к домену Windows.

Создание проверки подлинности AD с помощью файла keytab

Шаг 1. Создание кластера рабочей нагрузки и включение проверки подлинности AD

Перед установкой проверки подлинности AD необходимо сначала создать кластер рабочей нагрузки AKS и включить надстройку проверки подлинности AD в кластере. Если при создании нового кластера проверка подлинности AD не включена, его нельзя включить позже.

Откройте PowerShell от имени администратора и выполните следующие действия с помощью -enableADAuth параметра New-AksHciCluster команды:

New-AksHciCluster -name mynewcluster1 -enableADAuth

Для каждого кластера рабочей нагрузки убедитесь, что доступна одна учетная запись СЕРВЕРА API AD.

Сведения о создании кластера рабочей нагрузки см. в статье "Создание кластеров Kubernetes с помощью Windows PowerShell".

Шаг 2. Установка проверки подлинности AD

Перед установкой проверки подлинности AD необходимо установить кластер рабочей нагрузки и включить проверку подлинности AD в кластере. Чтобы установить проверку подлинности AD, используйте один из следующих параметров.

Вариант 1

Для присоединенного к домену кластера Windows Server откройте PowerShell от имени администратора и выполните следующую команду:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob

Примечание.

Для SPN k8s/apiserver@CONTOSO.com используйте формат SPN k8s/apiserver@<realm name>. При первой попытке укажите <realm name> в прописных буквах. Однако если у вас возникли проблемы с прописными буквами, создайте SPN с строчными буквами. Kerberos учитывает регистр.

Вариант 2

Если узел кластера не присоединен к домену, используйте имя пользователя администратора или имя группы в формате SID, как показано в следующем примере.

Пользователь администратора:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>

Группа администраторов:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>

Сведения о поиске идентификатора безопасности учетной записи пользователя см. в разделе "Определение идентификатора безопасности пользователя или группы".

Прежде чем перейти к следующим шагам, запишите следующие элементы:

  • Убедитесь, что файл keytab имеет имя current.keytab.
  • Замените SPN (имя субъекта-службы), соответствующее вашей среде.
  • Параметр -adminGroup создает соответствующую привязку роли для указанной группы AD с правами администратора кластера. Замените contoso\bob (как показано в варианте 1 выше) группой AD или пользователем, соответствующим вашей среде.

Шаг 3. Тестирование веб-перехватчика AD и файла keytab

Убедитесь, что вебхук AD запущен на сервере API, а файл keytab хранится как секрет Kubernetes. Чтобы получить файл kubeconfig на основе сертификатов для кластера рабочей нагрузки, выполните следующие действия.

  1. Получите файл kubeconfig на основе сертификата с помощью следующей команды. Используйте файл kubeconfig для подключения к кластеру в качестве локального узла:

    Get-AksHciCredential -name mynewcluster1

  2. Запустите kubectl на сервере, к которому вы подключились (с помощью файла kubeconfig, основанного на сертификате, который вы создали ранее), а затем проверьте развертывание веб-перехватчика AD, чтобы убедиться, что он соответствует формату ad-auth-webhook-xxxx.

    kubectl get pods -n=kube-system

  3. Запустите kubectl, чтобы проверить, файл keytab развернут как секрет и указан как секрет Kubernetes.

    kubectl get secrets -n=kube-system

Шаг 4. Создание файла kubeconfig AD

После успешного развертывания веб-перехватчика AD и keytab создайте файл AD kubeconfig. После создания файла скопируйте файл AD kubeconfig на клиентский компьютер и используйте его для проверки подлинности на сервере API. В отличие от файла kubeconfig на основе сертификатов, AD kubeconfig не является секретом и безопасно копировать как обычный текст.

Запустите PowerShell с правами администратора и выполните следующую команду.

Get-AksHciCredential -name mynewcluster1 -configPath .\AdKubeconfig -adAuth

Шаг 5. Копирование kubeconfig и других файлов на клиентский компьютер

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

  • Скопируйте файл AD kubeconfig, созданный на предыдущем шаге, в $env:USERPROFILE.kube\config.

  • Создайте путь к папке c:\adsso и скопируйте следующие файлы из кластера рабочей нагрузки AKS на клиентский компьютер:

    • Kubectl.exe в папке $env:ProgramFiles\AksHci переместить в c:\adsso.
    • Kubectl-adsso.exe в папке $env:ProgramFiles\AksHci в c:\adsso.

    Примечание.

    Файл adsso.exe создается на сервере при запуске командлета Get-AksHciCredential .

Шаг 6. Подключение к серверу API с клиентского компьютера

После выполнения предыдущих действий используйте учетные данные единого входа для входа на клиентский компьютер, присоединенный к домену Windows. Откройте PowerShell и попытайтесь получить доступ к серверу API с помощью kubectl. Если операция завершена успешно, вы правильно настроили SSO для AD.

Создание и обновление связывания ролей групп в AD

Как упоминалось на шаге 2, привязка роли по умолчанию с правами администратора кластера создается для пользователя и (или) группы, предоставленной во время установки. Привязка ролей в Kubernetes определяет политики доступа для групп AD. На этом шаге описывается, как использовать RBAC для создания новых привязок групповой роли AD в Kubernetes и изменения существующих привязок ролей. Например, администратор кластера может предоставить пользователям дополнительные привилегии с помощью групп AD (что делает процесс более эффективным). Дополнительные сведения о RBAC см. в статье об использовании авторизации RBAC.

При создании или изменении других записей RBAC группы AD имя субъекта должно иметь префикс microsoft:activedirectory:CONTOSO\название группы. Обратите внимание, что имена должны содержать доменное имя и префикс, заключенный в двойные кавычки.

Вот два примера:

Пример 1

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding 
metadata: 
  name: ad-user-cluster-admin 
roleRef: 
  apiGroup: rbac.authorization.k8s.io 
  kind: ClusterRole 
  name: cluster-admin 
subjects: 
- apiGroup: rbac.authorization.k8s.io 
  kind: User 
  name: "microsoft:activedirectory:CONTOSO\Bob"

Пример 2

В следующем примере показано, как создать настраиваемую роль и привязку ролей для пространства имен с группой AD. В этом примере SREGroup представляет собой существующую группу в Contoso Active Directory. Когда пользователи добавляются в группу AD, они немедленно получают привилегии.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ad-user-cluster-admin
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: "microsoft:activedirectory:CONTOSO\SREGroup"

Перед применением YAML-файла группы и имена пользователей всегда должны быть преобразованы в идентификаторы SID с помощью команды:

kubectl-adsso nametosid <rbac.yml>

Аналогичным образом, чтобы обновить существующий RBAC, можно преобразовать идентификатор безопасности в понятное имя группы перед внесением изменений. Чтобы преобразовать идентификатор безопасности, используйте команду:

kubectl-adsso sidtoname <rbac.yml>

Изменение пароля учетной записи AD, связанной с учетной записью сервера API

При изменении пароля для учетной записи сервера API необходимо удалить надстройку проверки подлинности AD и переустановить ее с помощью обновленных текущих и предыдущих ключей.

При каждом изменении пароля необходимо переименовать текущую keytab (current.keytab) на предыдущую.keytab. Затем убедитесь, что вы назовете новый пароль current.keytab.

Внимание

Файлы должны называться current.keytab и previous.keytab соответственно. Существующие привязки ролей не влияют на это изменение.

Удаление и переустановка проверки подлинности AD

Возможно, потребуется переустановить единый вход AD при изменении учетной записи сервера API, при обновлении пароля или устранении неполадок.

Чтобы удалить проверку подлинности AD, откройте PowerShell от имени администратора и выполните следующую команду:

Uninstall-AksHciAdAuth -name mynewcluster1

Чтобы переустановить проверку подлинности AD, откройте PowerShell от имени администратора и выполните следующую команду:

Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob

Примечание.

Чтобы избежать простоя, если клиенты кэшировали билеты, -previousKeytab параметр требуется только при изменении пароля.

Создайте учетную запись AD для сервера API и файл keytab

В создании учетной записи AD и файла keytab участвуют два шага. Сначала создайте новую учетную запись AD/пользователя для сервера API с главным именем службы (SPN), затем создайте файл keytab для этой учетной записи.

Шаг 1. Создание учетной записи AD или пользователя для сервера API

Используйте команду New-ADUser PowerShell, чтобы создать новую учетную запись/пользователя AD с SPN. Приведем пример:

New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1

Шаг 2. Создание файла keytab для учетной записи AD

Чтобы создать файл keytab, используйте команду ktpass Windows.

Ниже приведен пример использования ktpass:

ktpass /out current.keytab /princ k8s/apiserver@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

Примечание.

Если вы видите ошибку DsCrackNames вернул 0x2 в записи имени, убедитесь, что параметр /mapuser имеет форму mapuser DOMAIN\user, где ДОМЕН является выводом команды echo %userdomain%.

Определение идентификатора безопасности пользователя или группы

Используйте один из следующих двух вариантов, чтобы найти идентификатор безопасности для учетной записи или других учетных записей:

  • Чтобы найти идентификатор безопасности, связанный с вашей учетной записью, в командной строке домашнего каталога введите следующую команду:

    whoami /user

  • Чтобы найти идентификатор безопасности, связанный с другой учетной записью, откройте PowerShell от имени администратора и выполните следующую команду:

    (New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value

Устранение неполадок с сертификатами

Веб-перехватчик и сервер API используют сертификаты для взаимной проверки подключения TLS. Срок действия этого сертификата истекает через 500 дней. Чтобы убедиться, что срок действия сертификата истек, просмотрите журналы из ad-auth-webhook контейнера:

kubectl logs ad-auth-webhook-xxx

Если вы видите ошибки проверки сертификатов, выполните шаги по удалению и переустановке вебхука и получении новых сертификатов.

Лучшие практики и упорядочение

  • Используйте уникальную учетную запись для каждого кластера.
  • Не используйте пароль для учетной записи сервера API в кластерах.
  • Удалите локальную копию файла keytab сразу после создания кластера и убедитесь, что учетные данные единого входа работают.
  • Удалите пользователя Active Directory, созданного для сервера API. Дополнительные сведения см. в разделе Remove-ADUser.

Следующие шаги

Из этого руководства вы узнали, как настроить проверку подлинности AD для безопасного подключения к серверу API с учетными данными единого входа. Далее вы можете выполнить такую задачу: