Принципи Open Policy Agent. Практичне використання у Kubernetes
Привіт! Мене звати Анатолій Калюжний, я 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, без можливості обійти ці обмеження. А також убезпечити кластер від неправильної та необережної взаємодії з ним.
2 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів