Привет, дорогой мой бложек. У меня для тебя новая заметка о том, как подключить Ubuntu (проверено на 18.04 и 20.04) к домену Active Directory.

Как всегда, ничего нового я не придумал. Всё и так есть в интернете, но теперь и здесь тоже будет. Зачем это надо я не буду рассказывать, т.к. если вы хотите это сделать, то скорее всего сами прекрастно знаете зачем вам это надо.

Подготовка

Для начала включаем universe пакеты. Если они еще не включены, то:

sudo tee -a /etc/apt/sources.list <<EOF
deb http://us.archive.ubuntu.com/ubuntu/ bionic universe
deb http://us.archive.ubuntu.com/ubuntu/ bionic-updates universe
EOF

Дамы и господа, Docker всё, расходимся. Шутка.

А если серьезно, то у нас есть примерно год, чтобы избавиться от Docker в качестве среды исполнения контейнеров в Kubernetes. В версии 1.20 (которая выйдет уже совсем скоро) будет объявлен устаревшим Docker. А в версии 1.23 его поддержка будет удалена вовсе. Чтобы в будущем не было проблем с обновлением кластера, надо потрудиться уже сейчас.

Менять мы его будем на ContainerD, т.к. под капотом у того же Docker как раз ContainerD и лежит. Надо лишь убрать всех посредников.

Чтобы настроить в Kerio Control подключение к IPv6 по протоколу 6to4 нам надо:

  1. Убедиться что мы имеем белый статический IPv4 адрес
  2. Воспользоваться услугами одного из туннельных брокеров
  3. Внести изменения в конфигурацию интерфейса в Kerio Control
  4. Перезагрузить Kerio Control

От туннельного брокера мы получим следующий парамерты:

  1. <Remote IPv4 Endpoint> - IPv4 адрес для подключения
  2. <IPv6 Gateway> - IPv6 адрес на стороне брокера на интерфейсе IPv6WAN (у вас может быть другое)
  3. <Local IPv6 Address>/<Prefix Length> - IPv6 адрес на вашей стороне на интерфейсе IPv6WAN

Свой статический IPv4 адрес вас попросят указать в настройках брокера.

Доброго времени суток, уважаемый читатель.

Для того, чтобы Windows узел мог нормально функционировать в Kubernetes кластере, нам надо каким-либо способом обеспечить работу на нем как минимум 3-х компонентов:

  1. kubelet
  2. kubeproxy
  3. flannel (или что-то другое, что обеспечивает работу сети)

Kubelet запускается в виде Windows-службы, тут всё просто и по сути ничем не отличается от того, как это происходит на Linux узлах. А вот с kubeproxy и flannel всё куда интереснее. Ранее я писал, как сделать так, чтобы они запускались в виде Windows-служб; но на Linux узлах эти 2 компонента запускаются с помощью DaemonSets.

Всем привет. Сегодня я хочу рассказать о том, как установить traefik в свой собственный on-premise kubernetes кластер в качестве Ingress Controller.

Traefik может работать в Kubernetes в 2 режимах:

  1. kubernetesingress - это когда он будет мониторить стандартные объекты с kind: Ingress с строить маршруты на базе их
  2. kubernetescrd - это когда для описания маршрутов надо будет создавать объкты kind: IngressRoute. Этот способ более гибкий, однако при переходе на другой Ingress Controller, вам полностью придется переписать Ingress правила. Кроме того, с точки зрения kubernetes, такой способ развертывания не является Ingress Controller'ом, но нам это не так важно. Важно что мы получим тот же результат.

Мы будем разворачивать и то, и то. Кроме того, мы еще и Let's Encrypt подключим.

Если есть необходимость примотнировать SMB шару внутрь Windows контейнера, то можно воспользоваться вот такой штукой.

Если коротко, то для начала надо настроить сами Windows узлы в кластере. Делается это путем копирования папки сюда: C:\usr\libexec\kubernetes\kubelet-plugins\volume\exec\

Затем создать секрет с логином и паролем (в виде base-64):

apiVersion: v1
kind: Secret
metadata:
  name: smb-secret
data:
  password: cGFzc3dvcmQ=
  username: dXNlcm5hbWU=
type: microsoft.com/smb.cmd

Создаем учетную запись:

New-ADServiceAccount $serviceaccount `
  -DNSHostName $hostname `
  -PrincipalsAllowedToRetrieveManagedPassword $principals

Здесь:

  • $serviceaccount - имя учетной записи (gMSA)
  • $hostname - $serviceaccount.domain.com (имя учетной записи + имя домена)
  • $principals - Список компьютеров, имеющих права на получение пароля от очетной записи

Теперь ее необходимо установить на всех Windows узлах в кластере. Подключаемся к каждому узлу и выполняем:

Add-WindowsFeature RSAT-AD-PowerShell
Install-ADServiceAccount -Identity $serviceaccount
Test-ADServiceAccount -Identity $serviceaccount

По умолчанию, Windows Server Core запускает cmd.exe в виде shell, т.к. ничего другого нет. Однако, PowerShell в этой роли куда полезнее. Тем более, что сразу после логина, обычно, первым делом запускается PowerShell.

Заменить одно на второе можно немного отредактировав реестр.

Запускаем PowerShell и произносим следующее заклинание:

Set-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon' `
                 -Name Shell `
                 -Value 'PowerShell.exe -NoExit -Command "Set-Location ~"'

На github есть готовый скрипт, для развертывания всего необходимого.

Нам надо скачать 5 файлов:

Поместив все файлы на master выполняем скрипт:

./deploy-gmsa-webhook.sh --file deploy-gmsa.yml --overwrite --tolerate-master

Group Managed Service Account

Для начала следует рассказать что же такое gMSA и зачем оно нам надо в контексте Kubernetes.

Сети на базе Windows обычно используют Active Directory (AD) для облегчения проверки подлинности и авторизации между пользователями, компьютерами и другими сетевыми ресурсами. Разработчики корпоративных приложений часто проектируют свои приложения для интеграции AD и работают на серверах, связанных с доменом, чтобы воспользоваться преимуществами интегрированной аутентификации Windows.

Хотя контейнеры Windows не могут быть соединены доменом, они все еще могут использовать идентификаторы домена Active Directory для поддержки различных сценариев проверки подлинности.