Контроль допуска в Container Security

Режимы проверки

Для политик контроля допуска используются режимы проверки validationActions: Deny, Warn, Audit.

В режиме Deny при нарушении политики валидации действие с объектом, например создание или изменение, заблокируется.

В режимах Audit и Warn нарушение правила не препятствует действию с объектом. Операция разрешается, но информация о несоответствии:

• Фиксируется в отчете, если указан режим Audit.

• Отображается сразу, если указан режим Warn.

Область применения

Область применения политик контроля допуска задается в манифесте создания политики с помощью блока matchConstraints. Если запрос не удовлетворяет условиям matchConstraints, политика пропускается.

Блок matchConstraints содержит обязательный параметр resourceRules, который определяет, какие типы ресурсов Kubernetes должна оценивать политика допуска.

Каждый resourceRules описывается четырьмя обязательными полями:

• apiGroups — API-группа ресурса. Для базовых ресурсов, например Pod, Namespace, Service, указывается пустая строка [""]. Для ресурсов из расширенных групп, например apps или networking.k8s.io, указывается название группы.

• apiVersions — версия API, например v1.

• operations — операции, при которых срабатывает правило — CREATE, UPDATE, DELETE или * для всех.

• resources — тип ресурса, например pods, deployments. Можно указать подресурсы, например pods/ephemeralcontainers.

Особенности:

• Правила читаются как ИЛИ. При наличии нескольких resourceRules политика сработает, если запрос соответствует хотя бы одному из них.

• Осторожно с пустым apiGroups. Для базовых ресурсов, например Pod, нужно указывать [""], а не пустой список []. Ошибка в этом поле может привести к сбоям.

Пример

matchConstraints:
  resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods"]

В примере правило применяется к созданию и обновлению Pod в базовой группе API.