#kubernetes #yaml #kubectl #kubernetes-networkpolicy #kubernetes-security
Вопрос:
Я знаю, как использовать RBAC с сертификатами X. 509 для идентификации пользователя kubectl
и ограничения их (использования Role
и RoleBinding
) от создания модулей любого типа в пространстве имен. Однако я не знаю, как я могу запретить им размещать определенные метки на модуле (или любом ресурсе), который они пытаются создать.
То, что я хочу сделать, это что-то вроде:
- Создайте
NetworkPolicy
, чтобы только ресурсам в других пространствах имен с меткойgroup: cross-ns
разрешался доступ к ресурсу вspecial-namespace
- У пользователя, который не может создавать модули или другие ресурсы с меткой
group: cross-ns
- Есть другой пользователь, который может создавать ресурсы с помощью метки
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 ).