Привет!
Pod Security Policy (PSP) – достаточно удобный механизм, который позволяет контролировать запуск privileged контейнеров, останавливать запуск из под root, управлять mount’ами и реализовать иные функции, полезные с точки зрения безопасности.
Однако, многие слышали новость о том, что Pod Security Policy могут быть убраны/переработаны/заменены в новых версиях Kubernetes (предположительно в версии 1.22). В статье автор описывает свой взгляд на происходящее с точки зрения предпосылок:
🍭 Неявные/неочевидные bindings
🍭 Вопросы поддержки различных runtime
🍭 Ограничение границ применения (только pods)
🍭 Сложности, связанные с test coverage при создании PSP
И некоторых рекомендаций относительно того, что можно сделать в рассматриваемой ситуации (если вы их используете):
🍭 Custom Admission Controllers
🍭 Open Policy Agent (OPA)
🍭 Использование сторонних решений
P.S. Информация про изменения Kubernetes: https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta
Pod Security Policy (PSP) – достаточно удобный механизм, который позволяет контролировать запуск privileged контейнеров, останавливать запуск из под root, управлять mount’ами и реализовать иные функции, полезные с точки зрения безопасности.
Однако, многие слышали новость о том, что Pod Security Policy могут быть убраны/переработаны/заменены в новых версиях Kubernetes (предположительно в версии 1.22). В статье автор описывает свой взгляд на происходящее с точки зрения предпосылок:
🍭 Неявные/неочевидные bindings
🍭 Вопросы поддержки различных runtime
🍭 Ограничение границ применения (только pods)
🍭 Сложности, связанные с test coverage при создании PSP
И некоторых рекомендаций относительно того, что можно сделать в рассматриваемой ситуации (если вы их используете):
🍭 Custom Admission Controllers
🍭 Open Policy Agent (OPA)
🍭 Использование сторонних решений
P.S. Информация про изменения Kubernetes: https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta