Ответ
Доступ пользователей к приложениям в Kubernetes я разделяю на два уровня: доступ к API Kubernetes для административных задач и доступ к самим веб-приложениям.
1. Управление доступом к кластеру (Kubernetes API): Использую RBAC (Role-Based Access Control) в связке с внешним провайдером OIDC (например, Dex, подключённый к GitLab или GitHub).
- Пользователи аутентифицируются через корпоративный OIDC-провайдер.
- В Kubernetes создаю
ClusterRoleс необходимыми правами (например, только для чтения ресурсов в namespace). - Связываю пользователя или группу из OIDC с этой ролью через
ClusterRoleBinding.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: dev-team-read-only subjects: - kind: Group name: "dev-team" # Группа из OIDC-провайдера apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: view # Встроенная роль "только для чтения" apiGroup: rbac.authorization.k8s.io
2. Публикация и защита веб-приложений:
- Ingress Controller: Разворачиваю контроллер (например, NGINX Ingress или Traefik) для маршрутизации внешнего HTTP(S)-трафика на внутренние сервисы.
- Ingress-ресурс: Определяю правила маршрутизации, TLS-терминацию и базовые аннотации для балансировки нагрузки.
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress annotations: cert-manager.io/cluster-issuer: "letsencrypt-prod" spec: tls: - hosts: - app.example.com secretName: app-tls-secret rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: app-service port: number: 80 - Аутентификация на уровне Ingress: Для внутренних или админ-панелей настраиваю OAuth-прокси, например,
oauth2-proxy. Добавляю в аннотации Ingress правила, которые перенаправляют запросы на прокси для проверки аутентификации перед доступом к приложению.