[Перевод] Как автоматизировать безопасность контейнеров в стиле Policy as Code с помощью CRD

resej_lfa2uc6q7hw98dpinxlio.jpeg

Расскажем, как использовать CRD Kubernetes, чтобы автоматизировать безопасность и обеспечить защиту ваших приложений.

Перевод от команды журнала «Завтра облачно» Mail.ru Cloud Solutions. Источник: Niteen Kole How to Automate Container Security by Using CRDs to Get Security Policy as Code с дополнениями.

Зачем нужно CRD


Безопасность давно стала головной болью DevOps-команд. Существующие программные средства успешно решают задачи автоматизации сборки и выкатки приложений — автоматическая выкатка приложения на основе контейнеров стала стандартом. При этом автоматизация настройки безопасности сильно отстает.

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

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

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

Используя CRD для автоматизации и определяя настройки безопасности централизованно как код, можно одновременно ужесточить настройки безопасности и упростить их применение. Это в итоге приводит к тому, что приложения становятся более эффективными, с меньшим количеством ошибок, и, что самое главное, — более безопасными.

Как работает CRD


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

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

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

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

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

Кроме того, доступно версионирование для создания своих политик для каждой версии приложения, поддерживается интеграция с утилитами для управления политиками безопасности, такими как Open Policy Agent.

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

Создание NeuVector CRD


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

Создадим файл nvsecurityrule.yaml, содержащий описание 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


Для создания CRD выполните:

$ kubectl create -f nvsecurityrule.yaml


Как только NeuVector CRD будет создан, все ресурсы, созданные потом с параметром kind: NvSecurityRule будут обработаны этим CRD. Таким образом, можно создавать свои ресурсы с подключенными политиками безопасности. Перед тем как делать что-то, желательно изучить документацию NeuVector и добавить необходимые clusterroles и clusterrolebindings.

Также использование этого CRD для применения политик безопасности NeuVector в кластере 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-командой, DevOps могут проверить оба манифеста и дать рекомендации команде разработки с точки зрения безопасности. Новые приложения будут деплоиться совместно с эффективными политиками безопасности от самого первого деплоя и до продакшена.

mlkswl2haoy3el68vvrbk9iei7o.jpeg

Использование поведенческого анализа для создания политик безопасности


Команды DevOps могут использовать возможности поведенческого анализа NeuVector в тестовых средах для разработки политик безопасности и создания yaml-файлов, пригодных к использованию в NeuVector CRD.

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

Эти правила экспортируются и передаются разработчикам, которые вносят необходимые коррективы, и DevOps, которые тестируют их перед применением в продакшен.

b2ot4sh13g3djhzmohn3ketxliy.jpeg

Глобальные политики безопасности


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

c5trdkiv7j4gcsmnniniezn9bko.jpeg

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

Ниже приведен пример запрета 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 можно сконфигурировать режим новых сервисов для определения, наблюдения или защиты.

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

Используя возможности Kubernetes CRD и политики безопасности как код, ваши разработчики и DevOps смогут применять автоматизацию политик безопасности приложений и быть уверенными, что приложения гораздо лучше защищены на всех этапах: от начала разработки до работы в продакшен.

© Habrahabr.ru