Pod Security Admission

Огляд контролера Pod Security Admission, який може застосовувати Стандарти Безпеки Podʼів.
СТАН ФУНКЦІОНАЛУ: Kubernetes v1.25 [stable]

Стандарти безпеки Podʼів Kubernetes визначають різні рівні ізоляції для Podʼів. Ці стандарти дозволяють визначити, як ви хочете обмежувати поведінку Podʼів в чіткий, послідовний спосіб.

У Kubernetes є вбудований контролер допуску безпеки Pod, щоб застосовувати Стандарти Безпеки Podʼів. Обмеження безпеки Podʼів застосовуються на рівні просторі імен під час створення Podʼів.

Вбудоване забезпечення Pod Security admission

Ця сторінка є частиною документації Kubernetes v1.31. Якщо ви використовуєте іншу версію Kubernetes, перегляньте документацію для цієї версії.

Рівні безпеки Podʼів

Забезпечення Pod Security admission ставить вимоги до Контексту Безпеки Podʼа та інших повʼязаних полів відповідно до трьох рівнів, визначених Стандартами безпеки Podʼів: privileged (привілейований), baseline (базовий) та restricted (обмежений). Для докладного огляду цих вимог дивіться сторінку Стандартів безпеки Podʼів.

Мітки Pod Security Admission для просторів імен

Після активації функції або встановлення вебхука ви можете налаштувати простори імен, щоб визначити режим контролю допуску, який ви хочете використовувати для безпеки Podʼа в кожному просторі імен. Kubernetes визначає набір міток, які можна встановити, щоб визначити, який з попередньо визначених рівнів стандартів безпеки Podʼів ви хочете використовувати для простору імен. Вибрана вами мітка визначає дію, яку панель управління виконує, якщо виявлено потенційне порушення:

Режими входу для безпеки Podʼа
РежимОпис
enforceПорушення політики призведе до відмови обслуговування Podʼа.
auditПорушення політики спричинить додавання аудит-анотації до події, записаної в аудит-лог, але в іншому випадку буде дозволено.
warnПорушення політики спричинить попередження для користувача, але в іншому випадку буде дозволено.

Простір імен може налаштувати будь-який або всі режими, або навіть встановити різний рівень для різних режимів.

Для кожного режиму існують дві позначки, які визначають використовувану політику:

# Мітка рівня режиму вказує, який рівень політики застосовується для режиму.
#
# РЕЖИМ повинен бути одним з `enforce`, `audit` або `warn`.
# РІВЕНЬ повинен бути одним з `privileged`, `baseline` або `restricted`.
pod-security.kubernetes.io/<РЕЖИМ>: <РІВЕНЬ>

# Опціонально: позначка версії режиму, яку можна використовувати для привʼязки політики до
# версії, що поставляється з певною мінорною версією Kubernetes (наприклад, v1.31).
#
# РЕЖИМ повинен бути одним з `enforce`, `audit` або `warn`.
# ВЕРСІЯ повинна бути дійсною мінорною версією Kubernetes або `latest`.
pod-security.kubernetes.io/<РЕЖИМ>-version: <ВЕРСІЯ>

Перегляньте Застосування стандартів безпеки Podʼів з використанням міток просторів імен, щоб побачити приклад використання.

Ресурси робочого навантаження та шаблони Podʼа

Podʼи часто створюються не безпосередньо, а шляхом створення обʼєкта робочого навантаження, такого як Deployment або Job. Обʼєкт робочого навантаження визначає шаблон Podʼа та контролер для ресурсу робочого навантаження, який створює Podʼи на основі цього шаблону. Щоб вчасно виявляти порушення, обидва режими аудиту та попередження застосовуються до ресурсів робочого навантаження. Проте режим виконання не застосовується до ресурсів робочого навантаження, а лише до отриманих обʼєктів Podʼа.

Виключення

Ви можете визначити Виключення з виконання політики безпеки Podʼа, щоб дозволити створення Podʼів, які інакше були б заборонені через політику, повʼязану з певним простором імен.

Виключення можна статично налаштувати в конфігурації контролера допуску.

Виключення повинні бути явно перераховані. Запити, які відповідають критеріям винятків, ігноруються контролером допуску (всі поведінки enforce, audit та warn пропускаються). Винятків включають:

Оновлення наступних полів Podʼа виключаються з перевірки політики, що означає, що якщо запит на оновлення Podʼа змінює лише ці поля, його не буде відхилено, навіть якщо Pod порушує поточний рівень політики:

  • Будь-які оновлення метаданих виключають зміну анотацій seccomp або AppArmor:
    • seccomp.security.alpha.kubernetes.io/pod (застарілий)
    • container.seccomp.security.alpha.kubernetes.io/* (застарілий)
    • container.apparmor.security.beta.kubernetes.io/* (застарілий)
  • Дійсні оновлення .spec.activeDeadlineSeconds
  • Дійсні оновлення .spec.tolerations

Метрики

Ось метрики Prometheus, які надаються kube-apiserver:

  • pod_security_errors_total: Ця метрика показує кількість помилок, які перешкоджають нормальній оцінці. Нефатальні помилки можуть призвести до використання останнього обмеженого профілю для виконання.
  • pod_security_evaluations_total: Ця метрика показує кількість оцінок політики, що відбулися, не враховуючи ігнорованих або запитів винятків під час експортування.
  • pod_security_exemptions_total: Ця метрика показує кількість запитів винятків, не враховуючи ігноровані або запити, що не входять в область застосування.

Що далі

Якщо ви використовуєте старішу версію Kubernetes і хочете оновитися до версії Kubernetes, яка не містить політик безпеки Podʼа, прочитайте перехід від PodSecurityPolicy до вбудованого контролера допуску для безпеки Podʼа.

Змінено August 27, 2024 at 9:57 PM PST: Removing the reviewers section from the front matter (81a711722d)