Аудит-политика Kubernetes: чек-лист против типовых слепых зон в правилах
<img src="https://habrastorage.org/getpro/habr/upload_files/1b3/020/dfc/1b3020dfcc86c0fe5653ede78737b37c.png" /><p>Всем привет! Решил поделиться с вами опытом написания и проведения ревью аудит‑политики Kubernetes.</p><p>Аудит‑политика Kubernetes — один из тех пунктов, который пишется один раз при настройке кластера, а потом годами живёт «как есть», обрастая исключениями для новых компонентов и почти никогда не пересматривается целиком. В какой‑то момент это уже не политика безопасности, а слой из комментариев трёхлетней давности.</p><p>Недавно я сел перечитать собственный конфиг на ~580 строк — собирал его из нескольких источников, в первую очередь опираясь на <a href="https://kubernetes-threat-matrix.redguard.ch/" rel="noopener nofollow">Kubernetes Threat Matrix</a>. Хочу поделиться не столько конкретными находками (так как они специфичны для конкретного кластера), сколько <strong>принципами и типовыми ловушками</strong>, которые всплыли в процессе ревью. Если вы пишете или проводите ревью политики аудита для своего кластера — этот чек‑лист вполне сэкономит время.</p> <a href="https://habr.com/ru/articles/1080076/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1080076#habracut">Смотреть разбор и чек-лист</a>