Гайди

Безпека Kubernetes: 4 ефективні методи

CNCF повідомляє, що 96% організацій використовують Kubernetes. Це рекордний показник з початку їх щорічних опитувань у 2016 році. Водночас зростає і занепокоєння щодо безпеки Kubernetes. У своєму звіті Red Hat зазначає, що з 300 опитаних DevOps-фахівців:

55% відклали або уповільнили розгортання програми через проблеми безпеки k8s;
94% стикалися принаймні з одним інцидентом безпеки середовища Kubernetes за минулий рік;
59% повідомили своє занепокоєння щодо безпеки k8s і контейнерів.

Імовірно, ви знаєте про численні переваги Kubernetes. А от чи ви вмієте захищати цю систему? Зібрали для вас 4 ефективні методи безпеки, які допомагають нашим DevOps-фахівцям.

Що робимо ми 👇

[1] Використовуємо простір імен для ізоляції ресурсів Kubernetes

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

Примітка:

простір імен не потрібно створювати, якщо є кластери з невеликою кількістю юзерів (до 10);
для виробничого кластера не слід використовувати дефолтний простір імен.

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

Важливо:

імена ресурсів мають бути унікальними в межах одного і того ж простору імен;
кожен ресурс Kubernetes може знаходитись лише в одному просторі імен.

Задати простір імен можна за допомогою команди:

kubectl run nginx --image=nginx --namespace=<insert namespace>

kubectl — це утиліта командного рядка k8s. Тут ми використовуємо образ nginx із прапором –namespace для встановлення простору імен.

Далі слід звернутися до подів:

kubectl get pods --namespace=<insert namespace>

Якщо ви хочете вказати простір імен одразу для кількох команд, то слід ввести в консолі:

kubectl config set-context --current --namespace=<insert namespace>

Більше інформації про простори імен можете почитати тут.

[2] Захищаємо компоненти k8s

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

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

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

Ось ми створюємо простір імен, щоб обмежити пам’ять, ЦП та поди:

apiVersion: v1
metadata: compute-resources
spec:
pods: “6”
request.cpu: “1”
request.memory: 1Gi
limits.cpu: “4”
limits.memory: 4Gi

Тепер настав час розгорнути цей фрагмент в просторі імен:

kubectl create -f ./<resource-name> –<namesapc-name>

ТОП 6 опенсорсних інструментів безпеки Kubernetes знайдете тут.

[3] Постійно оновлюємо систему безпеки Kubernetes

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

Важливо: не варто встановлювати оновлення в продакшені, тому що воно може бути несумісне з пакетами ПЗ, що вже використовуються. Спочатку потрібно все добре протестувати в стейджингу і тільки потім викочувати в продакшен.

Для оновлення ми використовуємо команду:

apt- update

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

[4] Застосовуємо контекст безпеки до ресурсів k8s

У Kubernetes ми маємо файл deployment.yaml, який можемо використовувати для визначення контексту безпеки. Наприклад, ми визначаємо дозвіл для окремих програм, щоб вони мали доступ лише для читання.

За допомогою deployment.yaml ми можемо налаштувати модулі, контейнери, томи та привілеї. Якщо налаштуєте цей файл з особливою прискіпливістю, жоден зайвий користувач не зможе отримати доступ до цих ресурсів.

Щоб налаштувати цей файл, перейдіть до SecurityContext->runAsNonRoot. Тут слід вказати, що контейнер може працювати лише тоді, коли користувач не має права root.

Ось фрагмент поду для розуміння:

apiVersion: v1
metadata:
name: test
spec:
securityContext:
runAsNonRoot : True
readOnlyRootFilesystem : True

Висновок

Зараз все більше організацій переносять робочі навантаження у контейнери. Чи намагаються вони захистити Kubernetes? Сподіваємося, що так. Бо все може піти не так після кількох зламів і атак на систему.

Досвід наших DevOps-інженерів показує, що тільки інтеграція методів захисту в кожен етап життєвого циклу контейнерів дозволить компаніям бути впевненими у безпеці системи. Все тому, що k8s містить ресурси на різних рівнях, і ми повинні захищати кожен з них. Якщо на одному рівні виникне вразливість, то вся система буде під прицілом зловмисників.

Ми розповіли про ефективні методи безпеки, які щодня допомагають нашим DevOps-фахівцям. Пишіть у коментарях про практики, що використовуєте ви 👇

Запишіться на курс Адміністрування Kubernetes від IT Education Center, щоб стати гуру k8s. Програма містить лекційні та практичні заняття, що допоможуть вам освоїти усі тонкощі роботи з системою.