Принципи Open Policy Agent. Практичне використання у Kubernetes

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Анатолій Калюжний, я DevOps Engineer у харківському офісі SoftServe та лід локального DevOps Community. Зараз веду два проєкти, в яких широко використовується 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. І тут я раджу відразу собі додати закладку playground для rego.

Без цього інструменту зрозуміти, чому не спрацювала та чи інша політика, буде досить складно, а тут можна підсвічувати виконані інструкції та дивитися на результат виконання вашої політики у реальному часі.

Розглянемо принцип встановлення політик. Будь-яка політика буде складається з шаблону — набору правил (на rego) і ресурсу самої політики зі змінними, на підставі яких і буде визначатися, як сама політика реагуватиме на конкретно ваш кластер і на ваші запити до нас. Тобто коли ви пишете саму політику, ви відштовхуватиметеся від змінних, які потім зможете задати, виходячи з вимог щодо проекту до конкретного кластера.

Розбираємося в політиках

Під час реального користування такого інструмента, який буквально змушує інженерів використовувати найкращі практики світу, немає й шансу не використати їх. Політика наче говорить зробити все як треба з першого разу. І це окрім того, що різними політиками можна контролювати безпеку кластера з одного місця, що зручно, коли кластером користується більш ніж одна команда і не має можливості проконтролювати, що робить кожна.

З політик, що ми використовували на проєкті:

• gatekeeper-library. Зобов’язує вказувати ліміти CPU і пам’яті, а також можна встановити свій максимальний ліміт для цього.
• allowedrepos. Вказує, з яких репозиторіїв можна брати docker image для кластера (в ідеалі, залишити лише свій внутрішній репозиторій, і всі image брати саме з нього).
• requiredannotations. Зобов’язує мати конкретні анотації для ресурсів.
• requiredlabels. Те саме, тільки для лейблів.
• privileged-containers. Не дає запускати контейнери у privileged mode (можна вказати винятки).

Вказавши лише ці політики, вже досить серйозно можна покращити безпеку вашого кластера.

Висновки

У цілому, сам інструмент, при належному вмінні та налаштуванні, дуже підійде для використання як одного з компонентів безпеки вашої інфраструктури в кооперації з іншими інструментами. OPA дозволяє вам примусово змусити інженерів використовувати найкращі практики управління та використання Kubernetes, без можливості обійти ці обмеження. А також убезпечити кластер від неправильної та необережної взаємодії з ним.