Безпека Kubernetes – це практики, інструменти та конфігурації, які захищають кластери та робочі навантаження Kubernetes від несанкціонованого доступу, вразливостей та загроз під час виконання. Вона передбачає захист усіх компонентів середовища Kubernetes, включаючи площину управління, робочі вузли, поди, образи контейнерів, мережі та сховища.
Kubernetes створює унікальну поверхню атаки. Її захист передбачає контроль доступу до сервера API, застосування політик автентифікації та авторизації, захист даних під час передачі та зберігання, а також моніторинг поведінки системи для виявлення аномалій.
Ефективна безпека Kubernetes також вимагає захисту ланцюжка постачання ПЗ, забезпечення найменших привілеїв для всіх користувачів і служб, а також впровадження механізмів захисту під час виконання. Оскільки Kubernetes керує ефемерними, динамічними контейнерними середовищами, стратегії безпеки повинні бути безперервними та адаптивними, охоплюючи етапи збірки, розгортання та продакшну. Це означає глибоку інтеграцію безпеки в пайплайни CI/CD, безперервне сканування робочих навантажень та автоматизацію застосування політик в інфраструктурі.
Чому безпека Kubernetes є такою важливою?
Останні дані підкреслюють гостру потребу вжиття надійних заходів безпеки Kubernetes:
- Затримки розгортання через проблеми безпеки. 67% організацій відклали або уповільнили розгортання додатків через проблеми безпеки у своїх середовищах Kubernetes.
- Вплив інцидентів безпеки на бізнес. 46% опитаних організацій зазнали втрат доходів або клієнтів через інциденти безпеки контейнерів і Kubernetes.
- Поширені інциденти безпеки. 58% організацій повідомили, що за останній рік стикалися з інцидентами безпеки, пов’язаними з контейнерами або Kubernetes, причому майже третина з них стикалася з декількома інцидентами.
- Підвищений ризик розкриття. 37% респондентів визнали, що їм довелося відкласти оновлення безпеки або виправлення через обмеженість ресурсів, що зробило кластери вразливими до відомих загроз.
- Неправильна конфігурація як основний ризик. Неправильна конфігурація залишається основною причиною інцидентів безпеки Kubernetes, про що зазначили понад половина респондентів, підкреслюючи важливість належного управління конфігурацією та дотримання політик.
Ці статистичні дані підкреслюють необхідність комплексних стратегій безпеки в середовищах Kubernetes для запобігання перебоям у роботі, фінансовим втратам та шкоді репутації.
Ризики безпеки Kubernetes та пайплайн DevOps
Інший спосіб більш конкретно розглянути безпеку Kubernetes з погляду розробника – це розглянути її на трьох окремих етапах пайплайну DevOps:
- Створення образу контейнера під час збірки
- Налаштування інфраструктури Kubernetes під час розгортання
- Захист мережевого зв’язку в процесі продакшну
Ризики безпеки Kubernetes на етапі збірки
Безпека Kubernetes починається на етапі збірки під час написання коду, який стає образом контейнера. Хоча Kubernetes не обов’язково бере участь у процесі збірки та пакування, безпечне середовище починається з оцінки ризиків, пов’язаних із будь-яким кодом, що розгортається. Тут важливими є найкращі практики безпеки додатків та тестування, а будь-які зусилля, спрямовані на shift left у безпеці, принесуть дивіденди, дозволивши уникнути майбутніх проблем під час розгортання та продакшну.
На цьому етапі необхідно переконатися, що образ контейнера є актуальним, не містить вразливостей безпеки та відповідає ліцензійним політикам компанії. Контейнери створюються пошарово й часто не мають канонічного списку компонентів з відкритим вихідним кодом, які були включені в остаточну збірку образу контейнера. Щоб виправити цю проблему, потрібно сканувати контейнери, щоб визначити, які бібліотеки з відкритим вихідним кодом використовуються в додатку, що охоплює перевірку всіх залежностей, які були додані через менеджера пакунків, такий як Maven або npm.
Виявляючи та ідентифікуючи всі компоненти з відкритим вихідним кодом, що використовуються, є можливість виявити всі відомі вразливості, визначити, які образи піддаються ризику в разі виявлення нових вразливостей, та відстежувати ліцензії, пов’язані з конкретними бібліотеками. Відстеження дотримання ліцензійних вимог може не становити ризику для безпеки, але може мати наслідки. Наприклад, розкриття пропрієтарного коду, якщо використана несумісна ліцензія.
Першим кроком до гарантування безпеки середовища Kubernetes є регулярне сканування базових образів.
Ризики безпеки Kubernetes під час розгортання
При розгортанні Kubernetes доступний потужний набір засобів контролю для захисту кластерів та їхніх додатків. Налаштування цих засобів контролю вимагає глибоких знань про Kubernetes, а також про вимоги безпеки розгортання. Не слід використовувати стандартні налаштування! Це призведе лише до непотрібного (а можливо, навіть недбалого) розкриття інформації. Як мінімум, потрібно обмежити обсяг дозволів користувачів, обмежити прямий доступ до вузлів Kubernetes і створити сегментацію мережі, щоб контейнери взаємодіяли тільки з тими контейнерами, з якими вони повинні.
На цьому етапі сканування залишається надзвичайно важливим. Образи контейнерів повинні бути зібрані з використанням безпечних базових образів. Необхідно впровадити постійне сканування вразливостей безпеки та регулярно застосовувати оновлення безпеки у середовищі. Сканування не є одноразовою подією. Крім того, під час запуску контейнерів у середовищі Kubernetes слід використовувати лише образи з реєстрів образів, що знаходяться у списках дозволених.
Ризики безпеки Kubernetes у продакшні
Безпека додатків під час виконання значно відрізняється від безпеки на етапі збірки. Зокрема, мережева безпека є складнішою. Найкращі практики мережевої безпеки в Kubernetes виходять за межі базової мережевої інфраструктури та використовують контейнерний мережевий інтерфейс (container network interface, CNI) для впровадження більш надійного мережевого рівня, що включає підтримку багатокористувацьких середовищ, мережеві політики або і те, і інше.
У багатокористувацькій мережі кожен простір імен у кластері Kubernetes отримує приватну адресовану підмережу і може отримувати доступ лише до подів в інших просторах імен, які спеціально відкриті як служби. Open vSwitch – чудовий приклад мережевого рівня для Kubernetes, що підтримує багатокористувацьку роботу.
Мережеві політики в більшості мережевих шарів нового покоління доступні для розгортання через Kubernetes. Project Calico є прикладом широко використовуваного мережевого шару, який був створений з нуля для підтримки мережевих політик з контейнерами. Мережеві політики дозволяють адміністраторам кластерів заздалегідь визначати списки контролю доступу до мережі, які контролюють, які порти є доступними й до яких служб можна отримати доступ.
10 найкращих практик безпеки Kubernetes
Ось найважливіші найкращі практики, які допоможуть поліпшити стан безпеки кластерів Kubernetes.
1. Сканування зображень
Сканування зображень є необхідним для виявлення вразливостей у контейнерних зображеннях перед їх розгортанням у виробничих середовищах. Сучасні контейнерні образи часто базуються на шарах програмного забезпечення з відкритим кодом, кожен з яких може містити вразливості. Такі платформи, як Mend, можна інтегрувати в CI/CD-пайплайни для автоматичного виявлення відомих CVE (Common Vulnerabilities and Exposures), застарілих пакунків, неправильних налаштувань і ризикованих ліцензій на програмне забезпечення. Таке сканування не повинно бути одноразовою діяльністю, а має бути частиною процесу безперервної інтеграції та доставки, щоб виявляти регресії та нововиявлені вразливості.
Окрім ризиків безпеки, сканування образів може допомогти забезпечити дотримання політик, гарантуючи, що у продакшн допускаються лише образи, створені на основі затверджених базових образів та з відомими компонентами. Підписи та атестації образів контейнерів можна використовувати для перевірки цілісності та походження образів, запобігаючи потраплянню в кластер підроблених або ненадійних образів. Ведення списку компонентів програмного забезпечення (SBOM) також забезпечує простежуваність, допомагаючи командам швидко оцінювати та зменшувати ризики, коли в залежностях верхнього рівня виявляються нові вразливості.
2. Введення контролю доступу на основі ролей (RBAC)
Контроль доступу на основі ролей (RBAC) – це функція Kubernetes, яка дозволяє адміністраторам визначати, які користувачі або служби можуть отримувати доступ до яких ресурсів і яким чином. Присвоюючи користувачам ролі на основі їхніх обов’язків і прив’язуючи ці ролі до конкретних просторів імен або ресурсів, зменшується ризик надмірних дозволів для облікових записів і мінімізується вплив скомпрометованих облікових даних. Стандартні ролі, такі як cluster-admin, слід використовувати з обережністю, а розробникам слід надавати мінімальний доступ, необхідний для виконання їхніх завдань.
Політики RBAC слід регулярно переглядати, особливо після змін у структурі команд, розгортаннях або інцидентах безпеки. Такі інструменти, як rbac-lookup, rakkess та Kubernetes Policy Controller, можуть допомогти візуалізувати та перевірити конфігурації RBAC. Поєднуючи RBAC з іншими механізмами контролю доступу, такими як ізоляція простору імен та мережеві політики, організації можуть побудувати стратегію глибокого захисту, яка значно посилить їхню безпеку в Kubernetes.
3. Використання автентифікації сторонніх розробників для API-сервера
Інтеграція Kubernetes із зовнішнім постачальником ідентифікації (IdP) за допомогою OpenID Connect (OIDC) дозволяє централізувати автентифікацію та покращити управління користувачами. Це спрощує впровадження політик безпеки, таких як багатофакторна автентифікація (MFA), єдиний вхід (SSO) та скасування доступу користувачів. Популярні IdP, такі як Okta, Auth0, Azure AD та Google Identity, забезпечують масштабоване управління ідентифікацією, що підтримує вимоги аудиту та відповідності.
Використання сторонньої автентифікації також усуває необхідність безпосередньо керувати обліковими даними користувачів у кластері, що зменшує ризик неправильного управління або розповсюдження облікових даних. При правильній інтеграції сервер API Kubernetes використовує токени, видані IdP, а політики RBAC можуть бути застосовані на основі членства в групі ідентичності. Це спрощує узгодження доступу до Kubernetes з корпоративними ІТ-стандартами та покращує відстежуваність дій користувачів за допомогою централізованих журналів.
4. Захист etcd за допомогою TLS і фаєрвола
База даних etcd є центральним сховищем усіх даних кластера, включаючи конфігурації, секретні дані та облікові дані. Несанкціонований доступ до etcd може призвести до повної компрометації кластера. Щоб захистити etcd, слід зашифрувати комунікацію за допомогою TLS і увімкнути автентифікацію клієнтів за допомогою сертифікатів. Це гарантує, що тільки довірені компоненти можуть взаємодіяти зі сховищем даних. Таким чином можна запобігти атакам man-in-the-middle або витоку даних.
Окрім шифрування, etcd слід ізолювати від мережі за допомогою фаєрволів або груп безпеки, щоб дозволити доступ тільки з сервера API Kubernetes. Варто уникати виставлення etcd у публічних мережах або ненадійних сегментах. Також дуже важливо увімкнути шифрування даних etcd у стані спокою та забезпечити регулярне створення та безпечне зберігання зашифрованих резервних копій. Періодичне тестування процесу відновлення також необхідне для забезпечення безперервності бізнесу у разі пошкодження або втрати даних.
5. Ізоляція вузлів Kubernetes
Ізоляція вузлів допомагає зменшити радіус ураження в разі інциденту безпеки. Використовуючи Kubernetes taints і tolerations, адміністратори можуть призначати конкретні робочі навантаження певним групам вузлів. Наприклад, робочі навантаження, що мають публічний доступ, можна планувати на вузлах без доступу до внутрішніх баз даних або API, що мінімізує ризики перехресного зараження. Аналогічно, чутливі робочі навантаження, такі як платіжні послуги, можна ізолювати від послуг загального призначення для підвищення безпеки.
Хмарні провайдери також пропонують такі механізми, як підмережі, VPC та групи безпеки, які можна використовувати для подальшої ізоляції груп вузлів. Вони можуть застосовувати правила фаєрвола, що запобігають несанкціонованому доступу між різними класами вузлів або між вузлами та Інтернетом. Впровадження ізоляції вузлів разом із сегментацією мережі та політиками сервісної сітки може забезпечити багаторівневу модель безпеки, стійку до розгалужених атак та підвищення привілеїв.
6. Моніторинг мережевого трафіку для обмеження комунікацій
За замовчуванням мережа Kubernetes дозволяє всім подам взаємодіяти між собою, що створює непотрібний ризик у разі компрометації. Впровадження мережевих політик Kubernetes обмежує комунікацію між подами, службами та неймспейсами. Політики можна застосовувати за допомогою плагінів CNI, таких як Calico, Cilium або Weave, які дозволяють адміністраторам визначати чіткі правила щодо того, які служби можуть взаємодіяти між собою.
Постійний моніторинг мережевого трафіку є необхідним для виявлення неправильних налаштувань, потенційних вторгнень або аномальної поведінки. Такі інструменти, як Istio, Linkerd або комерційні service mesh-рішення, пропонують функції спостереження, такі як відстеження трафіку, показники затримки та реєстрація доступу. Ці інструменти можуть допомогти вам точно налаштувати політики та швидко виявляти порушення безпеки, що дозволяє командам реагувати, перш ніж зловмисники проникнуть глибше в кластер.
7. Використання списку дозволених процесів
Список дозволених процесів обмежує контейнери лише певними, заздалегідь визначеними програмами або системними викликами. Це обмежує можливості зловмисника щодо використання контейнера, навіть якщо він скомпрометований. Такі технології, як AppArmor, Seccomp і SELinux, дозволяють адміністраторам визначати ці обмеження у вигляді політик або профілів. Наприклад, профіль Seccomp може блокувати використання певних системних викликів Linux, значно зменшуючи площу атаки контейнера.
Забезпечення дотримання вимог на рівні процесів допомагає запобігти зловживанню контейнерними середовищами для таких дій, як майнінг криптовалют, запуск зворотних оболонок або підвищення привілеїв. На відміну від традиційних антивірусних програм або засобів виявлення кінцевих точок, ці механізми на рівні ядра працюють з мінімальним впливом на продуктивність і є дуже ефективними в середовищах з обмеженими ресурсами, таких як контейнери.
8. Увімкнення аудиторського журналювання
Аудиторське журналювання в Kubernetes реєструє всі взаємодії з API-сервером, забезпечуючи видимість того, хто отримав доступ до яких ресурсів і які дії були виконані. Це має вирішальне значення для аналізу інцидентів, реагування на інциденти та дотримання вимог відповідності, таких як HIPAA або PCI DSS. Аудиторські журнали можна налаштувати так, щоб вони включали такі події, як читання, запис або відмова в доступі, і фільтрувати їх за неймспейсами, ролями користувачів або типами ресурсів.
Журнали повинні збиратися та зберігатися в безпечній, централізованій системі. Це дозволяє здійснювати кореляцію журналів, виявлення загроз та довгострокове архівування. Регулярний перегляд журналів аудиту може допомогти виявити підозрілу поведінку, таку як спроби підвищення привілеїв або несанкціонований доступ до конфіденційних ресурсів, і є ключовим компонентом будь-якої проактивної стратегії моніторингу безпеки.
9. Оновлення версії Kubernetes
Кожна версія Kubernetes містить виправлення відомих вразливостей та поліпшення функцій безпеки. Використання застарілих версій наражає кластер на ризики, про які знають зловмисники і які вони активно використовують. Kubernetes підтримує швидкий цикл випуску оновлень, і організації повинні дотримуватися структурованого процесу оновлення, щоб залишатися в курсі останніх змін, мінімізуючи час простою та перебої в роботі.
Перед оновленням слід завжди тестувати нові версії в тестовому середовищі, щоб виявити проблеми сумісності з робочими навантаженнями або інтеграціями сторонніх розробників. Можна використовувати такі інструменти, як kubeadm, або покладатися на керовані служби, які автоматизують частину процесу оновлення. Бути в курсі останніх змін також означає стежити за застарілими API та змінами в стандартній поведінці, які можуть вплинути на продуктивність або доступність додатків, якщо їх не виправити.
10. Блокування kubelet
Kubelet – це потужний компонент, який керує операціями життєвого циклу поду на кожному вузлі. Він надає REST API, який може бути використаний зловмисниками, якщо не забезпечити належний захист. За замовчуванням kubelet дозволяє доступ до кінцевих точок /exec, /logs та /metrics, які можуть бути використані для перегляду журналів або введення команд у запущені контейнери. Вимкнення анонімного доступу та увімкнення автентифікації та авторизації – це найважливіші перші кроки для блокування kubelet.
Крім того, варто обмежити доступ до API kubelet, прив’язавши його до 127.0.0.1 або захистивши фаєрволом. Потрібно уникати використання прапорців з надмірними дозволами, таких як –read-only-port, і регулярно перевіряти конфігурації kubelet. Також рекомендується ввімкнути налаштування безпеки kubelet, такі як –tls-cert-file, –authentication-token-webhook і –authorization-mode=Webhook, щоб забезпечити перевірку ідентичності та контроль доступу для вхідних запитів.
Покращення безпеки Kubernetes за допомогою Mend.io
Гарантія безпеки розгорнутих у Kubernetes додатків вимагає комплексного підходу, який ефективно використовує безпеку контейнерів у всьому циклі розробки програмного забезпечення (SDLC). Інтеграція Mend.io з Kubernetes забезпечує видимість потенційних ризиків шляхом сканування вразливостей в образах контейнерів:
- Доступність контейнерів визначає, які вразливі файли та методи викликаються під час виконання без необхідності використання агентів виконання, що дозволяє безпечно знизити пріоритет більш недоступних вразливостей.
- Безпека від розробки до розгортання забезпечує захист протягом усього життєвого циклу розробки програмного забезпечення. Вона починається зі сканування статичних образів у пайплайні та продовжується аналізом поведінки контейнерів на предмет ризиків безпеки під час виконання.
- Виявлення “секретів” ідентифікує відкриті облікові дані, паролі, ключі та сертифікати в образі, задовольняючи критичну потребу в захисті конфіденційних даних.
- Сканування кластерів Kubernetes без зусиль сканує всі запущені образи контейнерів у кластерах Kubernetes. Таким чином полегшується пошук і маркування контейнерів, які активно використовуються та розгорнуті.
