Open Policy Agent (OPA) — что это такое и как использовать, знает достаточно мало специалистов, хотя это классный инструмент, чтобы иметь лучшую защиту и контроль за создаваемыми ресурсами. Поэтому в статье хотели бы поделиться как теорией, так и рассказать, как настраивать Open Policy Agent.
Эта тема будет особенно полезна для специалистов, работающих в проекте, где есть слоеные кластеры Kubernetes, любому инженеру, интересующемуся темой безопасности, а также в ситуациях, когда клиент стремится к большему контролю над кластерами.
Что такое Open Policy Agent
Хотелось бы начать с объяснения, а что же за зверь такой – этот Open Policy Agent (OPA). Его задача достаточно утилитарна и проста – заставить пользователя выполнять политики, заложенные администратором. Политики могут быть любыми — бизнес, техническими, административными или какими вы их придумаете. Сам инструмент не ограничивает его использование никоим образом.
Пример, который используют сами разработчики OPA: есть служащий банка, имеющий доступ к базе данных всех банковских аккаунтов, и мы хотим ограничить его возможность открывать детали аккаунтов. Так, чтобы он имел доступ только если есть открытый запрос от клиента, выполняемого этим сотрудником банка. Это не позволит неконтролируемо открывать аккаунты пользователей, даже учитывая, что у сотрудника есть доступ к базе всех аккаунтов. Соответственно это улучшает безопасность и снижает риски.
То есть OPA регламентирует, как и когда тот или иной ресурс может запрашиваться. Как же это касается Kubernetes и вообще DevOps? Оказывается, можно так же регламентировать и развертывание в Kubernetes. Например, не позволяя создавать Deployment’ы, в image-поле в Pod’е которых указан репозиторий не из разрешенного списка. Схема работы самого сервиса достаточно проста: запрос через поступающий webhook перехватывается OPA запрос (должен быть обязательно в JSON), обрабатывается в соответствии с политикой и выдается решение — разрешить такой запрос или отклонить. Можно также указать причину отклонения запроса, чтобы дать больше информации о причине отказа.
Схема работы OPA
Есть три версии OPA, однако две из них уже устарели, и одна – текущая. В старых версиях OPA в качестве основного хранилища для политик использовались ConfigMap, в которой прописывались как сами политики, так и данные, из которых формируется ответ на запрос. Это было удобно использовать, но прогресс не стоит на месте. Поэтому в новой, третьей версии, от этой практики отошли в пользу более прогрессивной модели – Custom Resource Definition. В ней как тип ресурса выступает шаблон политики, а как сам ресурс — конкретные данные о политике, формирующих саму политику.
Опыт реального использования
OPA на практике я использовал для стартапа из blockchain NFT. Задача была внедрить стандарты по использованию общих ресурсов, в частности, Kubernetes кластера. Да, с ОРА у нас появилось больше контроля за ними.
В целом, такие нововведения спокойно восприняли и другие команды по проекту. Но как раз во время внедрения ОРА вылезли проблемы, которые как раз не доходили руки починить из-за нехватки времени. Однако здесь уже не было другого выбора, кроме как фиксировать, потому что не смогли бы внедрить ОРА.
Как установить и настроить OPA
Установить OPA можно как с помощью helm chart’а, так и через манифесты. Лично я рекомендую использовать helm. Официальный chart доступен по ссылке .
Устанавливаем как обычный chart и не выделяем отдельный namespace под менеджер:
kubectl create namespace gatekeeper-system
После этого ставим сам chart:
helm repo add opa https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper opa/gatekeeper -n gatekeeper-system
Самое главное в работе с OPA – это тонкая настройка политик. Они пишутся на специальном языке — rego. Сама речь – это набор правил и функций (для упрощения и пере использования) для определения запретов и разрешений. Вы можете сделать как разрешительные правила, так и запретительные. Проще всего использовать один тип правил по умолчанию (если не запрещено — разрешено или наоборот). К счастью, существует достаточно большая библиотека правил , написанных самими разработчиками OPA. Там достаточно исчерпывающий список политик, которые можно применить в том или ином случае. Если же вам необходимо создать какую-нибудь политику с нуля, а такой политики в библиотеке не нашлось, то вам придется узнать все прелести rego. И тут я советую сразу себе добавить закладку play.openpolicyagent.org для rego.
Без этого инструмента понять, почему не сработала та или иная политика, будет сложно, а здесь можно подсвечивать выполненные инструкции и смотреть на результат выполнения вашей политики в реальном времени.
Рассмотрим принцип установления политик. Любая политика будет состоять из шаблона – набора правил (на rego) и ресурса самой политики с переменными, на основании которых и будет определяться, как сама политика будет реагировать на конкретно ваш кластер и на ваши запросы к нам. То есть, когда вы пишете саму политику, вы будете отталкиваться от переменных, которые потом сможете задать, исходя из требований по проекту к конкретному кластеру.
Разбираемся в политиках
Во время реального использования такого инструмента, который заставляет инженеров использовать лучшие практики мира, нет и шанса не использовать их. Политика будто говорит сделать все как следует с первого раза. И это кроме того, что разными политиками можно контролировать безопасность кластера с одного места, что удобно, когда кластером пользуется более одной команды и не имеет возможности проконтролировать, что делает каждая.
Из политик, которые мы использовали на проекте:
- gatekeeper-library . Обязательство указывать лимиты CPU и памяти, а также можно установить свой максимальный лимит для этого.
- allowedrepos . Указывает, из каких репозиториев можно брать docker image для кластера (в идеале, оставить только свой внутренний репозиторий, и все image брать именно из него).
- requiredannotations . Обязывает иметь конкретные инструкции для ресурсов.
- requiredlabels . То же, только для лейблов.
- privileged-containers . Не дает запускать контейнеры в privileged mode (можно указать исключения).
Указав только эти политики, достаточно серьезно можно улучшить безопасность вашего кластера.
Выводы
В целом сам инструмент, при надлежащем умении и настройке, очень подойдет для использования в качестве одного из компонентов безопасности вашей инфраструктуры в кооперации с другими инструментами. OPA позволяет вам принудительно заставить инженеров использовать лучшие практики управления и использования Kubernetes без возможности обойти эти ограничения. А также обезопасить кластер от неправильного и неосторожного взаимодействия с ним.