# Запровадження стандартів безпеки для Podʼів

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

---

<!-- overview -->

Ця сторінка надає огляд найкращих практик щодо впровадження [стандартів безпеки для Podʼів](/docs/concepts/security/pod-security-standards).

<!-- body -->

## Використання вбудованого контролера допуску безпеки Podʼів {#using-the-built-in-pod-security-admission-controller}








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



[Контролер допуску безпеки Podʼів](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) має на меті замінити застарілі політики безпеки Podʼів (PodSecurityPolicies).

### Налаштування для всіх просторів імен кластера {#configure-all-cluster-namespaces}

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

У сценарії, коли всі робочі навантаження у всіх просторах імен мають однакові вимоги до безпеки, ми надаємо [приклад](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) який показує, як можна застосовувати мітки безпеки для Podʼів гуртом.

### Принцип найменшого доступу {#embrace-the-principle-of-least-privilege}

У ідеальному світі кожен Pod в кожному просторі імен повинен відповідати вимогам політики `restricted`. Однак це або не можливо, або не практично, оскільки деякі робочі навантаження будуть вимагати підняття привілеїв з певних причин.

- Простори імен, які дозволяють робочі навантаження з піднятими привілеями, повинні встановлювати та здійснювати відповідні рівні контролю доступу.
- Для робочих навантажень, які працюють в цих дозвільних просторах імен, важливо зберігати документацію щодо їх унікальних вимог до безпеки. Якщо це можливо, розгляньте можливість подальшого обмеження цих вимог.

### Використання стратегії мультимодальності {#adopt-a-multi-mode-strategy}

Режими `audit` та `warn` контролера впровадження стандартів безпеки Podʼів дозволяють легко збирати важливі відомості щодо безпеки ваших Podʼів без порушення поточних робочих навантажень.

Доброю практикою є включення цих режимів для всіх просторів імен, встановлюючи їх на _бажаний_ рівень і версію, яку ви в кінцевому підсумку хочете `застосувати` (`enforce`). Попередження та аудит-анотації, створені на цьому етапі, можуть направляти вас до цього стану. Якщо ви очікуєте, що автори робочих навантажень внесуть зміни для відповідності бажаному рівню, увімкніть режим `warn`. Якщо ви очікуєте використання логів аудиту для моніторингу та виклику змін для відповідності бажаному рівню, включіть режим `audit`.

Коли режим `enforce` встановлено як бажаний рівень, ці режими все ще можуть бути корисними декількома різними способами:

- Встановивши `warn` на той самий рівень, що й `enforce`, клієнти отримають попередження при спробі створення Podʼів (або ресурсів, які мають шаблони Podʼів), які не проходять валідацію. Це допоможе їм оновити ці ресурси, щоб вони стали сумісними.
- В просторах імен, які закріплюють `enforce` за конкретною не-останньою версією, встановлення режимів `audit` та `warn` на той самий рівень, що й `enforce`, але на `latest` версію, надає видимість налаштувань, які були дозволені попередніми версіями, але не дозволяються за поточними найкращими практиками.

## Альтернативи від сторонніх постачальників {#third-party-alternatives}

<div class="alert alert-secondary callout third-party-content" role="note"><strong>Примітка:</strong>&puncsp;Цей розділ містить посилання на проєкти сторонніх розробників, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Проєкти вказано в алфавітному порядку. Щоб додати проєкт до цього списку, ознайомтеся з <a href="/uk/docs/contribute/style/content-guide/#third-party-content">посібником з контенту</a> перед надсиланням змін. <a href="#third-party-content-disclaimer">Докладніше.</a></div>


В екосистемі Kubernetes розробляються інші альтернативи для впровадження профілів безпеки:

- [Kubewarden](https://github.com/kubewarden).
- [Kyverno](https://kyverno.io/policies/).
- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).

Вирішення вибору _вбудованого_ рішення (наприклад, контролера допуску безпеки Podʼів) або інструменту від сторонніх постачальників цілком залежить від вашої конкретної ситуації. При оцінці будь-якого рішення довіра до вашого ланцюга постачання є критичною. В решті решт використання _будь-якого_ з зазначених підходів буде кращим, ніж нічого.