В организации регулярно находят отклонения (drift) от требований безопасности в Kubernetes-манифестах — например, кто-то создаёт Pod с privileged: true или Service типа LoadBalancer без согласования. Как внедрить policy-as-code, чтобы предотвращать такие отклонения, а не находить их постфактум при аудите?

Короткий ответ

Нужно внедрить admission-контроллер политик (OPA Gatekeeper или Kyverno), который проверяет каждый создаваемый/изменяемый объект на соответствие заданным правилам и блокирует или помечает нарушающие ресурсы прямо в момент применения, а не ждать периодического аудита постфактум.

Как это работает подробнее

admission-контроллер подключается к API-серверу как webhook и получает запрос на создание/изменение ресурса до его сохранения в etcd; политика (написанная на Rego для OPA Gatekeeper или YAML-декларативно для Kyverno) проверяет объект по заданным правилам и возвращает allow/deny. Это превращает требования безопасности из документации в технически применяемый контроль.

Пример кода

security-example-463.yamlКопировать

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce
  rules:
    - name: no-privileged
      match:
        resources:
          kinds: ["Pod"]
      validate:
        message: "Privileged containers are not allowed"
        pattern:
          spec:
            containers:
              - =(securityContext):
                  =(privileged): "false"

Что использовать на практике

• Практика. политики сначала вводят в режиме «audit»/dry-run (только логируют нарушения без блокировки), собирают статистику, чтобы не сломать существующие легитимные случаи, обсуждают с командами исключения, и только затем переводят в режим «enforce» (блокировка). Нужные исключения оформляют явно через параметры политики (например, allowlist конкретных namespace), а не отключением всей политики.
• Проверка. Ожидаемое поведение: попытка создать Pod с privileged: true будет немедленно отклонена с сообщением из политики («Privileged containers are not allowed») ещё на этапе kubectl apply, а не найдена спустя недели при очередном аудите конфигураций — это проверяется прямой попыткой применить такой манифест и получением ошибки admission webhook.

Подводные камни

• Ошибка. включать политику сразу в блокирующем режиме без периода наблюдения, что ломает существующие рабочие нагрузки без предупреждения; писать политику слишком широко (блокирует больше, чем нужно) или слишком узко (не покрывает реальный кейс нарушения); не версионировать и не тестировать сами политики, из-за чего ошибка в правиле может заблокировать весь кластер.