Контейнери в DevOps — це не нова концепція. Це віртуальні пісочниці з усіма необхідними інструментами для запуску мікросервісів, включаючи великі програми.
Ви можете розглядати контейнери як системи пакування, які дозволяють вам (як розробнику) централізовано зберігати все, що вам потрібно для запуску програми, наприклад, середовища виконання та двійкові коди.
Контейнери допомагають розробникам переміщувати програми з одного середовища в інше (наприклад, переміщувати програму з локальної машини у віртуальне середовище або переміщувати її з початкової стадії до робочої), усуваючи всі проблеми, пов’язані з різним програмним забезпеченням і параметрами конфігурації в розробниках і на виробництві. кінець.
Statista’s звіт про технологію контейнерів показує, що 50% організацій у світі запровадили оркестровку контейнерів. Незважаючи на те, що ця технологія отримала широке поширення завдяки своїм перевагам, контейнери можуть відкрити шлюз для атак на кібербезпеку, якщо їх не контролювати.
Деталі CVEквінтесенцією джерела даних про вразливості безпеки, зафіксовано 62 Уразливості Docker на момент написання цієї статті. Хіба це не потребує найкращих практик розробників, щоб усунути ці підводні камені та захистити контейнери для успішних процесів DevOps?
У цьому дописі розкривається концепція безпеки контейнерів, висвітлюються кілька проблем і вказуються найкращі методи використання контейнерної технології.
Що таке безпека контейнера?
Безпека контейнерів — це безперервний процес, який використовує протоколи безпеки (інструменти та політики) для захисту контейнерів та їхнього середовища від потенційних загроз.
Якщо зняти прапорець, загрози можуть завдати шкоди вашій програмі, її інфраструктурі, часу виконання, системним бібліотекам, операційній системі та ядру, серед інших функцій.
Враховуючи, що контейнери доступні в тимчасових режимах (на мить), а також призначені для динамічного розгортання та масштабування, існує потреба в автоматизованій безпеці на кожному етапі життєвого циклу розробки програмного забезпечення (SDLC).
Читайте також: Вступ до Kubernetes Kops для початківців
Які виклики виникають у сфері безпеки контейнерів?
Хоча контейнери мають багато винагород (наприклад, пришвидшення доставки програмного забезпечення), вони не захищені від проблем, головним чином тому, що їм потрібні заходи безпеки (їм бракує можливостей самозахисту).
Це тому, що контейнери отримують доступ до апаратного забезпечення через розміщену операційну систему (ОС). Це означає, що один контейнер може мати кілька базових зображень контейнера, що створює ширший простір для поверхонь атаки, створюючи деякі проблеми.
По-перше, це неправильна конфігурація контейнера, де розробники забувають налаштувати та використовувати конфігурації контейнера за замовчуванням, які мають деякі підводні камені, як-от деякі відкриті незахищені порти, які можуть бути не ідеальними для вашої програми, витік облікових даних, таких як паролі та маркери автентифікації, і надмірне надання дозволів середовище виконання контейнера (при запуску від імені root). Якщо ці конфігурації за замовчуванням не перевизначені, вони надають шляхи для атак.
Далі — вразливість контейнерної інфраструктури. Тут пакети, вбудовані в контейнер, як-от код програми, бібліотеки та конфігурації, або пакети в операційній системі хоста, представляють уразливості. Сприйнятливість може виникнути на будь-якій стадії життєвого циклу програми, наприклад, коли зовнішні залежності вбудовано в образ контейнера, бібліотеки з відкритим кодом встановлено як частину програми, базові образи контейнера надходять із сторонніх реєстрів контейнерів і хостів які можна використовувати через мережі та кінцеві точки.
Огляд робочих навантажень контейнерів є однією з найбільших проблем для контейнерів. Це пов’язано з дуже динамічною природою контейнерів, через що інструменти моніторингу не можуть визначити, які контейнери запущені, і перевірити їх поведінку в мережі. Покращена видимість запобігає порушенням і покращує час реагування на випадки, якщо вони трапляються.
Крім того, контейнер вразливий, якщо будь-яка фаза конвеєра CI/CD є незахищеною, або в коді програми, або в інфраструктурі робочого навантаження контейнера. Хоча розробники повинні піклуватися про безпеку наприкінці життєвого циклу програми, адміністрування її на кожному етапі розробки захищає ваші програми від цієї невдачі.
Які інструменти можуть вирішити проблеми безпеки контейнерів?
Ви можете переконатися, що розгорнуті корпоративні рішення безпечні, забезпечивши безпеку та цілісність контейнерів за допомогою засобів безпеки. Ці інструменти сканують уразливості та постійно перевіряють їх на наявність атак, помилок або будь-яких проблем.
Незалежно від того, чи шукаєте ви інструменти безпеки контейнерів з відкритим кодом або комерційного типу, усі вони слугуватимуть тій же меті. Усі вони працюють, перевіряючи вашу контейнерну інфраструктуру та перевіряючи загальні вразливості та ризики (CVE).
Ось кілька інструментів, які ви можете спробувати: Pingsafe Editors Choice, Datadog Cloud SIEM, Anchore, Sophos Cloud-Native Security, Bitdefender GravityZone, Sysdig secure, Aqua Security і RedHat Advanced Cluster Security для Kubernetes.
Читайте також: 11 сканерів безпеки контейнерів для пошуку вразливостей
Найкращі практики безпеки контейнерів
Незважаючи на описані вище проблеми безпеки контейнерів, ось розбивка найкращих угод, які можна застосувати для оптимізації безпеки контейнерів на всіх етапах життєвого циклу програми.
Захист ваших зображень
Ви використовуєте зображення контейнерів для створення контейнерів. Найменша неправильна конфігурація або зловмисні дії можуть спровокувати уразливості в контейнерах, що знаходяться в процесі виробництва. Ви можете протидіяти цьому:
- Використання надійних зображень. Якщо ви не створюєте зображення з нуля, ви завжди обираєте роботу із зображеннями з надійних джерел. Загальнодоступні сховища, як-от Docker Hub, містять зображення, зокрема зі зловмисним програмним забезпеченням і неправильною конфігурацією.
- Включення лише необхідних компонентів – якщо є компоненти, які не потрібні вашій програмі, краще їх видалити. Наприклад, система UNIX природно представляє двійкові файли «awk» і «sed».
- Включення вашої програми в образ контейнера – образ контейнера містить підмножину операційної системи (ОС) і запущену програму. Для кожного інструменту та бібліотеки, затягнутих у контейнер, це потенційна загроза. Щоб вирішити цю проблему, краще включити програму в зображення контейнера. Це робиться за допомогою статично скомпільованого двійкового файлу з усіма необхідними залежностями.
Автоматизація сканування на вразливість і керування
Регулярне сканування вразливостей і керування вашим контейнером і хостами допомагають виявляти вразливості на будь-якому етапі життєвого циклу програми.
У цьому випадку ви можете застосувати сканування коду для виявлення помилок і статичне тестування безпеки програми (SAST), щоб знайти вразливі місця в коді програми. Аналіз складу програмного забезпечення (SCA) може забезпечити видимість компонентів програмного забезпечення з відкритим вихідним кодом, створюючи специфіку програмного забезпечення, на яку можна порівняти задокументовані вразливості з відкритим кодом.
Крім того, сканування зображень аналізує вміст і процес створення зображення контейнера на чутливість. З такими інструментами, як Клер, ви можете сканувати відомі вразливості. Крім того, використовуйте динамічне тестування безпеки програми (DAST), яке вказує на ризики безпеки на основі поведінки контейнера. Інструменти DAST також можуть виконувати сканування хосту, під час якого ви перевіряєте компоненти хоста контейнера (ядро хоста та ОС) на наявність неправильної конфігурації.
Хоча вищезазначені заходи застосовуються в поточному процесі життєвого циклу контейнера, ви можете прийняти філософію «зрушення вліво». Це означає впровадження безпеки з самого початку життєвого циклу розробки. Хорошим інструментом, якщо ви виберете цей підхід, є Триви.
Захист реєстрів контейнерів
Реєстри контейнерів — це ефективний централізований спосіб зберігання та розповсюдження зображень. Часто організації мають тисячі зображень, які зберігаються в державних або приватних реєстрах. Є кілька заходів, які гарантують, що всі члени команди та співавтори використовують зображення без вразливостей.
По-перше, впровадження контролю доступу користувачів (для приватних реєстрів) визначає, хто може публікувати зображення та мати доступ до них. Хоча це основний захід безпеки, він запобігає публікації, зміні або видаленню ваших зображень неавторизованими особами.
Наступним заходом є підписування ваших зображень, що пов’язує кожне зображення з особою, яка його підписала, що ускладнює заміну скомпрометованого зображення. Ви можете використовувати Docker Content Trust методи додавання цифрових підписів до даних, які надсилаються та отримуються з реєстрів. Зрештою, пам’ятайте, що сканування ваших зображень (безперервне) допомагає виявити будь-які критичні вразливості.
Моніторинг контейнерів
Ви можете оптимізувати видимість робочих навантажень контейнерів за допомогою інструментів спостереження. Інструменти повинні мати можливість відстежувати та тестувати вразливості в усіх компонентах і забезпечувати реєстрацію подій у реальному часі для контейнерних середовищ.
Інструменти спостереження виявляють загрози, перевіряючи показники та журнали з усіх компонентів контейнерного стека та аналізуючи їх на наявність аномалій. Завдяки такому підходу ви можете негайно виправляти помилки конфігурації після їх виявлення.
Щоб зібрати показники використання ресурсів, використовуйте такі інструменти, як cAdvisor або kube-state-metrics. Для моніторингу активності контейнерів і продуктивності ваших кластерів використовуйте такі інструменти, як Grafana або Prometheus.
Якщо ви хочете проаналізувати мережевий трафік між контейнерами, використовуйте Wireshark або tcpdump. Якщо ви використовуєте керовану службу Kubernetes, наприклад (AKS), використовуйте Azure Monitor для відстеження ресурсів і загроз безпеці.
Крім того, Azure Log Analytics може збирати й аналізувати ваші ресурси AKS. Якщо ви обираєте Amazon EKS, Amazon CloudTrail добре підходить для реєстрації та перегляду; використовувати Amazon Cloud Watch.
Впровадження безпеки мережі
Заходи контролю безпеки мережі можуть допомогти захистити від несанкціонованого доступу до контейнера. Критерієм, який тут використовується, є сегментація мережі, яка ізолює контейнери, обмежуючи їх доступом лише до необхідних послуг.
Якщо ви використовуєте контейнерні програми на Kubernetes, ви можете використовувати мережеві політики K8s для налаштування вхідного та вихідного трафіку модулів у кластерах. Це, у свою чергу, обмежує трафік до певних пакетів на основі міток.
Безпеку транспортного рівня (TLS) можна розширити для зв’язку модулів. Для захищеного зв’язку між сервером API та іншими компонентами можна вибрати TLS або протокол захищених сокетів (SSL). Балансувальники навантаження є хорошим рішенням, якщо ви також хочете обмежити надходження трафіку до своїх кластерів.
Якщо ваші кластери мають мікросервіси, ви можете забезпечити безпечний трафік за допомогою сервісних інструментів mesh, таких як Meshery або Linkerd. Нарешті, захистіть свою мережу, якщо ви використовуєте хмарний продавець для розміщення своїх кластерів.
Якщо ви використовуєте службу Azure Kubernetes (AKS), використовуйте групи безпеки мережі (NSG) для керування трафіком. Якщо ви користуєтеся службою Amazon Elastic Kubernetes (EKS), найкраще підійдуть групи безпеки Amazon virtual private cloud (VPC).
Зменшення поверхневих атак
Мінімізація поверхні атак має дві переваги; збільшення швидкості обслуговування та зниження потенціалу порушень безпеки.
Використовуючи багатоетапну збірку, ви можете створювати легкі зображення з невеликою атакою на поверхню та покращеним часом завантаження та продуктивністю. Для цього є кілька рішень. Якщо ви використовуєте Linux, ви можете використовувати Alpine Linux, BusyBox або Tiny Core Linux.
Для Ubuntu є Ubuntu Minimal. Ви також можете використовувати Scratch, спеціальний образ Docker – по суті відкритий контейнер, щоб створити мінімалістичні зображення з самого початку.
Обмеження привілеїв контейнера
Застосований тут принцип передбачає надання мінімального дозволу для виконання певного завдання. Коли контейнери запускаються від імені root, вони надають користувачеві різні привілеї операцій, як-от інсталяція пакетів або повноваження операцій читання та запису у вашій операційній системі.
Ризик полягає в тому, що зловмисники можуть використати ескалацію потужності для середовища виконання контейнера, якщо його зламано. У цьому випадку є два життєздатних рішення. Ви можете запускати контейнери в режимі rootless або обмежити можливості ядра LINUX лише тими, що потрібні для робочого навантаження контейнера.
Безпечне керування секретами
Конфігураційні файли контейнера та докера не повинні містити секретів. Секрети включають сертифікати, паролі, ключі інтерфейсу прикладної програми (API) і маркери. І хоча це найкраща практика, ви часто побачите ці секрети, жорстко закодовані в процес збірки або зображення вихідного коду.
У таких випадках конфіденційні дані потрапляють у контейнери та кешуються на проміжних рівнях контейнерів, навіть якщо контейнери видалено. Для таких випадків найкращим підходом є розгортання рішення для керування секретами, наприклад Менеджер секретів AWS і Сховище зберігати секретні облікові дані та керувати ними.
Розширення можливостей вашої команди
Останній із заходів безпеки, навчання вашої команди найкращим практикам безпеки має вирішальне значення. Це означає, що всі гравці вашої команди можуть ідентифікувати загрози безпеці та реагувати на них.
Хороший спосіб реалізувати це — додати захист контейнерів до процесів адаптації вашої команди. Пропонуючи практичне навчання, постійне навчання та регулярні оцінки безпеки, ваша команда DevOps вирізняється, надаючи їй оновлені тенденції безпеки.
Заключні думки
Безпека контейнера є важливим безперервним процесом життєвого циклу розробки програмного забезпечення. Найкращий підхід до цього запиту полягає в інтеграції безпеки безпосередньо від коду програми до середовища виконання контейнера, операційної системи хоста та основної мережевої інфраструктури.
Ви можете реалізувати це, дотримуючись стратегічного плану, який передбачає перевірку контейнерів і використання лише тих, що надходять із надійних джерел. Виконайте зміцнення контейнерів, щоб переконатися, що в них є лише необхідні послуги. Впровадьте методи реєстрації, які легко застосовувати за допомогою інструментів моніторингу. Сегментуйте свою мережу так, щоб контейнери були відокремлені від загальної інфраструктури.
Завжди підписуйте свої зображення, щоб перевірити дані, введені та виведені через ваші служби. Крім того, вам слід проводити регулярне сканування та тести на проникнення, щоб перевіряти наявність уразливостей і негайно вживати заходів для виправлення. І в міру того, як технологічний ландшафт розвивається, завжди залишайтеся в курсі останніх методів безпеки.
Далі перевірте, як автоматизувати захист.
