Kubernetes OpenID Connect Integration с потоком владельца ресурсов

Привет 😄,

В этой статье я продемонстрирую, как настроить Kubernetes (Minikube) для использования OpenID Connect в качестве стратегии аутентификации.

Мы охватим Владелец ресурсов Пароль поток. Свободно выберите правильный поток аутентификации в зависимости от потребностей вашего приложения.

Пожалуйста, обратитесь к Эта диаграмма Для того, чтобы выбрать поток:

Обратите внимание, что Клиентские учетные данные поток — это не поддерживается от Kubernetes. По словам должностных лиц документов:

«Чтобы идентифицировать пользователя, аутентификатор использует ID_Token (не Access_Token ) от ответа токена OAUTT2 как токен на предъявителя. «

Поскольку поток учетных данных клиента возвращает только access_token, мы не сможем использовать этот поток с Kubernetes.

Чтобы играть с этими концепциями, нам нужно создать приложение OAUTH. Я предпочитаю использовать Auth0 Так что каждый может следовать бесплатно.

1. Создайте приложение типа Регулярное веб-приложение

2. Откройте вновь созданное приложение, перейдите к настройкам, прокрутите вниз и нажмите «Дополнительные настройки». На Типы грантов Вкладка Нажмите Пароль предмет и нажмите Сохранить.

3. ГОТО Аутентификация -> База данных и создайте новое соединение с базой данных. Я назвал мою связь Имя пользователя-пароль-аутентификация Отказ

4. ГОТО Настройки -> Арендатор А в разделе Настройки авторизации API установите Каталог по умолчанию Имя соединения с Имя пользователя-пароль-аутентификация

5. ГОТО Управление пользователями -> Пользователи и создать новый пользователь. Я назвал своего пользователя: uculabs-kube@nuculabs.dev и дал ему следующий пароль: pa27rgn9knen

Следующий Нажмите на пользователя и установите его адрес электронной почты как проверено.

Мы можем запустить Kubernetes локально на наших компьютерах, используя Minikube.

Если вы впервые играете с Minikube, последуйте инструкции по установке от: https://minikube.sigs.k8s.io/docs/start/ И начните свой кластер Minikube с Minikube Start. .

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

Теперь давайте начнем с помощью следующей команды:

minikube start --extra-config=apiserver.authorization-mode=RBAC --extra-config=apiserver.oidc-issuer-url="https://xxx.auth0.com/" --extra-config=apiserver.oidc-client-id=1RaJmjhjaapNLGXQjcYViQ15ZYzZoZdL --extra-config=apiserver.oidc-username-claim=email

--extra-config = apisiserver.oidc-easuer-url = Должно быть равна вашему домену AUTH0, он должен начать с HTTPS://и заканчивается с помощью/.

--extra-config = apisiserver.oidc-client-id = будет содержать идентификатор клиента клиента OAUTH.

--extra-config = apiserver.oidc-username-prem = Email будет установлен на электронную почту, потому что мы хотим сопоставить электронную почту нашего пользователя AUTH0 Nuculabs-kube@nuculabs.dev. пользователю, которое мы создадим в Kubernetes.

Auth0 вернет id_token от заголовка формы. Полезная нагрузка. Подпись. В нашем случае он будет полезной нагрузкой с полем Email который будет равен адресу электронной почты пользователя.

Следующий токен не включает Email претензия, но он включает Имя утверждают, что в этом случае мы можем использовать имя в качестве нашего Apiserver.oidc-username-rack.

Чтобы играть с Jwts Vision: https://jwt.io/#debugger-io.

Если ваш кластер Minikube начал, вы должны увидеть следующий вывод:

😄 minikube v1.20.0 on Microsoft Windows 10 Home 10.0.19042 Build 19042
✨ Using the docker driver based on existing profile
👍 Starting control plane node minikube in cluster minikube
🚜 Pulling base image …
🔄 Restarting existing docker container for "minikube" …
🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.6 …
▪ apiserver.authorization-mode=RBAC
▪ apiserver.oidc-issuer-url=https://xxx.auth0.com/
▪ apiserver.oidc-client-id=1RaJmjhjaapNLGXQjcYViQ15ZYzZoZdL
▪ apiserver.oidc-username-claim=email
🔎 Verifying Kubernetes components…
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Поздравляю за то, что сделал это так далеко! 🎉✨.

Следующий шаг — сопоставить нашу uculabs-kube@nuculabs.dev Пользователь к роли администратора внутри кластера Kubernetes.

Откройте свой любимый редактор кода, создайте Clusterrole.yaml и вставить следующее содержимое в нем:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin-role
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Далее, создайте Clusterrolebinding.yaml и вставить:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin-binding
subjects:
- kind: User
  name: nuculabs-kube@nuculabs.dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin-role

Примените роль и привязку роли в Minikube:

kubectl apply -f clusterrole.yaml
kubectl apply -f clusterrolebinding.yaml

Отлично, теперь мы общались с кластером Minikube, используя клиентский сертификат и ключ и пользователь Minikube.

PS C:\Users\denis\Downloads> cat C:\Users\denis\.kube\config
apiVersion: v1
clusters:
...
users:
- name: minikube
  user:
    client-certificate: C:\Users\denis\.minikube\profiles\minikube\client.crt
    client-key: C:\Users\denis\.minikube\profiles\minikube\client.key

Далее мы обновим KubeConfig, чтобы перейти на наш Nuculabs-kube@nuculabs.dev пользователь.

Файл Kubeconfig обычно находится в ~/.kube/config каталог, и он содержит информацию о кластерах и пользователях.

Для отправки запросов в Миникубу с Nuculabs-kube@nuculabs.dev Пользователь, сначала нам нужно схватить ID_Token:

curl --request POST \
  --url https://xxx.auth0.com/oauth/token \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data grant_type=password \
  --data client_id=1RaJmjhjaapNLGXQjcYViQ15ZYzZoZdL \
  --data client_secret=ZzxjjnOfxIj-__pUu7HCRNC9qknS5jYxOsTxd5Koz1uH7AmeXxtRClwlEW6WJLav \
  --data username=nuculabs-kube@nuculabs.dev \
  --data 'password=Pa27rgN9KneN'

{
  "access_token": "yepJxATWNN2hCZUmP4H4BzBaLycsUsJw",
  "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik1FSkVNRVE1TWtFMlFrUTRNVEZFTWpZNE5qSkRORFkxTURBMk16bENORVJET1VNelJUSTBPUSJ9.eyJuaWNrbmFtZSI6Im51Y3VsYWJzLWt1YmUiLCJuYW1lIjoibnVjdWxhYnMta3ViZUBudWN1bGFicy5kZXYiLCJwaWN0dXJlIjoiaHR0cHM6Ly9zLmdyYXZhdGFyLmNvbS9hdmF0YXIvMzQ1NjMxNzQxNjU0ODViYWE1NDBjOTBkODc2MzAyN2I_cz00ODAmcj1wZyZkPWh0dHBzJTNBJTJGJTJGY2RuLmF1dGgwLmNvbSUyRmF2YXRhcnMlMkZudS5wbmciLCJ1cGRhdGVkX2F0IjoiMjAyMS0wNS0xM1QxOTo1Nzo0Mi42ODZaIiwiZW1haWwiOiJudWN1bGFicy1rdWJlQG51Y3VsYWJzLmRldiIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwiaXNzIjoiaHR0cHM6Ly9kbnV0aXUtZGV2LmV1LmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw2MDlkNzlkMjk2OWU3MjAwNjhhNmFhNjciLCJhdWQiOiIxUmFKbWpoamFhcE5MR1hRamNZVmlRMTVaWXpab1pkTCIsImlhdCI6MTYyMDkzNTg2MiwiZXhwIjoxNjIwOTcxODYyfQ.avnUJv2aM0vpTkcoGiO54N4y765BxpXHV2alYAVXCpFeaNI2ISW-lW0sFUFrU3w35oM4p2Xh2tlMmVoQplSvJL0mJ9qZObMDvdqijFGdUbYN3XnD2F0kI5CCwshGhP59cbS_gdXIwwz3SOwDKKjGvacvEPcOofmhcBxNVW16qP7GS2JaAnrbGygCpj6AOyRcCkAL-jz0rxQCPrwZ5i1E4ofsbH0H8cVprYYazBpNRKPWcadcMqvGAXrtkrkSzHvrmTbQNaXi2rUiDzepDeJvciYJsNefLGmW2iStpB4KuN9M0wpXdV2PAd6lMYAd3sYSn_4NYLQKEbtmL5Sp1lkxow",
  "scope": "openid profile email address phone",
  "expires_in": 86400,
  "token_type": "Bearer"
}

Обратите внимание, что токен истекает в 86400 секунд, 24 часа, мы можем использовать его только в этом интервале времени. Не стесняйтесь декодировать токен на JWT.IO, чтобы осмотреть его содержание. 😀

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

apiVersion: v1
clusters:
- cluster:
    certificate-authority: C:\Users\denis\.minikube\ca.crt
    server: https://127.0.0.1:56840
  name: minikube
contexts:
- context:
    cluster: minikube
    namespace: default
    user: nuculabs-kube@nuculabs.dev
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube2
  user:
    client-certificate: C:\Users\denis\.minikube\profiles\minikube\client.crt
    client-key: C:\Users\denis\.minikube\profiles\minikube\client.key
- name: nuculabs-kube@nuculabs.dev
  user:
    auth-provider:
      name: oidc
      config:
        client-id: 1RaJmjhjaapNLGXQjcYViQ15ZYzZoZdL 
        client-secret: ZzxjjnOfxIj-__pUu7HCRNC9qknS5jYxOsTxd5Koz1uH7AmeXxtRClwlEW6WJLav
        idp-issuer-url: https://xxx.auth0.com/
        id-token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik1FSkVNRVE1TWtFMlFrUTRNVEZFTWpZNE5qSkRORFkxTURBMk16bENORVJET1VNelJUSTBPUSJ9.eyJuaWNrbmFtZSI6Im51Y3VsYWJzLWt1YmUiLCJuYW1lIjoibnVjdWxhYnMta3ViZUBudWN1bGFicy5kZXYiLCJwaWN0dXJlIjoiaHR0cHM6Ly9zLmdyYXZhdGFyLmNvbS9hdmF0YXIvMzQ1NjMxNzQxNjU0ODViYWE1NDBjOTBkODc2MzAyN2I_cz00ODAmcj1wZyZkPWh0dHBzJTNBJTJGJTJGY2RuLmF1dGgwLmNvbSUyRmF2YXRhcnMlMkZudS5wbmciLCJ1cGRhdGVkX2F0IjoiMjAyMS0wNS0xM1QxOTo1Nzo0Mi42ODZaIiwiZW1haWwiOiJudWN1bGFicy1rdWJlQG51Y3VsYWJzLmRldiIsImVtYWlsX3ZlcmlmaWVkIjpmYWxzZSwiaXNzIjoiaHR0cHM6Ly9kbnV0aXUtZGV2LmV1LmF1dGgwLmNvbS8iLCJzdWIiOiJhdXRoMHw2MDlkNzlkMjk2OWU3MjAwNjhhNmFhNjciLCJhdWQiOiIxUmFKbWpoamFhcE5MR1hRamNZVmlRMTVaWXpab1pkTCIsImlhdCI6MTYyMDkzNTg2MiwiZXhwIjoxNjIwOTcxODYyfQ.avnUJv2aM0vpTkcoGiO54N4y765BxpXHV2alYAVXCpFeaNI2ISW-lW0sFUFrU3w35oM4p2Xh2tlMmVoQplSvJL0mJ9qZObMDvdqijFGdUbYN3XnD2F0kI5CCwshGhP59cbS_gdXIwwz3SOwDKKjGvacvEPcOofmhcBxNVW16qP7GS2JaAnrbGygCpj6AOyRcCkAL-jz0rxQCPrwZ5i1E4ofsbH0H8cVprYYazBpNRKPWcadcMqvGAXrtkrkSzHvrmTbQNaXi2rUiDzepDeJvciYJsNefLGmW2iStpB4KuN9M0wpXdV2PAd6lMYAd3sYSn_4NYLQKEbtmL5Sp1lkxow

Примечание: аутентификация не будет работать, если у пользователя нет проверки электронной почты: E0513 20: 03: 32.089659 1 Аутентификация .GO: 53] Невозможно аутентифицировать запрос из-за ошибки: [Неверный токен Neger, OIDC: электронная почта не проверена] Вам нужно будет создать другого пользователя или установить электронную почту пользователя в соответствии с интерфейсом Auth0.

Чтобы убедиться, что аутентификация сохранена файл kubeconfig и запустите:

PS C:\Users\denis\Downloads> kubectl get services
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1            443/TCP   33m

Если вы измените один байт в ID-токене, то аутентификация больше не будет работать.

✨ Мы успешно взаимодействовали с Minikube с нашим пользователем AUTH0. ✨

Поскольку поток владельца ресурса не возвращает refresh_token Плагин авторизации OIDC Plugin для Kubectl не сможет обновить токен, поэтому необходим ручное обновление.

Документация Kubernetes Предлагает решение для этого: ExectEdentials. Вы можете использовать существующий плагин GO или напишите себе программу, которая выполняется и печатает Экспреденциальный Объект к STDOUT, который выглядит так:

{
  "apiVersion": "client.authentication.k8s.io/v1beta1",
  "kind": "ExecCredential",
  "status": {
    "token": "my-bearer-token"
  }
}

Если ExpirateTimestamp Предлагается наряду с токеном, затем Kubectl будет кэшировать токен, пока токен не истечет иначе, если IspirateTimestamp отсутствует, то KUBECTL будет использовать токен, пока сервер не отвечает 401.

KUBECTL-файл, сделанный для сценария Exectredentials, будет выглядеть так:

users:
- name: nuculabs-kube@nuculabs.dev
  user:
    exec:
      apiVersion: "client.authentication.k8s.io/v1beta1"
      command: "my-program-that-prints-an-credential"
      args:
      - "print-token"

Спасибо за чтение 📚!

Рекомендации:

Читайте ещё по теме: