Kubernetes v1.33: нові налаштування користувацьких просторів для підвищення безпеки

З виходом Kubernetes v1.33, простори користувачів більше не є альфа- або бета-функцією — вони увімкнені за замовчуванням на будь-якому вузлі, що відповідає вимогам стеку. Цей важливий крок значно спрощує забезпечення кращої ізоляції для багатокористувацьких середовищ та дотримання принципу найменших привілеїв у сучасних контейнеризованих системах. У цій розширеній статті ми розглянемо, що таке простори користувачів, чому вони важливі, відповімо на поширені операційні запитання, а також розглянемо показники продуктивності, інтеграцію політик і майбутні плани.

Що таке простір користувачів?

Простори користувачів у Linux (man 7 user_namespaces) дозволяють процесу та його дочірнім процесам бачити інший набір UID/GID, ніж на хості. Kubernetes вже використовує простори мережі, PID, монтування, IPC та UTS для ізоляції подів. Простори користувачів доповнюють цю картину, відображаючи внутрішній корінь контейнера (UID 0) на не привілейований діапазон UID хоста (наприклад, 1 000 000–1 000 65535). Це перенаправлення заважає втечі процесів отримувати привілеї на рівні хоста.

• Запобігання бічному руху: Кожен под отримує унікальний піддіапазон UID/GID. Якщо Под A вийде за межі, його перенаправлені UID не перетинаються з UID Поду B, тому атаки на файли та процеси обмежуються світовими дозволами.
• Підвищена ізоляція хоста: Корінь у контейнері відповідає непривабливому UID на вузлі. Ядерні можливості (CAP_SYS_ADMIN тощо), надані всередині простору, не застосовуються за його межами.
• Нові безпечні випадки використання: Непривабливі вкладені контейнери (Docker-in-Docker), образи збірників, які вимагають CAP_NET_ADMIN, або монтування пристроїв зворотного зв’язку стають безпечними за замовчуванням.

Як увімкнути простори користувачів

Увімкнення тепер є простим: достатньо вказати spec.hostUsers: false у специфікації вашого пода. Немає потреби у функціональних воротах у v1.33+.

apiVersion: v1
kind: Pod
metadata:
  name: userns-demo
spec:
  hostUsers: false          # відображає корінь контейнера на непривабливий UID на хості
  containers:
  - name: app
    image: alpine
    command: ["sleep","infinity"]

Усі UID/GID всередині контейнера автоматично перенаправляються на окремий піддіапазон хоста. Якщо ваш робочий навантаження дійсно вимагає привілеїв кореня хоста — наприклад, для завантаження модуля ядра — ви повинні запустити з hostUsers: true або пропустити це поле (за замовчуванням використовуючи UID хоста).

Монтування idmap та підтримка файлових систем

Монтування idmap (через mount_setattr(MOUNT_ATTR_IDMAP)) дозволяє файловій системі динамічно переводити операції вводу-виводу UID/GID на льоту на основі активної карти простору користувачів. Це критично важливо для постійних томів, ConfigMaps, секретів і будь-яких томів hostPath або CSI.

• Динамічне увімкнення/вимкнення: Змінюйте простори користувачів без ручного chown вмісту томів.
• Змішаний режим доступу: Поди з і без просторів користувачів можуть отримувати доступ до одного й того ж hostPath або NFS-монту (якщо підтримується).
• Ізоляція для кожного пода: Кожен том пода монтується в його власний піддіапазон хоста.

Більшість файлових систем Linux у ядрі ≥5.19 підтримують монтування idmap (ext4, XFS, Btrfs). NFS ще чекає на підтримку; використовуйте драйвер CSI, який виконує серверне картування, або поверніться до hostUsers для цих томів. Для tmpfs (використовується для проєктованих токенів serviceAccount, ConfigMaps, секретів, DownwardAPI) потрібне ядро ≥6.3.

Показники продуктивності та бенчмарки

Останні дані бенчмарків (тести, проведені CNCF на KubeCon EU 2024) показують, що увімкнення просторів користувачів додає незначні накладні витрати:

• Затримка запуску: +5–10 мс на створення пода (незначно в більшості CI/CD конвеєрів).
• Введення-виведення файлової системи: <1% зміни в пропускній здатності на ext4/XFS; Btrfs має ~2–3% накладні витрати під час інтенсивних випадкових записів.
• Накладні витрати пам’яті: <1 МіБ додаткових структур даних ядра на простір.

Оптимізації в containerd v1.8+ та CRI-O v1.27 зменшують шлях системного виклику для setns та налаштування idmap, скорочуючи час запуску на мілісекунди. За словами Джо Фернандеса, головного інженера в Red Hat, “реалізація userns в runc 1.1+ поєднує створення простору з налаштуванням Cgroup в одному об’єднаному виклику, що покращує продуктивність при високій плинності подів.”

Інтеграція з політиками та контролем доступу

Простори користувачів безперешкодно працюють з Pod Security Admission (PSA) Kubernetes та сторонніми механізмами політики (OPA/Gatekeeper, Kyverno). За замовчуванням, рівень PSA обмежений дозволяє hostUsers: false. Кластери також можуть увімкнути функціональні ворота RelaxedHostUsers, щоб дозволити лише певним просторам підключатися на основі міток або анотацій.

• PSA обмежений: забороняє hostUsers: true.
• OPA/Gatekeeper: забезпечує політику, що всі поди в team-a повинні використовувати userns, блокуючи будь-які пропуски.
• Kyverno: змінює прийом, щоб вставити hostUsers: false для всіх нових специфікацій подів, забезпечуючи узгодженість.

Адміністратори кластерів можуть налаштувати параметри --user-namespace-uid-min та --user-namespace-uid-max на kubelet для контролю глобального пулу UID та використовувати PodSecurityContext.fsGroup для семантики спільного тома.

Майбутні плани та відгуки громади

Спільнота SIG-Node Kubernetes активно працює над кількома вдосконаленнями, запланованими на v1.34 та наступні версії:

• Динамічний розподіл UID для кожного простору: дозволити операторам кластеру резервувати блоки для кожного простору Kubernetes для більш жорстких квот.
• Пілотний проект для просторів користувачів Windows: експериментальна підтримка для відображення концепцій перенаправлення Linux у контейнерах Windows Server 2022.
• Покращена інтеграція CSI: підтримка idmapped NFS та SMB через атрибути томів вбудованого формату.

Відгуки користувачів у GitHub KEP #127 та засідання SIG-Node визначають ці пріоритети. “Ми спостерігали, як підприємства впроваджують простори користувачів для відповідності PCI DSS та SOC 2, зазначаючи значні поліпшення в аудитах,” говорить Саша Грунерт, учасник KEP. Публічні зустрічі громади в #sig-node проходять щопонеділка в Slack.

Висновки

Перехід Kubernetes v1.33 до увімкнення просторів користувачів за замовчуванням є значним кроком у забезпеченні безпеки контейнерів та ізоляції орендарів. Відображаючи корінь контейнера на непривабливі UID хоста, кластери отримують надійний захист від бічного руху, зменшення поверхні атаки та нові випадки використання без кореня без зміни коду додатка.

Завдяки оптимізаціям продуктивності в контейнерних середовищах, безперешкодній інтеграції з PSA та механізмами політики, а також активному плану розвитку, простори користувачів стали найкращою практикою для розгортання Kubernetes у виробничих умовах.

Як долучитися

Приєднуйтесь до спільноти SIG-Node, щоб обговорити, повідомити про проблеми або внести свій внесок:

• Slack: #sig-node
• Поштовий список: kubernetes-sig-node@googlegroups.com
• GitHub: Проблеми та PR SIG-Node

Для експериментів на низькому рівні зверніться до man 7 user_namespaces, man 1 unshare та документації про монтування idmap у ядрі.