Как не превратить Kubernetes Audit Policy в решето: разбор реального конфига
<img src="https://habrastorage.org/getpro/habr/upload_files/798/c56/571/798c56571a650253020798302b1ccdc2.png" /><p>Аудит-политика Kubernetes — один из тех артефактов, который пишется один раз при настройке кластера, а потом годами живёт «как есть», обрастая исключениями для новых компонентов и почти никогда не пересматривается целиком. В какой-то момент это уже не политика безопасности, а археологический слой из комментариев вида «# temporary, TODO remove» трёхлетней давности.</p><p>Недавно я сел перечитать собственный конфиг на ~580 строк — собирал его из нескольких источников, в первую очередь опираясь на <a href="https://kubernetes-threat-matrix.redguard.ch/" rel="noopener nofollow">Kubernetes Threat Matrix</a> (это объясняет, почему часть правил — не просто «гасим шум», а прицельно ловит security-значимые действия вроде изменений RBAC или удаления events). Хочу поделиться не столько конкретными находками (они специфичны для конкретного кластера), сколько <strong>принципами и типовыми ловушками</strong>, которые всплыли в процессе ревью. Если вы пишете или ревьюите Audit Policy для своего кластера — этот чек-лист сэкономит время.</p> <a href="https://habr.com/ru/articles/1079968/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1079968#habracut">Смотреть разбор и чек-лист</a>