Написание первой OPA-политики Kubernetes с помощью Gatekeeper

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

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

В этой статье вы узнаете об установке Gatekeeper и настройке политик для вашего кластера Kubernetes.

Установка Gatekeeper

Сначала вам нужно установить Gatekeeper на ваш кластер Kubernetes. Для этого вы можете использовать Helm.

Добавьте репозиторий Gatekeeper.

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
Войдите в полноэкранный режим Выйдите из полноэкранного режима

Далее запустите установку.

helm install gatekeeper/gatekeeper --name-template=gatekeeper --namespace gatekeeper-system --create-namespace
Войти в полноэкранный режим Выйдите из полноэкранного режима

Вы должны увидеть результат, подобный приведенному ниже.

NAME: gatekeeper
LAST DEPLOYED: Thu Sep  8 12:36:20 2022
NAMESPACE: gatekeeper-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
Войти в полноэкранный режим Выход из полноэкранного режима

Выполнение конфигурации

После установки Gatekeeper вам нужно будет его настроить. Существует три типа конфигураций:

  • Конфигурация для самого Gatekeeper
  • шаблон
  • Реализация ограничений

Конфиг

Конфиг — это ваше определение того, для чего Gatekeeper разрешено создавать политики. Например, в config.yaml ниже, Gatekeeper знает, что он может определять политики только для стручков, но не для других ресурсов Kubernetes.

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: "gatekeeper-system"
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Pod"
Войти в полноэкранный режим Выход из полноэкранного режима

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

Например, если у вас есть Pods, запущенные на нескольких рабочих узлах, вам понадобится конфиг, чтобы Gatekeeper мог иметь доступ к Pods на всех рабочих узлах.

Шаблон ограничения

Constraint Template — это правило/политика, которую вы хотите настроить для вашей среды. Это шаблон, поэтому вы можете использовать его для нескольких ограничений.

Например, в шаблоне ограничений в этой директории есть политика Rego, которая гарантирует, что никто не сможет использовать тег latest образа контейнера.

Скопируйте приведенный ниже шаблон ограничений и добавьте его в YAML-файл. После завершения запустите kubectl apply -f на YAML-файле.

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: blocklatesttag
  annotations:
    description: Blocks container images from using the latest tag
spec:
  crd:
    spec:
      names:
        kind: blocklatesttag # this must be the same name as the name on metadata.name (line 4)
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package blocklatesttag
        violation[{"msg": msg, "details": {}}]{
        input.review.object.kind == "Pod"
        imagename := input.review.object.spec.containers[_].image
        endswith(imagename,"latest")
        msg := "Images with tag the tag "latest" is not allowed"
        }
Вход в полноэкранный режим Выход из полноэкранного режима

Конфигурация ограничения

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

Скопируйте приведенный ниже шаблон ограничения и добавьте его в YAML-файл. После завершения запустите kubectl apply -f на YAML-файле.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: blocklatesttag
metadata:
  name: nolatestcontainerimage
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    annotation: "no-latest-tag-used"
Вход в полноэкранный режим Выход из полноэкранного режима

Проверка конфигурации

Чтобы убедиться, что реализованная вами политика OPA работает, вы можете протестировать ее с помощью двух приведенных ниже манифестов Kubernetes.

Манифест с тегом latest не будет работать, потому что вы создали политику в предыдущем шаге, чтобы гарантировать, что теги latest не могут быть использованы. Сама установка будет развернута, но Pods не будут запущены.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginxdeployment
  replicas: 2
  template:
    metadata:
      labels:
        app: nginxdeployment
    spec:
      containers:
      - name: nginxdeployment
        image: nginx:latest
        ports:
        - containerPort: 80
Вход в полноэкранный режим Выйдите из полноэкранного режима

Приведенный ниже манифест будет работать, и Pods будут запущены, поскольку указан номер версии образа контейнера.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginxdeployment
  replicas: 2
  template:
    metadata:
      labels:
        app: nginxdeployment
    spec:
      containers:
      - name: nginxdeployment
        image: nginx:1.23.1
        ports:
        - containerPort: 80
Войти в полноэкранный режим Выход из полноэкранного режима

Поздравляем! Вы успешно настроили полную интеграцию OPA.

Оцените статью
devanswers.ru
Добавить комментарий