Обеспечение безопасности Kubernetes с помощью Open Policy Agent (OPA)

Kubernetes — это мощный инструмент, который помогает нам эффективно и надежно управлять и развертывать наше программное обеспечение. Однако по мере того как наши системы становятся все более сложными, может возникнуть проблема с обеспечением их безопасности и соответствия правилам и нормам. Именно здесь на помощь приходит Open Policy Agent (OPA). Перевели туториал, где рассматривается, как OPA можно использовать в Kubernetes для обеспечения безопасности наших систем и соблюдения политик.

Что такое OPA?

Прежде чем погрузиться в изучение OPA в Kubernetes, стоит рассмотреть, что такое OPA и как он работает. OPA — это механизм политики, который оценивает политики во время выполнения. Он обеспечивает централизованный способ управления политиками, которые могут применяться в различных приложениях и средах. OPA использует язык политик под названием Rego, который позволяет разработчикам писать политики как в человекочитаемом, так и в машиноисполняемом виде. После написания политик они хранятся в центральном хранилище политик, доступ к которому может получить механизм OPA.

Как OPA работает с Kubernetes

OPA имеет встроенную интеграцию с Kubernetes, что позволяет легко развернуть и использовать OPA в среде Kubernetes. Существует несколько способов интеграции OPA с Kubernetes:

OPA с Gatekeeper

Одним из самых популярных способов является Gatekeeper. OPA Gatekeeper — это validating admission controller Kubernetes, который применяет политики к объектам Kubernetes при их создании или изменении. Когда пользователь или процесс пытается создать или изменить объект Kubernetes, OPA Gatekeeper перехватывает запрос и проверяет его на соответствие политикам, определенным в OPA. Если запрос нарушает политику, он отклоняется.

OPA с Service Mesh

Еще один способ использования OPA с Kubernetes — это использование Service Mesh, например Istio или Envoy. Service Mesh помогают нам управлять трафиком между различными сервисами, и мы можем использовать OPA для обеспечения безопасности этого трафика и соблюдения наших политик. Например, мы можем использовать OPA для блокировки трафика к сервису, который не имеет правильной авторизации, или для шифрования трафика между сервисами.

В этой статье рассмотрим пошаговую установку Gatekeeper.

Обзор OPA Gatekeeper

Как мы уже упоминали ранее, OPA Gatekeeper — это validating admission controller, который будет вызываться через веб-хук Kubernetes. Validating admission контроллеры используются для проверки того, разрешен ли ресурс Kubernetes набором правил или политик, прежде чем он будет создан или обновлен в реальной системе.

Установка OPA Gatekeeper

Для установки OPA gatekeeper требуется разрешение Cluster Admin. Поэтому необходимо создать роль и привязку ролей, чтобы предоставить доступ OPA gatekeeper ко всем ресурсам в Kubernetes.

Есть много способов установить OPA gatekeeper, мы можем использовать команду Helm следующим образом. Базовый charts/gatekeeper. Если у вас установлен Helm, вы можете развернуть его с помощью следующих инструкций для Helm v3.

$ helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts --force-update "gatekeeper" has been added to your repositories

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

helm install gatekeeper/gatekeeper --name-template=gatekeeper --namespace gatekeeper-system --create-namespace NAME: gatekeeper LAST DEPLOYED: Wed Mar 22 09:21:54 2023 NAMESPACE: gatekeeper-system STATUS: deployed REVISION: 1 TEST SUITE: None

Компоненты привратника OPA установлены в пространстве имен gatekeeper-system. Выполнив следующую команду, можно просмотреть информацию об установленных ресурсах.

$ kubectl -n gatekeeper-system get all                                                                        NAME                                                 READY   STATUS    RESTARTS      AGE pod/gatekeeper-audit-549bcc6775-z74gm                1/1     Running   1 (92s ago)   100s pod/gatekeeper-controller-manager-7785cd6b4c-j64zv   1/1     Running   0             100s pod/gatekeeper-controller-manager-7785cd6b4c-mcfv5   1/1     Running   0             100s pod/gatekeeper-controller-manager-7785cd6b4c-xr9kt   1/1     Running   0             100s  NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE service/gatekeeper-webhook-service   ClusterIP   10.96.120.252   <none>        443/TCP   100s  NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/gatekeeper-audit                1/1     1            1           100s deployment.apps/gatekeeper-controller-manager   3/3     3            3           100s  NAME                                                       DESIRED   CURRENT   READY   AGE replicaset.apps/gatekeeper-audit-549bcc6775                1         1         1       100s replicaset.apps/gatekeeper-controller-manager-7785cd6b4c   3         3         3       100s

OPA Gatekeeper Constraint Template

Ресурс ConstraintTemplate — это, по сути, шаблон для генерации ресурсов Constraint, которые являются фактическими объектами Kubernetes, обеспечивающими соблюдение политик, определенных в ConstraintTemplate. Ресурс ConstraintTemplate определяет код Rego, который будет использоваться для оценки объектов Kubernetes на соответствие набору политик, определенных в ConstraintTemplate.

Давайте создадим шаблон ConstraintTemplate, который будет блокировать все запросы на развертывание, в которых отсутствует наш частный реестр private.example.com

$ cat <<EOF | kubectl apply -f - apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata:   name: k8sallowedrepos spec:   crd:     spec:       names:         kind: K8sAllowedRepos       validation:         # Schema for the `parameters` field         openAPIV3Schema:           properties:             repos:               type: array               items:                 type: string   targets:     - target: admission.k8s.gatekeeper.sh       rego: |         package k8sallowedrepos          violation[{"msg": msg}] {           container := input.review.object.spec.containers[_]           satisfied := [good | repo = input.parameters.repos[_] ; good = contains(container.image, repo)]           not any(satisfied)           msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])         }          violation[{"msg": msg}] {           container := input.review.object.spec.initContainers[_]           satisfied := [good | repo = input.parameters.repos[_] ; good = contains(container.image, repo)]           not any(satisfied)           msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])         } EOF  $ constrainttemplate.templates.gatekeeper.sh/k8sallowedrepos created 

Если вы внимательно посмотрите, мы проверяем правильность имен образов репо в контейнерах regular & initContainer в полезной нагрузке запроса развертывания k8s.

package k8sallowedrepos  violation[{"msg": msg}] {   container := input.review.object.spec.containers[_]   satisfied := [good | repo = input.parameters.repos[_] ; good = contains(container.image, repo)]   not any(satisfied)   msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos]) }  violation[{"msg": msg}] {   container := input.review.object.spec.initContainers[_]   satisfied := [good | repo = input.parameters.repos[_] ; good = contains(container.image, repo)]   not any(satisfied)   msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos]) }

Ограничение OPA Gatekeeper

Ограничения можно рассматривать как шаблоны для объектов Kubernetes, которые обеспечивают соблюдение определенного набора политик. Каждое ограничение состоит из двух основных частей: spec и parameters. spec определяет набор политик, которые вы хотите применить к объектам Kubernetes, а раздел parameters позволяет передавать переменные, которые могут быть использованы в spec.

Мы создадим следующее ограничение (K8sAllowedRepos), чтобы сообщить Gatekeeper, что администратор хочет, чтобы вышеуказанный ConstraintTemplate применялся, и Gatekeeper будет применять и следить за тем, чтобы в системе Kubernetes были развернуты только допустимые репозитории образов.

$ cat <<EOF | kubectl apply -f - apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sAllowedRepos metadata:   name: allow-only-private-registry spec:   match:     kinds:       - apiGroups: [""]         kinds: ["Pod"]   parameters:     repos:       - "private.example.com" EOF  $ K8sAllowedRepos.constraints.gatekeeper.sh/allow-only-private-registry created

ПРИМЕЧАНИЕ: Нужно изменить private.example.com на имя нашего собственного Image registry host. Кроме того, в списке может быть более одного реестра.

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

$ cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata:   name: allowed-image-pod spec:   containers:     - name: allowed-image-pod       image: private.example.com/sample-api:tagname       resources:         limits:           cpu: "100m"           memory: "30Mi" EOF            pod/allowed-image-pod created

Под развернут, поэтому Gatekeeper не отказал нам в развертывании.

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

$ cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata:   name: deny-image-pod spec:   containers:     - name: deny-image-pod       image: docker.io/library/nginx:latest       resources:         limits:           cpu: "100m"           memory: "30Mi" EOF            Error from server (Forbidden): error when creating "STDIN": admission webhook "validation.gatekeeper.sh" denied the request: [allow-only-private-registry] container <deny-image-pod> has an invalid image repo <docker.io/library/nginx:latest>, allowed repos are ["private.example.com"]

Gatekeeper отклонил наши запросы на развертывание запрещенных образов.

Вот так мы можем создать множество политик с помощью Gatekeeper, чтобы обеспечить безопасность нашей системы Kubernetes.

Библиотека политик OPA Gatekeeper

OPA Gatekeeper Policy Library — это коллекция предварительно созданных политик, которые вы можете использовать с OPA Gatekeeper. Библиотека включает в себя политики для внедрения лучших практик безопасности, требований соответствия, квот на ресурсы и многое другое. Вы можете использовать эти политики как есть или настроить их под свои нужды.

Библиотека включает в себя набор каталогов, каждый из которых содержит набор политик, ориентированных на определенную область, например безопасность или соответствие нормативным требованиям. Каждая политика определяется в виде файла Rego, а каталог также содержит файл README с дополнительной информацией о политиках.

Заключение

Kubernetes — это мощный инструмент, который помогает нам управлять и развертывать программное обеспечение, но обеспечить безопасность и соответствие систем требованиям может быть непросто. Open Policy Agent (OPA) предоставляет мощное решение для внедрения политик и обеспечения безопасности наших систем. Используя OPA с Kubernetes, мы можем упростить применение политик, повысить безопасность и обеспечить соответствие нормативным требованиям.

Изучи Open Policy Agent (OPA) в Kubernetes в Слёрме за 10 000 ₽

Мы подробно изучаем Open Policy Agent в одном из модулей продвинутого курса Kubernetes: Мега. Теперь можно купить этот модуль отдельно за 10 000 ₽. Оформить его можно в самом конце этого лендинга.

В полной версии курса мы подробно разбираем ещё Network Policy, безопасность и высокодоступные приложения, ротацию сертификатов, аутентификацию пользователей в кластере, хранение секретов, Horisontal Pod Autoscaler, создание собственного оператора K8s, в общем, залезаем под капот Kubernetes. ? Полная программа.