См. " Сравнение методов аутентификации Kubernetes " от Этьен Дилокер
Возможное решение - x509 клиентские сертификаты :
Преимущества
Работа с кластером Kubernetes и выдача пользовательских сертификатов значительно более безопасна, чем обычная аутентификация
Недостатки
x509 сертификаты имеют очень длительный срок службы(месяцы или годы).Таким образом, отзыв доступа пользователя практически невозможен.Если вместо этого мы выберем выпуск краткосрочных сертификатов, взаимодействие с пользователем будет прекращено, поскольку замена сертификатов требует определенных усилий.
Но Этьен рекомендует OpenID :
Не было бы замечательно, если бы у нас были краткосрочные сертификаты или токены, выданные сторонней организацией, поэтому связь с операторами кластера K8s отсутствует.
И в то же время все это должно быть интегрировано с существующей корпоративной инфраструктурой, такой как LDAP или Active Directory .
. Здесь OpenID Connect (OIDC) .
Для моего примера я использовал Keycloak в качестве эмитента токена.Keycloak является одновременно и эмитентом токенов, и провайдером идентификации, и его довольно легко раскрутить с помощью Docker.
Использовать RBAC с такой аутентификацией не просто, но возможно.
См. " выпуск 118; Безопасность, аутентификация и вход в систему "
С 1.3 у меня есть SSO на приборной панели, отлично работающей с обратным прокси и OIDC / OAuth2.Я бы не стал создавать явный экран входа в систему, свести на нет модель RBAC и модель Auth, которая уже поддерживается.Было бы здорово иметь что-то, что говорит о том, кто является вошедшим в систему пользователем.
Обратите внимание, что, начиная с версии 1.3, может быть более простое решение.
Тот же поток включает в себя:
У меня есть работающий образ прототипа, который будет делать то, что, как я думаю, вы ищете: https://hub.docker.com/r/mlbiam/openunison-k8s-dashboard/
Я снял все требования к обеспечению пользователей и сократил его до:
- обратный прокси
- интеграция с openid connect
- отображение токена доступа пользователя
- страница простых ссылок
Это включает в себя привязку роли :
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
name: admin-role
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
nonResourceURLs: ["*"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1alpha1
metadata:
name: admin-binding
subjects:
- kind: Group
name: admin
- kind: ServiceAccount
name: default
namespace: kube-system
- kind: ServiceAccount
name: openunison
namespace: default
roleRef:
kind: ClusterRole
name: admin-role
Опять же, это было характерно для доступа к RBAC на панели мониторинга, и с тех пор было улучшено с помощью PR 2206 Добавить механизм входа (на панель инструментов) .
Он все еще может дать вам некоторые подсказки, чтобы связать обычного пользователя с RBAC kubernetes.