Как запретить пользователю создавать модуль с определенной меткой?

#kubernetes #yaml #kubectl #kubernetes-networkpolicy #kubernetes-security

Вопрос:

Я знаю, как использовать RBAC с сертификатами X. 509 для идентификации пользователя kubectl и ограничения их (использования Role и RoleBinding ) от создания модулей любого типа в пространстве имен. Однако я не знаю, как я могу запретить им размещать определенные метки на модуле (или любом ресурсе), который они пытаются создать.

То, что я хочу сделать, это что-то вроде:

  1. Создайте NetworkPolicy , чтобы только ресурсам в других пространствах имен с меткой group: cross-ns разрешался доступ к ресурсу в special-namespace
  2. У пользователя, который не может создавать модули или другие ресурсы с меткой group: cross-ns
  3. Есть другой пользователь, который может создавать ресурсы с помощью метки group: cross-ns

Возможно ли это?

Комментарии:

1. Подумайте об использовании OPA Gatekeeper, я думаю, это сработает.

Ответ №1:

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

Kyverno работает как динамический контроллер доступа в кластере Kubernetes. Kyverno получает от сервера kube-apiserver проверяющие и изменяющие HTTP-обратные вызовы webhook для приема и применяет соответствующие политики для возврата результатов, которые обеспечивают соблюдение политик приема или отклоняют запросы.

Политика Kyverno-это набор правил, которые могут быть применены ко всему кластеру ( ClusterPolicy ) или к определенному пространству имен ( Policy ).


Я приведу пример, чтобы проиллюстрировать, как это может работать.

Сначала нам нужно установить Kyverno, у вас есть возможность установить Kyverno непосредственно из манифеста последней версии или с помощью Helm (см.: Краткое руководство по запуску).:

 $ kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/definitions/release/install.yaml
 

После успешной установки давайте создадим простой ClusterPolicy :

 apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: labeling-policy
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: deny-rule
    match:
      resources:
        kinds:
        - Pod
    exclude:
      clusterRoles:
      - cluster-admin
    preconditions:
      - key: "{{request.object.metadata.labels.purpose}}"
        operator: Equals
        value: "*"
    validate:
      message: "Using purpose label is not allowed for you"
      deny: {}
 

В приведенном выше примере только с помощью cluster-admin ClusterRole вы можете изменить модуль с меткой purpose .

Предположим, у меня есть два пользователя ( john и dave ), но john он связан только с cluster-admin ClusterRole помощью ClusterRoleBinding :

 $ kubectl describe clusterrolebinding john-binding
Name:         john-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  cluster-admin
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  john
 

Наконец, мы можем проверить, работает ли он так, как ожидалось:

 $ kubectl run test-john --image=nginx --labels purpose=test --as john
pod/test-john created

$ kubectl run test-dave --image=nginx --labels purpose=test --as dave
Error from server: admission webhook "validate.kyverno.svc" denied the request:

resource Pod/default/test-dave was blocked due to the following policies

labeling-policy:
  deny-rule: Using purpose label is not allowed for you

$ kubectl get pods --show-labels
NAME        READY   STATUS    RESTARTS   AGE   LABELS
test-john   1/1     Running   0          32s   purpose=test
 

Дополнительные примеры с подробными объяснениями можно найти в документации по политике написания Kyverno.

Комментарии:

1. Если я правильно понимаю, это, по сути, использование контроля допуска?

2. Одной из функций Kyverno является блокировка несоответствующих ресурсов с помощью средств контроля доступа (см.: О Kyverno ).