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

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

  • Статья

Область применения: AKS в Azure Local 22H2, AKS на Windows Server

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

Обзор AD в AKS с поддержкой Arc

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

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

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

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

Примечание.

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

Примечание.

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

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

  • Создайте учетную запись AD для сервера API, а затем создайте файл keytab , связанный с учетной записью. См. статью "Создание проверки подлинности AD" с помощью файла keytab для создания учетной записи AD и создания файла keytab.
  • Используйте файл keytab для установки проверки подлинности AD в кластере Kubernetes. В рамках этого шага конфигурация управления доступом на основе ролей (RBAC) по умолчанию создается автоматически.
  • Преобразуйте имена групп в идентификаторы безопасности и наоборот при создании или редактировании конфигураций RBAC см. в статье о создании и обновлении привязки роли группы AD для инструкций.

Подготовка к работе

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

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

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

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

    Примечание.

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

Для присоединенного к домену локального кластера Azure или кластера 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> в прописных буквах. Однако если у вас возникли проблемы с прописными буквами, создайте имя участника-службы с строчными буквами. 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.
  • Замените имя субъекта-службы, соответствующее вашей среде.
  • Параметр -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. Если операция выполнена успешно, вы правильно настроили единый вход AD.

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

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

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

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

Пример 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 для учетной записи AD.

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

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

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, где домен является выходным результатом эха%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 с учетными данными единого входа. Далее вы можете выполнить такую задачу: