Политики валидации

Типы политик

Container Security поддерживает создание политик валидации:

• Kubernetes — нативные Kubernetes-политики валидации. Политика применяется для объектов, определенных в биндинге.

• Kyverno (весь кластер) — расширенные политики валидации, которые применяются для объектов всего кластера.

• Kyverno (пространство имен) — расширенные политики валидации, которые применяются для объектов указанного пространства имен в кластере.

Автоматическая генерация правил валидации для контроллеров подов

Поды — один из самых распространенных типов объектов в Kubernetes, и поэтому они являются основой большинства правил валидации. Однако создание подов напрямую почти не практикуется.

Вместо прямого создания подов в Kubernetes обычно используют высокоуровневые контроллеры, которые управляют подами автоматически. К таким контроллерам относятся Deployment, DaemonSet, StatefulSet, Job и CronJob.

Создавать отдельные политики, ориентированные непосредственно на поды, для Deployment, DaemonSet, StatefulSet, Job и CronJob было бы трудоемко и избыточно.

Container Security устраняет эту проблему: если политика валидации Kyverno написана специально для пода, система генерирует соответствующие политики и для контроллеров более высокого уровня.

Поведение автоматической генерации политики управляется параметром spec.autogen.podControllers.controllers в Kyverno-политике. Достаточно перечислить в аннотации контроллеры, для которых которых будут автоматически создаваться политики:

spec:
  autogen:
    podControllers:
      controllers:
        - deployments
        - statefulsets

В примере Container Security сгенерирует правила для Deployment и StatefulSet.

Проверка соблюдения политик валидации в режиме фонового сканирования

Container Security может проверять объекты, созданные в кластере до создания политики, на соответствие политикам валидации Kyverno. Такая проверка необходима для оценки влияния новых политик валидации на кластер перед их переводом в режим «Deny».

Чтобы фоновое сканирование выполнялось, необходимо в YAML-конфигурации политики для параметра spec.background.evaluation.enabled указать значение true:

spec:
  evaluation:
    background:
      enabled: true

Если в ходе фонового сканирования обнаруживаются объекты, нарушающие действующую политику, информация об этом публикуется в отчете.

Фоновое сканирование не блокирует существующие ресурсы, подпадающие под действие правила.

Для отключения фонового сканирования в YAML-конфигурации политики для параметра spec.background.evaluation.enabled необходимо указать значение false:

spec:
  evaluation:
    background:
      enabled: false

Настройка разрешений для генерации отчетов контроля допуска

Для генерации отчетов о соблюдении Kyverno-политик у контроллера отчетов Container Security должны быть права на получение списка объектов проверки. Kubernetes-роль view по умолчанию разрешает доступ к просмотру списка большинства объектов. Но просмотр списка чувствительных объектов, таких как ClusterRole или Secret, не разрешен ролью view.

При создании Kyverno-политики, которая проверяет не включенные в роль view объекты, необходимо в кластер добавить отдельную роль с правами на просмотр списка таких объектов. Иначе проверка выполнится, но отчет сформирован не будет.

Пример роли с правами для контроллера отчетов на просмотр списка ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kyverno:list-clusterroles
  labels:
    rbac.kyverno.io/aggregate-to-reports-controller: 'true'
rules:
  - apiGroups:
      - rbac.authorization.k8s.io
    resources:
      - clusterroles
    verbs:
      - get
      - list
      - watch

Где:

• rbac.kyverno.io/aggregate-to-reports-controller: 'true' — метка для механизма aggregated clusterroles, который автоматически добавит роль в общую роль для контроллера отчетов.

• resources — перечень объектов, на просмотр списка которых предоставляется разрешение.

• verbs — набор разрешенных действий над указанными объектами. get, list и watch — обязательные действия для контроллера отчетов.