SecurityContext
Простыми словами
Приложению не обязательно давать полномочия root и возможность менять системные файлы. SecurityContext позволяет описать более узкие условия, в которых процесс должен работать.
Как применяется
Параметры применяют при защите контейнерных нагрузок от избыточных полномочий. Настройки уровня Pod и контейнера имеют разные области действия; поддержка зависит от ОС и среды исполнения. Они дополняют, но не заменяют обновление образов и проверку допустимости конфигурации при запуске.
Пример применения
Веб-сервис запускают непривилегированным пользователем, отключают повышение привилегий и убирают ненужные capabilities. Корневую файловую систему делают доступной только для чтения, а временные файлы направляют в отдельный том. Перед внедрением проверяют, что приложение действительно умеет работать с такими ограничениями.
Не путать с
- Kubernetes RBACКонтролирует запросы к API, а не права процесса внутри контейнера.
- NetworkPolicyОпределяет сетевые связи Pod; не задаёт UID и файловые разрешения.
- Pod Security AdmissionПроверяет допустимость конфигурации при создании Pod; сам SecurityContext описывает условия исполнения.
Как это работает
- Определить потребностиВыясняют, какие UID, файлы и привилегии действительно нужны приложению.
- Ограничить процессЗадают непривилегированный запуск и минимальный набор capabilities.
- Защитить исполнениеНастраивают запрет повышения привилегий, seccomp и режим файловой системы.
- Испытать нагрузкуПроверяют рабочие операции и то, что запрещённые действия действительно недоступны.
Продолжить изучение
Связанные термины
Частые вопросы
Нет. Это одно ограничение; также оценивают capabilities, файловую систему и другие параметры.
Read-only запрещает любую запись?Нет. Подключённые writable-тома могут оставаться доступными для записи.
Почему контейнер перестал запускаться?Приложение может требовать запись в системный каталог или привилегированную операцию. Нужную функцию перерабатывают, а не снимают все ограничения сразу.