Volcano 1.15.2 закрив DoS-ризик у планувальнику Kubernetes

Volcano 1.15.2 виправляє вразливість GHSA-j38h-7pfq-cxmw у механізмі Dynamic Resource Allocation: авторизований орендар Kubernetes-кластера міг підібрати контрольовані значення кількості пристроїв або задач так, щоб облік доступної місткості виконував надмірну кількість ітерацій. Особлива небезпека полягала в тому, що розрахунок міг працювати під блокуванням scheduler cache. Один дорогий запит тоді впливав не лише на власну чергу, а й затримував планування інших workloads.

Чому це проблема всього кластера

Volcano розширює стандартні сценарії Kubernetes для batch, AI/HPC і пристроїв, де планувальник працює з PodGroups, пріоритетами та спеціалізованими ресурсами. У багатокористувацькому середовищі користувач із правом створювати допустимі workload-об’єкти не повинен мати можливості перетворити їхні параметри на непропорційно дороге обчислення в центральному scheduler.

За описом advisory, складність вразливого capacity accounting залежала від tenant-controlled counts. Якщо такий цикл запускається, поки утримується спільний lock, черга подій накопичується: нові pods довше залишаються Pending, рішення про preemption і reclaim запізнюються, а метрики scheduler latency ростуть навіть для інших namespaces. Це класичний availability-ризик без витоку даних чи зміни конфігурації.

Що змінили розробники

У 1.15.2 повторне додавання одиниць місткості замінене множенням зі сталою кількістю операцій. Додатково посилено перевірку вхідних значень і обробку переповнення. Тобто виправлення прибирає сам алгоритмічний важіль: велике число більше не повинно прямо перетворюватися на таку саму кількість проходів усередині критичної секції.

Advisory оцінює проблему у 6,5 бала CVSS 3.1: атака можлива мережею, має низьку складність, потребує низьких привілеїв і впливає на доступність. Уразливими названі Volcano 1.15.0 та 1.15.1, виправленою — 1.15.2. Командам на цих двох версіях не варто обмежуватися додатковим rate limit біля API: коректне усунення знаходиться в scheduler.

Інші виправлення релізу

• Прибрано nil-pointer panic у backfill, коли scoring вузлів не знаходить найкращого кандидата.
• Після попередніх reclaim-evictions повторно перевіряються predicates і доступність пристрою, щоб reclaim міг тривати до реального розміщення.
• Виправлено normal preemption для HAMi Ascend після звільнення достатньої device capacity.
• PodGroups залишаються у стані Running, поки вже заплановані pods коректно завершуються, без хибного NotEnoughResources.

Практичний висновок: для кластерів із Volcano 1.15.0–1.15.1 це безпекове, а не косметичне оновлення. Спочатку оновіть scheduler у staging, потім перевірте latency черги й сценарії DRA, backfill, reclaim та graceful termination.

План безпечного оновлення

Перед rollout зафіксуйте поточні p95/p99 scheduling latency, довжину pending queue, CPU scheduler pod і час утримання cache lock, якщо він доступний у вашій телеметрії. Після встановлення 1.15.2 програйте workload із великою кількістю device claims, але не робіть destructive stress-test у production. Окремо перевірте priority classes, PodGroups та jobs, які покладаються на reclaim.

Оновлення не скасовує багаторівневий захист. RBAC має обмежувати створення нестандартних resource claims, admission policies — відхиляти безглузді або непропорційні значення, а alerts — реагувати на раптовий ріст scheduler CPU і Pending pods. Ці заходи зменшують blast radius майбутніх алгоритмічних помилок, але не є заміною виправленій версії.

Обмеження

Release notes не повідомляють про витік конфіденційності або підвищення привілеїв, тому не варто перебільшувати характер проблеми. Водночас «Medium» не означає низьку операційну важливість: у спільному AI/HPC-кластері з дорогими чергами навіть коротка зупинка планування може мати значний вплив. Конкретний ризик залежить від того, чи ввімкнено DRA і які workload-об’єкти дозволені орендарям.

Джерело та права

Матеріал є самостійним українським перекладом-переказом release notes Volcano 1.15.2, опублікованих 29 серпня 2026 року JesseStutler та учасниками проєкту. Текст і код офіційного репозиторію поширюються за Apache License 2.0. Перекладено, адаптовано й доповнено редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI і не входить до першоджерела.