Стандарти безпеки Podʼів визначають три різні політики, щоб широко охопити спектр безпеки. Ці політики є кумулятивними й охоплюють діапазон від дуже дозвільних до дуже обмежувальних. У цьому посібнику наведено вимоги кожної політики.
| Профіль | Опис |
|---|---|
| Privileged | Необмежена політика, яка забезпечує найширший можливий рівень дозволів. Ця політика дозволяє відомі підвищення привілеїв. |
| Baseline | Мінімально обмежувальна політика, яка запобігає відомим підвищенням привілеїв. Дозволяє стандартну (мінімально визначену) конфігурацію Podʼа. |
| Restricted | Дуже обмежувальна політика, що відповідає поточним рекомендаціям зі зміцнення Podʼів. |
Політика Privileged навмисно відкрита й повністю необмежена. Цей тип політики зазвичай призначений для робочих навантажень системного та інфраструктурного рівня, якими керують привілейовані, довірені користувачі.
Політика Privileged визначається відсутністю обмежень. Якщо ви визначаєте Pod, до якого застосовується політика безпеки Privileged, цей Pod може обходити типові механізми ізоляції контейнерів. Наприклад, ви можете визначити Pod, який має доступ до мережі хоста вузла.
Політика Baseline спрямована на легке впровадження для поширених контейнеризованих робочих навантажень із запобіганням відомим підвищенням привілеїв. Ця політика призначена для операторів застосунків і розробників некритичних застосунків. Наведені нижче засоби контролю слід застосовувати або забороняти:
*) позначають усі елементи списку. Наприклад, spec.containers[*].securityContext стосується обʼєкта контексту безпеки для усіх визначених контейнерів. Якщо будь-який із перелічених контейнерів не відповідає вимогам, весь Pod не пройде перевірку.| Засіб контролю | Політика |
|---|---|
| HostProcess | Podʼи Windows дають змогу запускати контейнери HostProcess, що надають привілейований доступ до хост-машини Windows. Привілейований доступ до хоста заборонено в політиці Baseline. СТАН ФУНКЦІОНАЛУ:
GA since Kubernetes v1.26 Обмежені поля
Дозволені значення
|
| Простори імен хоста | Спільне використання просторів імен хоста має бути заборонене. Обмежені поля
Дозволені значення
|
| Привілейовані контейнери | Привілейовані Podʼи вимикають більшість механізмів безпеки й мають бути заборонені. Обмежені поля
Дозволені значення
|
| Capabilities | Додавання capabilities, крім перелічених нижче, має бути заборонене. Обмежені поля
Дозволені значення
|
| Томи HostPath | Томи HostPath мають бути заборонені. Обмежені поля
Дозволені значення
|
| Порти хоста | HostPorts слід повністю заборонити (рекомендовано) або обмежити відомим списком Обмежені поля
Дозволені значення
|
| Проби хоста / хуки життєвого циклу (v1.34+) | Поле Host у пробах і хуках життєвого циклу має бути заборонене. Обмежені поля
Дозволені значення
|
| AppArmor | На підтримуваних хостах стандартно застосовується профіль AppArmor Обмежені поля
Дозволені значення
Дозволені значення
|
| SELinux | Встановлення типу SELinux обмежено, а встановлення власного користувача або ролі SELinux заборонено. Обмежені поля
Дозволені значення
Обмежені поля
Дозволені значення
|
Тип монтування /proc | Стандартні маски Обмежені поля
Дозволені значення
|
| Seccomp | Профіль Seccomp не можна явно встановлювати в значення Обмежені поля
Дозволені значення
|
| Sysctls | Sysctls можуть вимикати механізми безпеки або впливати на всі контейнери на хості, тому їх слід заборонити, крім дозволеної «безпечної» підмножини. Sysctl вважається безпечним, якщо він обмежений простором імен контейнера або Podʼа й ізольований від інших Podʼів або процесів на тому самому вузлі. Обмежені поля
Дозволені значення
|
Політика Restricted спрямована на застосування поточних рекомендацій зі зміцнення Podʼів ціною певної втрати сумісності. Вона призначена для операторів і розробників критичних для безпеки застосунків, а також для користувачів із нижчим рівнем довіри. Наведені нижче засоби контролю слід застосовувати або забороняти:
*) позначають усі елементи списку. Наприклад, spec.containers[*].securityContext стосується обʼєкта контексту безпеки для усіх визначених контейнерів. Якщо будь-який із перелічених контейнерів не відповідає вимогам, весь Pod не пройде перевірку.| Засіб контролю | Політика |
| Усе з політики Baseline | |
| Типи томів | Політика Restricted дозволяє лише такі типи томів. Обмежені поля
Дозволені значення Кожен елемент спискуspec.volumes[*] повинен встановлювати одне з наведених нижче полів у значення, відмінне від null:
|
| Підвищення привілеїв (v1.8+) | Підвищення привілеїв (наприклад, через режим файлів set-user-ID або set-group-ID) не слід дозволяти. Це політика лише для Linux у v1.25+ Обмежені поля
Дозволені значення
|
| Запуск не від імені root | Контейнери мають працювати від імені користувачів, відмінних від root. Обмежені поля
Дозволені значення
nil, якщо на рівні Podʼа
spec.securityContext.runAsNonRoot встановлено в true. |
| Запуск від імені користувача, відмінного від root (v1.23+) | Контейнери не повинні встановлювати runAsUser у 0 Обмежені поля
Дозволені значення
|
| Seccomp (v1.19+) | Профіль Seccomp має бути явно встановлений в одне з дозволених значень. Заборонено як профіль Обмежені поля
Дозволені значення
nil, якщо на рівні Podʼа spec.securityContext.seccompProfile.type встановлено відповідне значення. Навпаки, поле на рівні Podʼа може бути undefined/nil, якщо встановлено _всі_ поля на рівні контейнера. |
| Capabilities (v1.22+) | Контейнери повинні скидати всі capabilities ( Обмежені поля
Дозволені значення
Обмежені поля
Дозволені значення
|
Відокремлення визначення політики від її втілення дає змогу мати спільне розуміння й узгоджену мову політик у всіх кластерах незалежно від базового механізму застосування.
Коли механізми стануть зрілішими, їх буде описано нижче окремо для кожної політики. Способи застосування окремих політик тут не визначено.
Контролер Pod Security Admission
Інші альтернативи застосування політик розробляються в екосистемі Kubernetes, зокрема:
Kubernetes дозволяє використовувати вузли, що працюють під керуванням Linux або Windows. Ви можете поєднувати обидва типи вузлів в одному кластері. Windows у Kubernetes має певні обмеження й відмінності від робочих навантажень на базі Linux. Зокрема, багато полів securityContext Podʼа не діють у Windows.
Ще одна важлива зміна, внесена в Kubernetes v1.25, полягає в тому, що політику Restricted оновлено для використання поля pod.spec.os.name. Залежно від назви ОС певні політики, специфічні для конкретної ОС, можна послабити для іншої ОС.
Обмеження на наведені нижче засоби контролю потрібні лише тоді, коли .spec.os.name не дорівнює windows:
Простори імен користувачів — це можливість лише для Linux, що дозволяє запускати робочі навантаження з підвищеною ізоляцією. Як вони працюють разом зі стандартами безпеки Podʼів, описано в документації для Podʼів, що використовують простори імен користувачів.
Три визначені тут профілі мають чітку лінійну прогресію від найбезпечнішого (Restricted) до найменш безпечного (Privileged) і охоплюють широкий набір робочих навантажень. Привілеї, потрібні понад політику Baseline, зазвичай дуже специфічні для застосунку, тому ми не пропонуємо стандартного профілю в цій ніші. Це не означає, що в такому разі завжди слід використовувати профіль Privileged, але політики в цій області потрібно визначати окремо для кожного випадку.
SIG Auth може переглянути цю позицію в майбутньому, якщо зʼявиться чітка потреба в інших профілях.
Контексти безпеки налаштовують Podʼи та контейнери під час виконання. Контексти безпеки визначаються як частина специфікацій Podʼа й контейнера в маніфесті Podʼа та є параметрами для середовища виконання контейнерів.
Профілі безпеки — це механізми панелі управління для застосування певних налаштувань у контексті безпеки, а також інших повʼязаних параметрів поза контекстом безпеки. Станом на липень 2021 року політики безпеки Podʼів визнано застарілими на користь вбудованого контролера Pod Security Admission.
Наразі немає стандарту API, який визначає, чи вважається Pod ізольованим у пісочниці. Podʼи в пісочниці можна визначити за використанням середовища виконання в пісочниці (такого як gVisor або Kata Containers), але стандартного визначення такого середовища немає.
Захист, потрібний робочим навантаженням у пісочниці, може відрізнятися від інших. Наприклад, потреба обмежувати привілейовані дозволи менша, коли робоче навантаження ізольоване від базового ядра. Це дозволяє ізолювати робочі навантаження, яким потрібні підвищені дозволи.
Крім того, захист робочих навантажень у пісочниці значною мірою залежить від методу ізоляції в пісочниці. Тому немає єдиного профілю, рекомендованого для всіх робочих навантажень у пісочниці.
Елементи на цій сторінці відносяться до сторонніх продуктів чи проєктів, які надають функціонал, необхідний для Kubernetes. Автори проєкту Kubernetes не несуть відповідальності за ці проєкти. Ознайомтесь з настановами на вебсайті CNCF для отримання докладної інформації.
Ознайомтесь з посібником з контенту перед тим, як пропонувати додавання посилання на стороні компоненти.