Новий випуск 1.13 Kubernetes Container Platform видаляє критичну вразливість (CVE-2018-1002105), що дозволяє будь-якому користувачеві отримати повний контроль над групою ізольованих контейнерів. Проблема також була виправлена в оновленнях 1.10.11, 1.11.5 та 1.12.3.
У вразливості, виявленій у Kubernetes, для здійснення атаки достатньо надіслати спеціально розроблений запит через API для визначення доступних бэкэндів (запит на виявлення).
Про вразливість Kubernetes
Через помилку цей тип запиту залишає мережеве підключення відкритим, що дозволяє використовувати API сервера (kube-apiserver) як посередник для надсилання запитів на будь-який сервер за допомогою з'єднання, встановленого із сервером API.
Отже, запити, переадресовані за такими з'єднаннями, будуть оброблятись серверною інформацією як внутрішні запити сервера API, надіслані за допомогою параметрів автентифікації сервера API.
За замовчуванням, всі автентифіковані та неаутентифіковані користувачі Kubernetes мають можливість надсилати запити через API виявлення, яких достатньо для запуску атаки.
Тому будь-який непривілейований користувач Kubernetes, який має доступ до API, може отримати повний контроль над усією інфраструктурою, наприклад, надіславши запит на запуск свого коду на хості.
На додаток до отримання контролю над інфраструктурою Kubernetes, вразливість може також застосовуватися до атак, націлених на клієнтів, через маніпуляції з послугами для клієнтів, розташованими у хмарі.
Проблема виникає у всіх версіях Kubernetes, починаючи з версії 1.0.
Тому всім адміністраторам Kubernetes пропонується терміново оновити свої системи до поточних проблем, а також перевірити системні журнали на предмет потенційної шкідливої діяльності.
Як рішення для захисту від атак несанкціонованих користувачів вони можуть вимкнути анонімний доступ до API за допомогою опції «–anonymous-auth = false» та відкликати права на виконання операцій exec / attach / portforward.
Окремо зазначається, що в журналах Kubernetes атака з використанням несанкціонованих запитів взагалі не реєструється, тому можна було визначити, чи можливий компроміс лише за непрямими ознаками.
Про новий випуск Kubernetes 1.13 та новинки
У цьому новому випуску Kubernetes 1.13 Інтерфейс CSI (контейнерний інтерфейс зберігання даних) стабілізований, що дозволяє створювати плагіни для підтримки декількох систем зберігання.
CSI забезпечує єдиний інтерфейс для розподілу простору, приєднання та монтування сховищ, що дозволяє надавати плагіни для інтеграції з різними службами зберігання без необхідності внесення змін до кодової бази Kubernetes.
За замовчуванням використовується сервер DNS CoreDNS.
CoreDNS написаний мовою Go і має гнучку архітектуру на основі плагінів.
Наприклад, конкретні функції, такі як виявлення послуги Kubernetes, накопичення метрик для системи моніторингу Prometheus та інтеграція із системою зберігання конфігурації тощо. вони реалізовані за допомогою плагінів.
Kubeadm було стабілізовано як спрощений інтерфейс для управління кластером Kubernetes, що дозволяє виконувати такі операції, як створення та розгортання кластера на існуючій машині, налаштування основних компонентів Kubernete, підключення та видалення вузлів, виконання операцій оновлення;
Представлений експериментальний інтерфейс для створення плагінів для інтеграції зі сторонніми системами моніторингу.
Реєстр плагінів пристроїв Kubelet, стабілізований службою, який надає засоби доступу до Kubelet із плагінів.
Планувальник розподілу контейнерів TAVS (Topology Aware Volume Scheduling) стабілізувався з урахуванням топології розділів стручків (з урахуванням обмежень, встановлених для вузлів і зон).
Ми перейшли до етапу бета-тестування APIServer DryRun, команди Kubectl Diff та можливості використовувати пристрої необроблених блоків як постійні джерела даних (постійне джерело томів).
Якщо ви хочете дізнатись трохи більше про цей новий випуск може відвідайте наступне посилання.