Безопасность Kubernetes часто сводят к “закрыть доступ к API”, но на практике основные риски — это слишком широкие права и небезопасные настройки Pod. Именно здесь критичны Pod Security Standards (PSS) и RBAC.
1. Pod Security Standards: базовая защита workload’ов
PSS — это набор политик, который ограничивает, как именно могут запускаться Pod’ы.
Есть 3 уровня:
- Privileged — почти без ограничений. Подходит только для системных компонентов.
- Baseline — блокирует явно опасные настройки: privileged containers, host namespaces, часть небезопасных capabilities.
- Restricted — самый безопасный режим для большинства приложений: требует запуск без root, ограничивает volume types, усиливает контроль контекста безопасности.
Что это даёт:
- снижает риск выхода контейнера на уровень хоста
- не даёт разработчикам случайно запустить Pod с опасными правами
- помогает стандартизировать безопасность по namespace
На практике для production чаще всего используют Restricted, а исключения оформляют отдельно и осознанно.
2. Как включается PSS
Pod Security Standards применяются через механизм Pod Security Admission. Обычно namespace помечают label’ами:
pod-security.kubernetes.io/enforce=restrictedpod-security.kubernetes.io/audit=restrictedpod-security.kubernetes.io/warn=restricted
Логика простая:
- enforce — запрещает создание небезопасных Pod
- audit — пишет нарушения в аудит
- warn — показывает предупреждения пользователю
Хорошая практика — сначала включить warn и audit, проверить, что ломается, и только потом переходить на enforce. ⚙️
3. RBAC: кто и что может делать
RBAC (Role-Based Access Control) отвечает не за настройки Pod, а за права пользователей, сервисных аккаунтов и приложений внутри кластера.
Ключевые сущности:
- Role — права в пределах namespace
- ClusterRole — права на уровне всего кластера
- RoleBinding / ClusterRoleBinding — привязка прав к пользователю или ServiceAccount
Пример типичной ошибки: приложению дают cluster-admin, хотя ему нужен только get/list/watch для ConfigMap в одном namespace. Это создаёт избыточные привилегии и повышает риск lateral movement при компрометации. 🚨
4. Лучшие практики RBAC
- придерживайтесь принципа least privilege
- не используйте
cluster-adminдля приложений - разделяйте права для CI/CD, разработчиков и операторов
- регулярно проверяйте, какие ServiceAccount реально используются
- убирайте неактуальные RoleBinding и ClusterRoleBinding
- ограничивайте доступ к secret’ам особенно строго
5. Почему PSS и RBAC нужно использовать вместе
PSS отвечает на вопрос: “что можно запустить?”
RBAC отвечает на вопрос: “кто может это сделать?”
Если настроен только RBAC, пользователь с легальными правами может создать небезопасный Pod. Если настроен только PSS, но права разданы слишком широко, атакующий всё равно получит лишние возможности в кластере.
Итог ✅
- namespaces с PSS Restricted по умолчанию
- аккуратно настроенный RBAC без избыточных прав
- аудит исключений, а не “временные” admin-доступы навсегда
Надёжная защита Kubernetes начинается не с сложных security-платформ, а с правильных базовых ограничений. 🛡️
Подборку полезных каналов про IT — разработку, DevOps, безопасность и инфраструктуру — стоит посмотреть ниже.