Автоматически создавать ресурсы Kubernetes после создания пространства имен

Question

У меня 2 команды:

• devs: они создают новое пространство имен Kubernetes каждый раз, когда развертывают ветку / тег своего приложения.
• ops: они управляют контролем доступа к кластеру с помощью ролей (кластера) и привязок ролей (кластера)

Проблема в том, что "разработчики" не могут использовать kubectl для своих пространств имен, пока "операторы" не создадут ресурсы RBAC. И "разработчики" не могут сами создавать ресурсы RBAC, так как у них нет списка субъектов для добавления в ресурс привязки ролей (совместное использование списка не является вариантом).

Я прочитал официальную документацию о веб-перехватчиках допуска, но понял, что они действуют только на ресурс, который инициировал веб-перехватчик.

Есть ли в Kubernetes собственный и / или простой способ применения ресурсов при создании нового пространства имен?

Answer 1

Я придумал решение, написав собственный контроллер.

После развертывания следующего настраиваемого ресурса контроллер вводит role а также rolebinding в соответствующих пространствах имен dev-.* а также fix-.*:

kind: NamespaceResourcesInjector
apiVersion: blakelead.com/v1alpha1
metadata:
  name: nri-test
spec:
  namespaces:
  - dev-.*
  - fix-.*
  resources:
  - |
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: dev-role
    rules:
      - apiGroups: [""]
        resources: ["pods","pods/portforward", "services", "deployments", "ingresses"]
        verbs: ["list", "get"]
      - apiGroups: [""]
        resources: ["pods/portforward"]
        verbs: ["create"]
      - apiGroups: [""]
        resources: ["namespaces"]
        verbs: ["list", "get"]
  - |
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: dev-rolebinding
    subjects:
    - kind: User
      name: dev
    roleRef:
      kind: Role
      name: dev-role
      apiGroup: rbac.authorization.k8s.io

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

Вот для интересующихся: https://github.com/blakelead/nsinjector

Answer 2

Да, есть собственный способ, но не готовый к использованию.

Вы можете делать то, что вы описали, используя / создавая оператора. По сути, расширение API Kubernetes для ваших нужд.

Поскольку оператор - это просто открытый шаблон, который может реализовывать вещи разными способами, в сценарии, который вы указали, может выглядеть один способ потока управления:

1. Оператор с правами на создание RBAC развертывается и подписывается на изменения в типе объекта пространства имен k8s.
2. Разработчики создают пространство имен, содержащее согласованную метку
3. Оператор уведомляется об изменениях в кластере
4. Оператор проверяет валидацию пространства имен (это также можно сделать с помощью отдельного веб-перехватчика допуска)
5. Оператор создает RBAC во вновь созданном пространстве имен
6. Если RBAC являются общекластерными, тот же оператор может выполнить очистку RBAC после удаления пространства имен.

Answer 3

Это как бы связано с тем, как пользователь аутентифицируется в кластере и как он получает файл kubeconfig. Вы можете поместить группу в сертификат клиента или токен-носитель, который использует kubectl из kubeconfig. Заблаговременно вы можете определить роль кластера с привязкой к этой группе, которая дает им разрешение на использование определенных глаголов на определенных ресурсах (например, возможность создавать пространство имен).

Кроме того, вы можете использовать веб-перехватчик допуска, чтобы проверить, должен ли пользователь быть частью этой группы или нет.