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

Ця сторінка надає огляд найкращих практик щодо впровадження стандартів безпеки для Podʼів.

Використання вбудованого контролера допуску безпеки Podʼів

Контролер допуску безпеки Podʼів має на меті замінити застарілі політики безпеки Podʼів (PodSecurityPolicies).

Налаштування для всіх просторів імен кластера

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

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

Принципу найменшого доступу

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

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

Використання стратегії мультимодальності

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

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

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

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

Альтернативи від сторонніх постачальників

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

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

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