k8s (in)security

Вторая часть из цикла [1] про sensor-based решения по безопасности для Kubernetes.



Prevention - желание многих security-команд и страшный сон SRE-команд, так как это может как сломать что-то, так и просто внести неясность в работу из-за того, что изменения/правила известны только тем, кто их внес и могут быть видны только в инструменте, где были применены.



Sensor'ы могут это обеспечить по-разному (со своими плюсами и минусами): через системные механизмы, CRI и собственными силами.



1) Системные механизмы значит, что сам sensor этим не занимается, а занимается ОС с помощью seccomp, AppArmor, SeLinux в режиме prevention, а в случаи сети это вообще NetworkPolicy самого Kubernetes. В таком случаи sensor может помочь подготовить политики для данных механизмов, но применять их будет ОС. Обеспечивает высокий уровень надежности и контроля с высокой наглядностью для всех команд (так как можно прописать прям в YAML).

2) Сценарий с CRI (Container Runtime Interface) означает контроль на уровне работы всего контейнера - запуск, пауза, остановка. Реализации бывают разные и некоторые способны только на response, никакого реального prevention.

3) Категория собственными силами самая обширная и полностью зависит от способа работы (рассматривали в прошлом посте) самого sensor. В случае встраивания библиотек, тут классический антивирус - подгружающий в себя все что нельзя и на каждый системный вызов проверяющий можно это или нет. В случае eBPF все может быть очень красиво на базе KRSI (Kernel Runtime Security Instrumentation), но требует ядро > 5.8. Явным плюсом тут является возможность на лету менять сами политики/правила.



Важно понимать, что sensor как и ContainerRuntime достаточно опосредованно понимает, что такое сущности Kubernetes и мыслит в терминах контейнеров и происходящего в нем. Также sensor заранее не знает где и какой workload будет запущен и ряд проверок будет делать там, где это и не надо, замедляя работу даже тех сущностей, к которым prevention и не относится.