Policy as Code – CRDs для автоматизации настроек безопасности приложений

Расскажем, почему полезно и удобно использовать Kubernetes CRDs для автоматизации применения политик безопасности в контейнерных приложениях.

Подготовлено на основе Niteen Kole How to Automate Container Security by Using CRDs to Get Security Policy as Code.

На фоне автоматической сборки и выкатки приложений перед DevOps-командами встает задача автоматизации настроек безопасности. Сегодня можно легко внедрить автоматизированное сканирование уязвимостей, при этом политики безопасности обычно приходится применять вручную.

Kubernetes custom resource definitions (CRDs) определяют политики безопасности как код на начальном этапе сборки приложений и автоматизируют их применение при выкатке приложений. CRDs позволяют внедрить глобальные политики безопасности и централизованно настроить безопасность сразу для нескольких кластеров Kubernetes.

CRDs делают настройки безопасности одновременно строгими и простыми в применении. Это повышает эффективность приложений и сокращает количество ошибок.

CRDs совместимы с Kubernetes RBAC – для применения политик безопасности можно использовать сервисные аккаунты и роли Kubernetes. Кроме того, доступно создание отдельных политик для каждой версии приложения и поддерживается интеграция с утилитами для управления политиками безопасности (например, Open Policy Agent).

Готовые кластеры Kubernetescо специально адаптированной системой мониторинга на базе Prometheus и Grafana, а также TLS и RBAC для управления правами доступа и стандартизацией разработки в распределенных командах, можно бесплатно протестировать в облаке Mail.ru Cloud Solutions.

Рассмотрим пример применения политики безопасности, используя CRD внутри контейнерной платформы NeuVector (альтернативы: AquaSec, StackRox, Sysdig Secure, Twistlock).

NeuVector CRD содержит политики, которые сначала формируют полный профиль нормального поведения приложения. Профиль включает сетевые правила, процессы, протоколы, файловые операции и добавляется в белый список. Затем применяются настройки безопасности, разрешающие только подтвержденные сетевые соединения внутри контейнеров приложения. Эти соединения идентифицируются при инспекции 7 уровня модели OSI (уровень протоколов приложения). Таким образом предотвращаются попытки несанкционированного использования приложения путем подключения к нему извне или установления соединений внутри контейнеров.

Для создания правил безопасности NeuVector CRD можно использовать нативные YAML-файлы Kubernetes.

Создадим файл nvsecurityrule.yaml c описанием NeuVector CRD. В этом файле определим NvSecurityRule, которое относится к сущности namespaced, и NvClusterSecurityRule, которое относится к кластеру.

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: nvsecurityrules.neuvector.com
spec:
  group: neuvector.com
  names:
kind: NvSecurityRule
listKind: NvSecurityRuleList
plural: nvsecurityrules
singular: nvsecurityrule
  scope: Namespaced
  version: v1
  versions:
  — name: v1
served: true
storage: true
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: nvclustersecurityrules.neuvector.com
spec:
  group: neuvector.com
  names:
kind: NvClusterSecurityRule
listKind: NvClusterSecurityRuleList
plural: nvclustersecurityrules
singular: nvclustersecurityrule
  scope: Cluster
  version: v1
  versions:
  — name: v1
served: true
storage: true

 Чтобы создать NeuVector CRD, выполните команду:

$ kubectl create -f nvsecurityrule.yaml

 В результате все ресурсы, созданные с параметром kind: NvSecurityRule, будут обрабатываться NeuVector CRD. Таким образом вы можете создавать свои ресурсы с подключенными политиками безопасности.

Чтобы добавить необходимые clusterroles и clusterrolebindings, ознакомьтесь с документацией NeuVector.

Кроме того, использование NeuVector CRD для применения политик безопасности в кластере Kubernetes требует правильной настройки прав (RBAC):

•   Политики безопасности, определяемые CRD для какого-либо пространства имен, может применить только пользователь с правами на развертывание в указанное пространство имен.
•   Политики безопасности для кластера может применить только администратор кластера.

Ниже приведена часть тестового кода из demo-security-v1.yaml, который ограничивает контейнеры nginx-pod в пространстве имен demo, предоставляя доступ к другим контейнерам этого же пространства имен по протоколу HTTP.

apiVersion: v1

items:

— apiVersion: neuvector.com/v1

  kind: NvSecurityRule

  metadata:

name: nv.nginx-pod.demo

  spec:

egress:

— Selector:

     criteria:

     — key: service

       op: =

       value: node-pod.demo

     — key: domain

       op: =

       value: demo

     name: nv.node-pod.demo

   action: allow

   applications:

   — HTTP

   name: nv.node-pod.demo-egress-0

   ports: any

— Selector:

     criteria:

     — key: service

       op: =

 После этой части должно следовать описание всех сетевых соединений, разрешенных контейнерам в пространстве имен demo (например, соединения с сервером REDIS), а также процессы и дисковая активность, разрешенные каждому контейнеру. Чтобы политики безопасности применялись сразу после запуска приложения, сначала разверните политики безопасности NeuVector, а затем приложение.

Чтобы применить политику безопасности, выполните команду:

$ kubectl create -f demo-security-v1.yaml

 NeuVector вычитывает политики безопасности в созданных ресурсах и с помощью REST API обращается к контроллеру NeuVector, который создает правила и конфигурации в соответствии с переданными политиками безопасности.

Применение политик безопасности как кода открывает массу возможностей для DevOps/DevSecOps-команд и программистов.

CRD позволяют обеспечить безопасность приложения, начиная с самых ранних стадий разработки и заканчивая выкаткой. Можно одновременно делать манифесты для развертывания и применения политик безопасности.

После сборки образа, автоматической проверки на уязвимости и утверждения, DevOps могут проверить оба манифеста и дать разработчикам рекомендации по обеспечению безопасности. Новые приложения будут сразу развертываться вместе с эффективными политиками безопасности на всех стадиях разработки.

Для разработки политик безопасности и создания YAML-файлов DevOps-команды могут использовать возможности анализа поведения приложения в тестовых средах.

На схеме ниже показано, как DevOps-команда разворачивает приложение в тестовом окружении, в котором выполняется полный анализ поведения приложения и формируются профили безопасности. Эти профили экспортируются и передаются разработчикам, которые вносят соответствующие правки, и DevOps-команде, которая тестирует их перед выкаткой.

NeuVector CRD позволяет определять глобальные политики безопасности, не привязанные к конкретному приложению или группе приложений в кластере. Например, ваша команда по безопасности или внедрению может определить глобальные сетевые правила для блокирования каких-либо соединений во всех контейнерах или для настройки доступа к мониторингу всех процессов в кластере.

Одновременное использование общих политик безопасности и политик безопасности приложений позволяет гибко настроить безопасность с учетом всех особенностей вашей компании.

Пример запрета внешних ssh-соединений из контейнеров:

— apiVersion: neuvector.com/v1

  kind: NvClusterSecurityRule

  metadata:

name: containers

namespace: default

  spec:

egress: []  

file: []

ingress:

— Selector:

     criteria: []

     name: external

   action: deny

   applications:

   — SSH

   name: containers-ingress-0

   ports: tcp/22

process:

— action: deny

   name: ssh

   path: /bin/ssh

target:

      Selector:

     criteria:

     — key: container

       op: =

       value: '*'

     name: containers

   policymode: null

version: v1

С помощью NeuVector CRD можно управлять автоматической миграцией политик безопасности — всех или конкретных — из тестового окружения в продакшн-окружение. В консоли NeuVector можно сконфигурировать режим новых сервисов для определения, наблюдения или защиты.

При выборе режима наблюдения или защиты каждое развертывание или обновление сервиса будет обязательно включать настройку политик безопасности. То есть сервис станет активен только после применения политик безопасности.