Kubernetes надзвичайно популярний, але без належних заходів безпеки він також пов’язаний з ризиками. Експерт із безпеки CyberArk називає три конкретні ризики та показує, які захисні заходи потрібні, щоб контролювати ризики обладнання, сервера API та контейнера в Kubernetes.
У розробці програмного забезпечення сьогодні швидкість і гнучкість є ключовими. Контейнерна технологія використовується все ширше. Kubernetes став стандартом де-факто для керування контейнерними навантаженнями та службами.
Аспекти безпеки Kubernetes
З точки зору безпеки, платформа оркестровки Kubernetes несе з собою певні проблеми, пов’язані з ідентифікацією, які потрібно вирішити на ранніх стадіях процесу розробки. Інакше контейнерні середовища можуть становити загрозу для ІТ-безпеки. Є три основні потенційно вразливі області Kubernetes, на яких організації повинні зосередитися в рамках справжнього підходу DevSecOps.
Ризик Kubernetes: апаратне забезпечення
Незалежно від того, чи працює Kubernetes локально чи в сторонній керованій хмарі, апаратна платформа все одно потрібна. Коли зловмисник отримує доступ до віртуальної машини, на якій працює Kubernetes, і права root, він також може атакувати кластери Kubernetes.
Щоб запобігти цьому, існують такі найкращі методи безпеки:
- Дотримання принципу найменших привілеїв має вирішальне значення для захисту апаратного забезпечення, яке лежить в основі як Kubernetes, так і самих контейнерів. Віртуальні машини слід розгортати з найнижчим рівнем привілеїв (тобто лише з тими, які суворо необхідні з функціональних причин), щоб ускладнити зловмисникам отримання кореневого доступу.
- Облікові дані потрібно регулярно змінювати, і використання автоматизованого рішення для сховища має сенс для подальшого підвищення захисту без збільшення накладних витрат.
Ризик Kubernetes: сервер API Kubernetes
Окрім фізичних машин, площину керування Kubernetes також потрібно захистити. Він надає доступ до всіх контейнерів, що працюють у кластері, включаючи сервер Kubernetes API, який діє як інтерфейс і полегшує взаємодію користувачів у кластері.
Атака на сервер API може мати великий вплив. Навіть один викрадений секрет або облікові дані можуть бути використані для підвищення прав доступу та привілеїв зловмисника. Спочатку невелика вразливість може швидко перерости в проблему всієї мережі.
Передові методи безпеки включають:
- Щоб зменшити ризик, організації повинні спочатку захистити кінцеві точки від крадіжки облікових даних і загроз зловмисного програмного забезпечення. Особливо актуальні локальні комп’ютери, якими користуються користувачі з правами адміністратора в Kubernetes.
- Багатофакторна автентифікація (MFA) для доступу до серверів Kubernetes API є важливою. Наприклад, викрадені облікові дані не можна використовувати для доступу до Kubernetes.
- Після автентифікації користувачів у Kubernetes вони можуть отримати доступ до всіх ресурсів кластера. Тому управління авторизаціями має вирішальне значення. Завдяки контролю доступу на основі ролей компанія може гарантувати, що користувачі мають лише ті права доступу, які їм дійсно потрібні.
- Мінімальні привілеї також повинні застосовуватися для облікових записів служби Kubernetes, які автоматично створюються під час налаштування кластера, щоб допомогти автентифікувати модулі. Не менш важливо регулярно змінювати секрети, щоб усунути можливості доступу для тих, кому вони більше не потрібні.
Ризик Kubernetes: контейнери
Поди та контейнери є будівельними блоками кластера Kubernetes і містять інформацію, необхідну для запуску програми. У цій контейнерній екосистемі та робочому процесі є кілька потенційних вразливостей. До них відноситься, наприклад, незахищений доступ до API контейнера або до хосту контейнера та незахищених реєстрів зображень.
Для безпеки контейнерів рекомендовано дотримуватись таких найкращих практик:
- Секрети не можна вбудовувати в код або в зображення контейнера. В іншому випадку кожен, хто має доступ до вихідного коду, також має доступ до інформації в сховищах коду, наприклад.
- Ризики безпеки значно мінімізовані завдяки контролю доступу на основі ролей, обмеженню секретного доступу до процесів у певному контейнері та видаленню секретів, які більше не потрібні.
- Секретне використання, включаючи ротацію або дезактивацію, має реєструватися. Перевагою також є рішення для централізованого керування секретами, яке забезпечує автоматичне адміністрування та захист конфіденційних даних доступу.
«Застосовуючи ці найкращі практики, компанія може значно покращити безпеку в усьому середовищі Kubernetes», — сказав Майкл Клейст, регіональний віце-президент DACH у CyberArk. «Крім того, існує також можливість підтримки розробників функціями самообслуговування в їхній повсякденній роботі, наприклад, щодо сканування коду. Це дозволяє їм зробити подальший внесок у підвищення безпеки Kubernetes швидко та зручно».
Більше на CyberArk.com
Про CyberArk
CyberArk є світовим лідером у сфері захисту ідентифікаційних даних. Завдяки керуванню привілейованим доступом як основному компоненту CyberArk забезпечує комплексну безпеку для будь-якої ідентифікаційної інформації – людини чи не людини – у бізнес-додатках, розподілених робочих середовищах, гібридних хмарних робочих навантаженнях і життєвих циклах DevOps.