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