# Pod Security Admission

> Огляд контролера Pod Security Admission, який може застосовувати Стандарти безпеки Podʼів.

---

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->








  <div class="feature-state-notice feature-stable">
      <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span>
      <code>Kubernetes v1.25 [stable]</code>
    </div>
  



Стандарти [безпеки Podʼів Kubernetes](/docs/concepts/security/pod-security-standards/) визначають різні рівні ізоляції для Podʼів. Ці стандарти дозволяють визначити, як ви хочете обмежувати поведінку Podʼів в чіткий, послідовний спосіб.

У Kubernetes є вбудований <a class='glossary-tooltip' title='Фрагмент коду, який перехоплює запити до сервера API Kubernetes перед збереженням обʼєкта.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/access-authn-authz/admission-controllers/' target='_blank' aria-label='контролер допуску'>контролер допуску</a> _безпеки Pod_, щоб застосовувати Стандарти безпеки Podʼів. Обмеження безпеки Podʼів застосовуються на рівні <a class='glossary-tooltip' title='Абстракція, що використовується в Kubernetes для ізоляції груп ресурсів в межах одного кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/namespaces' target='_blank' aria-label='просторі імен'>просторі імен</a> під час створення Podʼів.

### Вбудоване забезпечення Pod Security admission {#built-in-pod-security-admission-enforcement}

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

<!-- body -->

## Рівні безпеки Podʼів {#pod-security-levels}

Pod Security admission ставить вимоги до [Контексту Безпеки](/docs/tasks/configure-pod-container/security-context/) Podʼа та інших повʼязаних полів відповідно до трьох рівнів, визначених [Стандартами безпеки Podʼів](/docs/concepts/security/pod-security-standards): `privileged` (привілейований), `baseline` (базовий) та `restricted` (обмежений). Для докладного огляду цих вимог дивіться сторінку [Стандартів безпеки Podʼів](/docs/concepts/security/pod-security-standards).

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

Після активації функції або встановлення вебхука ви можете налаштувати простори імен, щоб визначити режим контролю допуску, який ви хочете використовувати для безпеки Podʼа в кожному просторі імен. Kubernetes визначає набір <a class='glossary-tooltip' title='Позначає обʼєкти атрибутами ідентифікації, які мають значення і є важливими для користувачів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/labels' target='_blank' aria-label='міток'>міток</a>, які можна встановити, щоб визначити, який з попередньо визначених рівнів стандартів безпеки Podʼів ви хочете використовувати для простору імен. Вибрана вами мітка визначає дію, яку панель управління виконує, якщо виявлено потенційне порушення:



 





<table><caption style="display: none;">Режими входу для безпеки Podʼа</caption>
	<thead>
			<tr>
					<th style="text-align: left">Режим</th>
					<th style="text-align: left">Опис</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td style="text-align: left"><strong>enforce</strong></td>
					<td style="text-align: left">Порушення політики призведе до відмови обслуговування Podʼа.</td>
			</tr>
			<tr>
					<td style="text-align: left"><strong>audit</strong></td>
					<td style="text-align: left">Порушення політики спричинить додавання аудит-анотації до події, записаної в <a href="/uk/docs/tasks/debug/debug-cluster/audit/">аудит-лог</a>, але в іншому випадку буде дозволено.</td>
			</tr>
			<tr>
					<td style="text-align: left"><strong>warn</strong></td>
					<td style="text-align: left">Порушення політики спричинить попередження для користувача, але в іншому випадку буде дозволено.</td>
			</tr>
	</tbody>
</table>


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

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

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

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

Перегляньте [Застосування стандартів безпеки Podʼів з використанням міток просторів імен](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels), щоб побачити приклад використання.

## Ресурси робочого навантаження та шаблони Podʼа {#workload-resources-and-pod-templates}

Podʼи часто створюються не безпосередньо, а шляхом створення [обʼєкта робочого навантаження](/docs/concepts/workloads/controllers/), такого як <a class='glossary-tooltip' title='Керує реплікованим застосунком у вашому кластері.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/deployment/' target='_blank' aria-label='Deployment'>Deployment</a> або <a class='glossary-tooltip' title='Скінченне або пакетне завдання, яке виконується до завершення.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/job/' target='_blank' aria-label='Job'>Job</a>. Обʼєкт робочого навантаження визначає _шаблон Podʼа_ та <a class='glossary-tooltip' title='Контролер — цикл управління, що спостерігає за загальним станом кластера через apiserver і вносить зміни в намаганні наблизити поточний стан до бажаного.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/controller/' target='_blank' aria-label='контролер'>контролер</a> для ресурсу робочого навантаження, який створює Podʼи на основі цього шаблону. Щоб вчасно виявляти порушення, обидва режими аудиту та попередження застосовуються до ресурсів робочого навантаження. Проте режим enforce **не** застосовується до ресурсів робочого навантаження, а лише до отриманих обʼєктів Podʼа.

## Виключення {#exemptions}

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

Виключення можна статично налаштувати в [конфігурації контролера допуску](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller).

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

- **Usernames:** запити від користувачів за виключеним автентифікованих (або знеособлених) користувачів ігноруються.
- **RuntimeClassNames:** Podʼи та [ресурси робочого навантаження](#workload-resources-and-pod-templates), які вказують виключене імʼя класу runtime, ігноруються.
- **Namespaces:** Podʼи та [ресурси робочого навантаження](#workload-resources-and-pod-templates) у виключеному просторі імен ігноруються.

<div class="alert alert-caution" role="note"><h4 class="alert-heading">Увага:</h4>Більшість Podʼів створюються контролером у відповідь на <a href="#workload-resources-and-pod-templates">ресурс робочого навантаження</a>, що означає, що виключення кінцевого користувача буде застосовуватися лише до нього при створенні Podʼів безпосередньо, але не при створенні ресурсу робочого навантаження. Службові облікові записи контролера (наприклад, <code>system:serviceaccount:kube-system:replicaset-controller</code>) зазвичай не повинні бути виключені, оскільки це неявно виключить будь-якого користувача, який може створювати відповідний ресурс робочого навантаження.</div>


Оновлення наступних полів 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`

## Метрики {#metrics}

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

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

## Що далі

- [Стандарти безпеки Podʼів](/docs/concepts/security/pod-security-standards)
- [Застосування стандартів безпеки Podʼів](/docs/setup/best-practices/enforcing-pod-security-standards)
- [Застосування стандартів безпеки Podʼів за допомогою вбудованого контролера допуску](/docs/tasks/configure-pod-container/enforce-standards-admission-controller)
- [Застосування стандартів безпеки Podʼів з мітками простору імен](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)

Якщо ви використовуєте старішу версію Kubernetes і хочете оновитися до версії Kubernetes, яка не містить політик безпеки Podʼа, прочитайте [перехід від PodSecurityPolicy до вбудованого контролера допуску для безпеки Podʼа](/docs/tasks/configure-pod-container/migrate-from-psp).