DevSecops в Kubernetes с использованием jsPolicy

Кластеры Kubernetes теперь повсюду. Чтобы запустить модель машинного обучения, вам нужен кластер Kubernetes, если вы хотите запустить аналитику данных, вам нужен кластер Kubernetes, для развертывания вашего внешнего приложения, внутреннего приложения или любого типа приложения вам понадобится кластер Kubernetes. Но защищен ли ваш кластер? Вы когда-нибудь беспокоились о безопасности кластера? Предположим, вы пытаетесь запустить какие-то сценарии автоматизации и случайно удалили все пространства имен в Production. Бум, это будет самый длинный день в жизни инженера DevOps. Даже мысль об этом может вызвать мурашки у инженеров DevOps, читающих это. Есть ли способ избежать этого? Есть ли способ эффективно контролировать такие бедствия? jsPolicy в помощь. jsPolicy — это механизм политик для Kubernetes, который позволяет вам писать политики на JavaScript или TypeScript.

Преимущества jsPolicy

а) Молниеносное и безопасное выполнение политик: jsPolicy запускает политики с помощью сверхбыстрого движка Google V8 JavaScript в пуле предварительно нагретых изолированных сред. Для выполнения большинства политик не требуется даже одной миллисекунды.

б) Отличный язык для политик: JavaScript создан для обработки и управления объектами JSON (сокращение от «JavaScript Object Notation» (!)), и Kubernetes использует JSON, преобразовывая ваш YAML в JSON при каждом запросе API.

О чем вся история? (TLDR)

  1. Защита кластера K8s с помощью jsPolicy.
  2. Создание политик безопасности в JavaScript с помощью jsPolicy.

Предпосылки

  1. Кластер Kubernetes (EKS, AKS, Kind и т. д.).

Сюжетные ресурсы

  1. Ссылка на GitHub: https://github.com/pavan-kumar-99/medium-manifests
  2. Ветка GitHub: jsPolicy

Установка и архитектура jsPolicy

Компоненты

Хотя jsPolicy запускает все свои компоненты в одном контейнере (не учитывая реплики при увеличении числа реплик для обеспечения высокой доступности), jsPolicy логически состоит из трех основных компонентов:

Менеджер веб-перехватчиков

Диспетчер веб-перехватчиков отвечает за регистрацию и управление допущенными веб-перехватчиками на сервере API Kubernetes, чтобы запросы к серверу API применяли изменяющие и проверяющие веб-перехватчики, определенные как JsPolicy объекты.

Пул песочницы V8 JavaScript

Для более быстрого выполнения кода политики jsPolicy поддерживает пул предварительно нагретых изолированных программных сред JavaScript V8, которые можно использовать для запуска кода JavaScript, содержащего логику политики.

Компилятор политики

Компилятор политики — это контроллер, который отслеживает JsPolicy ресурсы и создает и обновляет JsPolicyBundle объекты для всех JsPolicy объектов, определяющих поле spec.javascript. Процесс компиляции выглядит примерно так:

  1. Получить все необходимые npm пакеты, указанные в spec.dependencies (аналогично npm install загрузке dependencies, указанных в package.json файле обычного проекта JavaScript)
  2. Запустите webpack, чтобы создать высокооптимизированный пакет кода JavaScript, который содержит код из spec.javascript и все зависимости, в то же время объединяя только те функции, которые необходимы для выполнения кода.
  3. Сжать пакет с помощью gzip.
  4. Закодируйте пакет, используя base64.
  5. Сохраните пакет в spec.bundle в соответствующем объекте JsPolicyBundle.

Установить jsPolicy

jsPolicy запускает все свои компоненты в одном контейнере. Это можно легко установить с помощью диаграммы руля.

$ helm install jspolicy jspolicy -n jspolicy --create-namespace --repo https://charts.loft.sh

Время увидеть jsPolicy в действии

Политики бывают трех типов

а) Мутирование: Политики мутирования выполняются как часть kubectl запросов сразу после того, как сервер API выполняет аутентификацию и авторизацию (RBAC). Целью изменения политик является изменение полезной нагрузки (объекта Kubernetes), предоставленной в запросе, например. автоматически добавлять sidecar-контейнер при создании модуля.

b) Проверка: Политики проверки выполняются как часть kubectl запросов после выполнения политик изменения. Цель проверки политик — проверить запрос, а затем либо отклонить, либо разрешить его. например запретить создание модуля, если используется пространство имен по умолчанию, или запретить создание модуля, если образ взят из общедоступного репозитория.

c) Контроллер: в отличие от политик изменения и проверки, политики контроллера не являются частью жизненного цикла запроса к серверу API Kubernetes. Политики контроллера запускаются Events, которые Kubernetes создает для каждого изменения состояния кластера в etcd.e.g. Автоматическое создание определенных ресурсов в каждом вновь созданном пространстве имен (например, LimitRange, NetworkPolicy и т. д.)

Давайте посмотрим на всех троих в действии.

Политика изменения:

Эта jsPolicy говорит, что она имеет тип Mutating (строка 6) и применима при создании модулей (строка 7,8), и политика говорит, что если создаваемые модули имеют аннотацию «inject-agent»: «true» (строка 10), тогда модуль должен быть изменен дополнительным контейнером sidecar (строка 16). Давайте теперь создадим политику и модуль, чтобы проверить это.

$ git clone https://github.com/pavan-kumar-99/medium-manifests.git \
-b jsPolicy
$ cd medium-manifests
$ kubectl apply -f mutate-policy.yaml
$ kubectl apply -f pod.yaml

Модуль имеет необходимые аннотации, и теперь модуль должен быть создан с 2 контейнерами (и боковая панель автоматически мутируется).

Политика проверки:

Давайте удалим модуль, который мы создали ранее, а затем применим политику проверки.

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

$ git clone https://github.com/pavan-kumar-99/medium-manifests.git \
-b jsPolicy
$ cd medium-manifests
## Delete the Pod created earlier
$ kubectl delete -f pod.yaml
## Apply the validation webhook
$ kubectl apply -f default-ns-deny.yaml

Давайте теперь попробуем снова создать тот же модуль.

$ kubectl apply -f pod.yaml

Ошибка сервера (запрещено): ошибка при создании «pod. yaml»: веб-хук допуска «deny-default-namespace.devsecops.com» отклонил запрос: создание ресурсов в пространстве имен по умолчанию не разрешено!

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

Политика контроллера:

В этом примере мы попытаемся создать квоту ресурсов автоматически при каждом создании пространства имен. При условии, что пространство имен должно иметь метки "create-rq": "true".

$ git clone https://github.com/pavan-kumar-99/medium-manifests.git \
-b jsPolicy
$ cd medium-manifests
$ kubectl apply -f controller-policy.yaml
## Let us now create the namespace with the required labels
$ kubectl apply -f namespace.yaml

Как только пространство имен создано, вы можете обнаружить, что ResourceQouta также создается автоматически.

Именно так вы используете jsPolicy для написания различных типов политик в JavaScript и TypeScript с использованием jsPolicy. Пожалуйста, не стесняйтесь делиться своим опытом работы над этими политиками в разделе комментариев.

До скорого…..

рекомендуемые