KubeUser: декларативное управление пользователями Kubernetes

13 августа 2026 г.

#access-management#certificates#gitops#operators#rbac#x509
Обложка статьи о операторе KubeUser для Kubernetes

Если вы управляете кластером Kubernetes, вы наверняка знаете, какую боль доставляет подключение нового разработчика или сервисного аккаунта. «Традиционный» процесс обычно выглядит так: сгенерировать приватный ключ с помощью openssl, создать запрос на подпись сертификата (Certificate Signing Request, CSR), отправить его в кластер, вручную одобрить, получить сертификат и наконец собрать kubeconfig-файл руками.

Всё это утомительно, чревато ошибками, и честно говоря — давно просилось под автоматизацию.

Знакомьтесь: KubeUser

KubeUser — это нативный оператор для Kubernetes, который превращает управление пользователями в декларативный опыт: описываешь желаемое состояние в коде, а оператор берёт всё остальное на себя. Никакой ручной возни с сертификатами — просто применяешь YAML-файл. Github

В этой статье мы разберём, как KubeUser решает головную боль с управлением X.509-сертификатами, как устроена его безопасность и как установить его за считанные минуты.

Проблема: в Kubernetes нет объекта «Пользователь»

Для автоматизированных процессов в Kubernetes есть ServiceAccount, но для людей-пользователей кластер полагается на внешние механизмы аутентификации. OIDC отлично подходит для крупных организаций, однако настраивать его для небольших команд или отдельных автоматизированных процессов зачастую избыточно. Многие команды возвращаются к X.509-клиентским сертификатам — и снова попадают в ручной «CSR-ад», описанный выше.

Решение:

KubeUser вводит Custom Resource Definition (CRD) с именем User. Он следует стандартному паттерну оператора:

  1. Вы описываете желаемое состояние: создаёте YAML-манифест User, указывая права доступа и срок действия.

  2. Контроллер выполняет согласование: автоматически генерирует приватный ключ, отправляет CSR в Kubernetes API и создаёт необходимые RBAC-привязки (RoleBindings/ClusterRoleBindings).

  3. Результат: полученный сертификат и готовый kubeconfig сохраняются в Kubernetes Secret.

Важно: KubeUser опирается на строго явную модель аутентификации (Strictly Explicit Authentication Model). Тип аутентификации (сейчас поддерживается только x509) необходимо указывать явно — никакой неоднозначности в конфигурации безопасности.

Практика: установка и рабочий процесс

Разберём реальный сценарий шаг за шагом.

1. Предварительные требования и установка

KubeUser требует cert-manager для управления сертификатами вебхуков.

# Установить cert-manager
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml
# Дождаться готовности cert-manager
kubectl wait --for=condition=ready pod -l app=cert-manager -n cert-manager --timeout=60s

После того как cert-manager запущен, установите KubeUser через Helm.

# Добавить репозиторий
helm repo add kubeuser https://openkube-hub.github.io/KubeUser
# Извлечь адрес API-сервера из текущего kubeconfig
export KUBERNETES_API_SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
# Установить оператор (пространство имён 'kubeuser' создаётся автоматически)
helm install kubeuser kubeuser/kubeuser --create-namespace -n kubeuser \
  --set env.KUBERNETES_API_SERVER="$KUBERNETES_API_SERVER"
# Проверить установку
kubectl get pods -n kubeuser

2. Создание пользователя («Alice»)

В этом сценарии мы подключаем опытного инженера Alice, которому нужна смесь из пространство-специфичных прав и доступа на уровне всего кластера. Требуется долгоживущий сертификат (1 год) с автоматическим обновлением за 30 дней до истечения.

apiVersion: auth.openkube.io/v1alpha1
kind: User
metadata:
  name: alice
spec:
  auth:
    type: x509
    ttl: 8760h          # 1 год (максимальный TTL)
    autoRenew: true
    renewBefore: "720h" # Обновить за 30 дней (720 часов) до истечения
  roles:
    - namespace: "development"
      existingClusterRole: "admin"
    - namespace: "staging"
      existingRole: "developer"
  clusterRoles:
    - existingClusterRole: "view"
    - existingClusterRole: "readonly-plus"

Важно: предварительное создание кастомных ролей

KubeUser привязывает пользователей к ролям, но не создаёт сами определения ролей. Все упомянутые роли должны существовать до применения манифеста User.

Запланировано в будущих обновлениях: библиотека предустановленных шаблонов ролей уже включена в roadmap и будет реализована в ближайшее время. Эта функция позволит оператору автоматически создавать стандартные определения ролей, ещё больше сокращая ручную настройку.

В конфигурации Alice:

  • Встроенные роли (admin, view): это стандартные ClusterRole Kubernetes. Они уже существуют, поэтому KubeUser привяжет к ним сразу.

  • Кастомные роли (developer, readonly-plus): это пользовательские роли. Их нужно создать вручную (через kubectl или через GitOps) до применения конфигурации Alice, иначе оператор сообщит об ошибке.

Пример создания недостающих ролей:

# Создать кастомную роль в пространстве имён
kubectl create role developer --verb=get,list,create,update --resource=pods,services -n staging

# Создать кастомную ClusterRole
kubectl create clusterrole readonly-plus --verb=get,list,watch --resource=pods,nodes,events

3. Получение учётных данных

После применения YAML-манифеста KubeUser берёт на себя всю тяжёлую работу. Запускать openssl вручную не нужно — просто получите сгенерированный секрет:

# Извлечь kubeconfig из секрета, созданного оператором
kubectl get secret alice-kubeconfig -n kubeuser -o jsonpath='{.data.config}' | base64 -d > alice.kubeconfig
# Проверить доступ
kubectl --kubeconfig alice.kubeconfig get pods -n development

4. Аудит

kubectl get users

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

Аудит привязок:

# Проверить привязки в пространстве имён 'development'
kubectl get rolebindings -n development | grep alice
# Проверить глобальные привязки
kubectl get clusterrolebindings | grep alice

Безопасность: «теневые секреты» и безопасная ротация

KubeUser — это не просто обёртка над openssl; он реализует полноценное управление жизненным циклом сертификатов в production-среде.

  • Паттерн «теневого секрета» (Shadow Secret)

    Ротация сертификата без должной осторожности ведёт к простою. KubeUser использует стратегию Shadow Secret: когда приходит время обновления, оператор генерирует новый ключ и CSR во временном состоянии и перезаписывает живой секрет лишь после того, как API-сервер успешно проверит новый сертификат. Это гарантирует атомарное обновление без простоев.

  • Правило 33%

    Следуя стандартам cert-manager, KubeUser автоматически инициирует обновление, когда осталось 33% срока жизни сертификата. Если у Alice трёхдневный сертификат, KubeUser попытается его ротировать через 48 часов, обеспечивая значительный запас до истечения срока.

  • Защитные ограничения (Guardrails)

    Чтобы предотвратить эффект «стада» (Thundering Herd), при котором клиенты заваливают API-сервер запросами на новые ключи, валидирующие вебхуки KubeUser устанавливают минимальный TTL в 24 часа.

Когда использовать KubeUser

KubeUser лучше всего подходит для окружений, где нужен GitOps-управляемый контроль доступа без накладных расходов на внешний Identity Provider (IdP) вроде Keycloak или Okta. Он заполняет пропасть между простыми ServiceAccount и сложными OIDC-решениями.

Заключение

Kubernetes движется к миру, где всё управляется как код, — и пользовательские учётные данные не должны быть исключением. KubeUser закрывает разрыв между сложными требованиями аутентификации и простотой Kubernetes-манифестов.

Посмотреть проект, поставить звезду репозиторию или внести вклад можно здесь: https://github.com/openkube-hub/KubeUser

Похожее

© 2026 meganuke