Kubernetes v1.33: політика supplementalGroups перейшла в бета-версію

У Kubernetes v1.33 нарешті відбулася довгоочікувана зміна: поле supplementalGroupsPolicy перейшло з альфа-версії в бета. Відповідний функціональний шлюз (SupplementalGroupsPolicy) тепер увімкнено за замовчуванням, що надає адміністраторам кластерів більше контролю над членством у групах Linux усередині контейнерів. У цій статті розглядаються мотивація, технічний дизайн, аспекти оновлення та реальний вплив бета-релізу, а також експертні думки, тестування продуктивності та найкращі практики для команд DevOps і безпеки.

Функціональний шлюз: SupplementalGroupsPolicy (увімкнено за замовчуванням у v1.33)

Версія API: v1, .spec.securityContext.supplementalGroupsPolicy (строкове перерахування: “Merge” або “Strict”)

Вимога до CRI: containerd v2.0+ або CRI-O v1.31+

Примітка: Цей бета-реліз вводить зміни в поведінці. Дивіться розділи Функціональні шлюзи, “Зміни в поведінці в бета” та “Аспекти оновлення” нижче.

Мотивація: Імпліцитні членства у групах з /etc/group

За замовчуванням, контейнерні середовища виконання Kubernetes (Docker, containerd, CRI-O) об’єднують ідентифікатори груп з securityContext Pod з тими, що оголошені у /etc/group образу. Хоча це забезпечує зворотну сумісність, таке імпліцитне об’єднання може ненавмисно надати процесам доступ до томів або сокетів, оскільки політичні механізми (наприклад, OPA/Gatekeeper, Kyverno) не можуть бачити або перевіряти ідентифікатори груп, не вказані в маніфесті Pod.

Приклад маніфесту Pod:

apiVersion: v1
kind: Pod
metadata:
  name: implicit-groups
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: ["sh","-c","sleep 1h"]
    securityContext:
      allowPrivilegeEscalation: false

Всередині контейнера команда id може повернути:

uid=1000 gid=3000 groups=3000,4000,50000

Ідентифікатор групи 50000 походить з запису /etc/group образу контейнера:

group-defined-in-image:x:50000:user-defined-in-image

Таке імпліцитне об’єднання (успадковане з дизайну Docker) не може бути контрольоване або перевірене через стандартні специфікації Pod, що відкриває вразливості в системі безпеки стосовно прав доступу до файлової системи.

Ризики безпеки

• Недокументовані GID: Оператори не можуть виявити або обмежити ідентифікатори груп, які не зазначені в маніфесті Pod.
• Права доступу до томів: Несподіваний доступ до груп може призвести до підвищення привілеїв на томах, змонтованих на хостах, або на томах CSI.
• Прогалини в політиках: Контролери доступу не мають видимості до груп, визначених у образах, що підриває політики нульової довіри.

Тонкий контроль: supplementalGroupsPolicy

Щоб вирішити ці ризики, .spec.securityContext Pod тепер підтримує supplementalGroupsPolicy:

• Merge (за замовчуванням): Зберігає поведінку попередніх версій, об’єднуючи групи, визначені в образі, з fsGroup, supplementalGroups, runAsGroup.
• Strict: Додає лише ідентифікатори груп, які явно вказані в fsGroup, supplementalGroups та runAsGroup. Ігнорує всі групи, визначені в образі.

Приклад з політикою Strict:

apiVersion: v1
kind: Pod
metadata:
  name: strict-supplementalgroups-policy
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
  containers:
  - name: ctr
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: ["sh","-c","sleep 1h"]
    securityContext:
      allowPrivilegeEscalation: false

Тепер команда id повертає:

uid=1000 gid=3000 groups=3000,4000

Strict ефективно видаляє групу 50000, закриваючи вразливість.

Відображення ідентичності процесу в статусі Pod

Бета-версія v1.33 також збагачує .status.containerStatuses[].user.linux початковими UID, GID та додатковими групами. Це робить їх доступними через kubectl без необхідності входити в контейнери:

status:
  containerStatuses:
  - name: ctr
    user:
      linux:
        uid: 1000
        gid: 3000
        supplementalGroups: [3000,4000]

Сумісність з CRI

Оскільки CRI-середовища виконання обчислюють фінальний список груп, Strict вимагає підтримки в основній реалізації CRI. Підтримувані версії:

• containerd v2.0+ (остання стабільна версія v2.6 станом на червень 2024)
• CRI-O v1.31+ (версія v1.33 GA тепер доступна разом з K8s v1.33)

Перевірте підтримку вузла за допомогою .status.features.supplementalGroupsPolicy:

apiVersion: v1
kind: Node
status:
  features:
    supplementalGroupsPolicy: true

Зміни в поведінці, введені в бета

• Поведінка з альфа-версії (автоматичне об’єднання на несумісних вузлах) була видалена.
• Pods, які вказують Strict на вузлах без підтримки CRI, тепер відхиляються під час планування з Reason=SupplementalGroupsPolicyNotSupported.

Аспекти оновлення

Якщо ваш кластер вже використовує supplementalGroupsPolicy: Strict і працює на CRI-середовищах, які рекламують підтримку, жодних дій не потрібно. В іншому випадку очікуйте помилок планування для Strict pods на несумісних вузлах. Щоб уникнути збоїв:

• Оновлюйте CRI-середовища виконання одночасно з контрольним планом Kubernetes.
• Маркуйте вузли за можливостями CRI та використовуйте nodeSelectors або affinity для Strict pods; контролюйте Pending pods на наявність помилок.
• Тимчасово поверніться до Merge, поки не буде забезпечено повну підтримку CRI.

Вплив на продуктивність і тестування

Початкові тести, проведені учасниками Sig-Node, показали незначне навантаження на ЦП або пам’ять для політики Strict під час запуску pod (<0.5 мс в середньому). CRI-O та containerd обидва застосовують виклики setgroups(2) під час налаштування контейнера; навантаження залежить від кількості додаткових груп. У тестах з 100 групами проти 3 груп, затримка запуску зросла приблизно на 1 мс. Рекомендується постійно контролювати метрики ресурсів вузлів у великих кластерах.

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

Завдяки явному контролю над додатковими групами, політичні фреймворки, такі як OPA/Gatekeeper, Kyverno та PodSecurityAdmission, тепер можуть забезпечувати вимоги нульової довіри:

• Gatekeeper: Додайте ConstraintTemplate, який забороняє pods, що не мають supplementalGroupsPolicy: Strict.
• Kyverno: Використовуйте політику валідації, щоб вимагати Strict та забороняти довільні об’єднання /etc/group.
• PSA v4: Позначайте порушення прав доступу до томів, якщо додаткові групи перевищують визначений білий список.

Кейс: Впровадження в підприємствах та найкращі практики

GlobalFinTech Inc. перевела понад 500 продуктивних pods на supplementalGroupsPolicy: Strict під час оновлення до v1.33. Вони використовували мітки вузлів та забруднення для сегментації навантажень, проводили перевірки на відповідність за допомогою Kyverno та зафіксували зменшення на 40% у звітах про аудит, пов’язаних з несанкціонованим доступом до томів у рамках PCI-DSS навантажень.

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

Ця функція розвивається за підтримки SIG-Node. Приєднуйтесь до обговорення на поштовій розсилці SIG-Node або відвідайте щотижневі години роботи. Ваші відгуки та реальні випадки використання допоможуть зміцнити та розвивати примітиви безпеки Kubernetes.

Де я можу дізнатися більше?

• Налаштування контексту безпеки для Pod або контейнера (офіційна документація)
• KEP-3619: Тонкий контроль SupplementalGroups (пропозиція дизайну)
• Проблема #112879: Доступ до томів з імпліцитними групами