Kubernetes став безумовно найпопулярнішою хмарною системою контейнерів. Так насправді це було лише питанням часу, поки не буде виявлений його перший серйозний недолік у безпеці.
Так і було, бо нещодавно Перший серйозний недолік безпеки в Kubernetes був випущений під CVE-2018-1002105, також відомий як помилка ескалації привілеїв.
Цей основний недолік Kubernetes є проблемою, оскільки він є критичним прорізом у безпеці CVSS 9.8. На випадок першого великого недоліку в безпеці Kubernetes.
Деталі помилок
За допомогою спеціально розробленої мережі запитів будь-який користувач може встановити з'єднання через з сервера інтерфейсу прикладного програмування (API) Kubernetes до внутрішнього сервера.
Після встановлення, зловмисник може надсилати довільні запити через мережеве підключення безпосередньо до цього серверного сервера в якому постійно метою є саме той сервер.
Ці запити автентифікуються за допомогою облікових даних TLS (Безпека транспортного рівня) з сервера Kubernetes API.
Гірше того, що в конфігурації за замовчуванням усі користувачі (автентифіковані чи ні) можуть запускати виклики виявлення API, які дозволяють ескалацію цих привілеїв зловмисником.
Тож, кожен, хто знає цю діру, може скористатися можливістю взяти на себе командування своїм скупченням Кубернетів.
На даний момент не існує простого способу виявити, чи використовувалася ця вразливість раніше.
Оскільки несанкціоновані запити надсилаються через встановлене з’єднання, вони не відображаються в журналах аудиту сервера Kubernetes API або журналі сервера.
Запити відображаються в журналах kubelet або на сукупному сервері API, але вони відрізняються від належним чином авторизованих та запитів проксі через сервер Kubernetes API.
Зловживання ця нова вразливість у Kubernetes це не залишило б очевидних слідів у журналах, тому тепер, коли помилка Kubernetes виявлена, це лише питання часу, поки вона не буде використана.
Іншими словами, Red Hat сказав:
Недолік ескалації привілеїв дозволяє будь-якому неавторизованому користувачеві отримати повні права адміністратора на будь-якому обчислювальному вузлі, запущеному в підсистемі Kubernetes.
Це не просто крадіжка чи відкриття для введення зловмисного коду, це також може зменшити службові додатки та виробництво в брандмауері організації.
Будь-яка програма, включаючи Kubernetes, є вразливою. Дистриб’ютори Kubernetes вже випускають виправлення.
Red Hat повідомляє, що це стосується всіх продуктів та послуг на базі Kubernetes, включаючи Red Hat OpenShift Container Platform, Red Hat OpenShift Online та Red Hat OpenShift Dedicated.
Red Hat почав надавати виправлення та оновлення послуг для постраждалих користувачів.
Наскільки відомо, ще ніхто не використовував порушення безпеки для нападу. Даррен Шепард, головний архітектор та співзасновник лабораторії Rancher, виявив помилку та повідомив про неї, використовуючи процес звітування про вразливість Kubernetes.
Як виправити цю несправність?
На щастя, виправлення цієї помилки вже випущено. В якому тільки їм пропонується виконати оновлення Kubernetes щоб вони могли вибрати деякі виправлені версії Kubernetes v1.10.11, v1.11.5, v1.12.3 та v1.13.0-RC.1.
Отже, якщо ви все ще використовуєте будь-яку з версій Kubernetes v1.0.x-1.9.x, рекомендується оновити до фіксованої версії.
Якщо з якихось причин вони не можуть оновити Kubernetes і вони хочуть зупинити цю невдачу, необхідно, щоб вони виконали наступний процес.
Вам слід припинити використання API агрегатів сервера або видалити дозволи pod exec / attach / portforward для користувачів, які не повинні мати повного доступу до API kubelet.
Джордан Ліггітт, інженер програмного забезпечення Google, який виправив цю помилку, сказав, що ці заходи, ймовірно, будуть шкідливими.
Тож єдиним реальним рішенням щодо цієї вади безпеки є виконання відповідного оновлення Kubernetes.