На днях стало известно, что в Kubernetes v1.22.0 ожидается альфа-реализация функции, которая при запуске контейнеров превентивно включает режим seccomp (Secure Computing Mode). Идея в том, чтобы фильтрация системных вызовов, которые могут выполнять контейнеры, работала в K8s по умолчанию; сейчас seccomp нужно активировать вручную. Нововведение призвано повысить уровень базовой безопасности Kubernetes.
Инициатор соответствующего KEP (Kubernetes Enhancement Proposal) — немецкий инженер и Open Source-энтузиаст Саша Грунерт (@saschagrunert). Он отметил, что seccomp защищает и от CVE, и от уязвимостей нулевого дня. «Если мы включим seccomp по умолчанию, Kubernetes будет более безопасным», — написал Грунерт.
Новость многих порадовала:
Как seccomp работает сейчас
Приложение в контейнере может быть уязвимо. Без фильтрации системных вызовов злоумышленник без труда выберется из контейнера, после чего скомпрометирует узел или целый кластер. Seccomp — механизм ядра Linux, который защищает от такой компрометации.
Для фильтрации используются профили seccomp, в которых указываются легитимные вызовы. Сами профили активирует исполняемая среда контейнера (container runtime) при его запуске: после этого ядро ОС может контролировать системные вызовы. (Подробнее о том, как работает seccomp в Kubernetes и как его настраивать, можно почитать в этой статье.)
В текущей версии Kubernetes seccomp по умолчанию отключен. Чтобы его включить, нужно прописать профиль seccomp в аннотациях объекта PodSecurityPolicy. Задавать профили seccomp можно на уровне pod’а и на уровне контейнера. Все pod’ы, для которых профиль seccomp не определен, запускаются в режиме Unconfined.
Кстати, PSP (Pod Security Policies) уже устарели для v1.21 и будут удалены в v1.25. Но пока именно они определяют настройки безопасности.
Как это будет реализовано в K8s 1.22.0
В Kubernetes каждой рабочей нагрузке по умолчанию присваивается встроенный профиль RuntimeDefault. Теперь RuntimeDefault станет еще и seccomp-профилем по умолчанию. То есть ему будет присваиваться значение SeccompProfile.type в настройках PodSecurityContext и SecurityContext.
Плюс такого подхода в том, что отпадает необходимость в дополнительном профиле seccomp. Это упрощает реализацию, потому что среды выполнения контейнеров уже поддерживают RuntimeDefault.
В то же время режим seccomp по умолчанию «не освобождает от ответственности»: сам профиль всё равно придется настраивать, прописывать разрешения, блокировки и т. д.
P.S.
Читайте также в нашем блоге:
