[Перевод] Как автоматизировать безопасность контейнеров в стиле Policy as Code с помощью CRD
Расскажем, как использовать 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 могут проверить оба манифеста и дать рекомендации команде разработки с точки зрения безопасности. Новые приложения будут деплоиться совместно с эффективными политиками безопасности от самого первого деплоя и до продакшена.
Использование поведенческого анализа для создания политик безопасности
Команды DevOps могут использовать возможности поведенческого анализа NeuVector в тестовых средах для разработки политик безопасности и создания yaml-файлов, пригодных к использованию в NeuVector CRD.
На следующем рисунке, начиная с нижнего правого угла диаграммы, показано, как ваша 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 можно сконфигурировать режим новых сервисов для определения, наблюдения или защиты.
Выбор режима наблюдения или защиты означает, что любой деплой или обновление сервиса будет в обязательном порядке включать настройку политик безопасности, определенных вами. Таким образом, сервис перейдет в активное состояние только после применения политик безопасности.
Используя возможности Kubernetes CRD и политики безопасности как код, ваши разработчики и DevOps смогут применять автоматизацию политик безопасности приложений и быть уверенными, что приложения гораздо лучше защищены на всех этапах: от начала разработки до работы в продакшен.
