Безопасность Kubernetes-кластеров: вредные советы или bullshit bingo

Как погубить кластер, действуя во благо? Подборка вредных советов из реальных кейсов и опыта от специалиста по безопасности контейнеров и Kubernetes. Вместе установим антивирус на ноды, просканируем хостовую ОС и заблокируем выкатки образов с чувствительной информацией.

Привет, Хабр! Меня зовут Дмитрий Евдокимов. Я — Founder & CTO Luntry в компании по созданию решений для безопасности контейнеров и Kubernetes, CFP конференций DevOpsConf и Highload, автор курса «Cloud-Native безопасность в Kubernetes» и телеграм-канала k8s (in) security. Эта статья написана по мотивам моего доклада для DevOpsConf 2024. Так как я проработал в сфере информационной безопасности больше 15 лет и специализируюсь именно на безопасности контейнеров и кластеров, дам несколько «вредных» советов, как сделать Kubernetes-кластер «безопасным».

Сразу отмечу, что безопасность и надёжность — вещи неразрывные. Нельзя сделать систему безопасной, но при этом ненадёжной — она просто не будет никому нужна. А ещё нельзя её построить, не понимая как она устроена и функционирует.

Дисклеймер

Все вредные советы взяты из реальных корпоративных требований и техзаданий, внутренней документации, описаний процессов. Это кейсы, собранные из четырёхлетнего опыта работы с безопасностью контейнеров в крупных компаниях разных секторов — от финтеха и ретейла до онлайн-кинотеатров, нефтегазовой промышленности и соцсетей. Скриншотов не будет, чтобы не раскрывать информацию. Использовать все перечисленные в этой статье советы — можно, только осторожно и с полным пониманием последствий. Самое страшное — бездумно использовать эти приёмы без понимания, к чему они могут привести. Моя задача — показать, к чему может привести использование без понимания.

Немного теории

К сожалению, многие забыли истоки Kubernetes и цели для которых он создавался. Kubernetes — это оркестратор контейнеров, который позволяет скалировать и распределять нагрузку.

Минимальная единица управления для Kubernetes — Pod. Kubernetes является декларативной PaaS-системой и не работает напрямую с контейнерами. Работу с контейнерами на себя берут высокоуровневый и низкоуровневый container runtime. Kubernetes управляет YAML-файлами, не ведая ни про хостовую операционную систему, ни про железо, ни про контейнер, ни про то, как они работают. Просто это не его задача. Но многие думают не так. В результате помещают в него задачи и подходы, предполагающие, что он этими знаниями владеет. И вот тогда и возникают проблемы…

Компоненты Kubernetes выглядят так:

Kubernetes создан для оркестрации микросервисов, для этого у него есть собственная инфраструктура, которая обычно состоит из Control Plane и Worker Node. На Control plane установлены управляющие микросервисы, а на Data Plane или Worker Node — kube-proxy, kubelet. Kube-proxy при этом может в некоторых инсталляциях отсутствовать (зависит от CNI). А ещё есть непосредственно наши пользовательские нагрузки.

Идейно не предполагается, что на этих Nodes вы будете устанавливать не контейнерезированные нагрузки: FTP сервера, базы данных и так далее. Это специализированная система для управления контейнерами и рядом, по идее, ничего запускаться не должно.

Окружение и соседние сервисы. А ещё у многих из виду выпадает аспект, что безопасность Kubernetes — это не только защита самого Kubernetes как платформы, но и всех смежных систем вокруг него. Ведь в экосистеме Kubernetes много дополнительных компонентов: registry, CI/CD пайплайны, внешние базы данных, хранилища, различные системы, связанные с аутентификацией, находящиеся за пределами Kubernetes, и так далее. Реальность обеспечения безопасности Kubernetes-окружения — это защита как самой платформы, так и соседних, связанных с ней систем. Потому что, как показывает практика аудитов и пентестов, порой, слабые звенья — это те, что стоят рядом с Kubernetes. Для этого даже необязательно попадать в Kubernetes и ломать его.

Shift left security или shift everyway security — подход, при котором все наилучшие практики по безопасности постепенно перемещаются с правого края, с рантайма, к левому краю, то есть к процессу разработки. Об этом аспекте многие забывают и в результате всё, что только возможно, располагают слева, отходя от основной идеи. При этом, не понимая какие риски и проблемы это может привнести. Важно понимать, что каждый механизм безопасности имеет своё правильное место в цепочке shift everyway security. Далее рассмотрим, как эти механизмы должны быть правильно распределены.

Вредные советы

Эти вредные советы вы можете встретить в различных корпоративных документах, ТЗ, и так далее. Мы разберём, как обосновать или правильно продумать архитектуру процесса и подходы, почему делать как в совете не надо и как сделать правильно.

Совет 1. Установка антивируса на ноды кластера

Этот совет/требование можно увидеть в огромном количестве документов: нужно поставить антивирус на ноды кластера Kubernetes. На своём канале «k8s in security» я даже проводил опрос по вредным советам: что самое глупое от вас требовали? С большим отрывом победил такой комментарий: «установить сертифицированный антивирус и наложенное СЗИ от НСД на ноды кластера Kubernetes». Мы также часто замечаем необдуманную установку антивирусов у наших друзей и клиентов.

Обычно это требование обосновывается так:

• Прописано в общем корпоративном стандарте информационной безопасности, составленном много лет назад. Требование так и звучит, что на всей инфраструктуре и на всех системах должны быть установлены антивирусы. Это требование логично, когда речь идёт о Windows и Linux системах, где работают пользователи, сотрудники, бухгалтеры и т.д.

• Это требование спокойно переносят и на Kubernetes, ведь его инфраструктура является частью общей инфраструктуры. Идея в том, чтобы обнаруживать вредоносную активность, которая выполняется на такой системе.

Последствия установки антивируса на ноды кластера Kubernetes:

• Неэффективное использование вычислительных ресурсов нод.

Антивирус, работая на ноде, начинает её полностью проверять, забирая на себя значительное количество вычислительных ресурсов. 

Например, у одного из наших клиентов средства безопасности на ноде потребляли больше ядер, чем бизнес-нагрузка, из-за того, что он установил в свой Kubernetes-кластер гигантское количество средств защиты. В кластере из 16 ядер 8 использовались для защиты, и лишь часть из оставшихся 8 выделялась на бизнес-нагрузку, которая зарабатывала деньги бизнесу.

• Негативное влияние на микросервисы.

Антивирусы — сложные решения с поведенческими, сигнатурными, динамическими, эмуляционными анализами, работающими в связке. Поэтому, когда добираются до директории var/lib/docker, var/lib/containerd, где лежат кэшированные образы, то начинают ходить по всем их слоям и сканировать, потребляя очень много ресурсов.

Это может привести к выполнению сотен и тысяч операций, что иногда даже приводит к падению ноды из-за интенсивного чтения. Естественно, антивирус ходит во все контейниризированные процессы и в namespace контейнеров, которые работают отдельно. Начинает их активно мучить эволюционными и динамическими анализами, порой фризя их активность. Что, естественно, негативно сказывается на их работе.

Даже в самой документации Docker написано о проблемах работы системы контейнеризации на одном хосте с антивирусным решением.

Как это работает в реальности?

Обычно всё это работает вдвойне странно: агенты антивируса ставят в отключенном виде или почти всё заносят в список исключений. Мы видим это в реальной жизни, в рабочих кейсах постоянно.

И даже если мы обратимся к различным международным и отечественным стандартам, фреймворкам, бенчмаркам по безопасности контейнерных сред, типа:

• CLOUD NATIVE SECURITY WHITEPAPER;

• СIS Kubernetes Benchmark;

• NSA/CISA Kubernetes Hardening Guide;

• Kubernetes Security Technical Implementation Guide (STIG);

• PCI Security Standards Council: Guidance for Containers and Container Orchestration Tools;

• NIST Special Publication 800-190 «Application Container Security Guide»;

• Приказ ФСТЭК России No118. Требования по безопасности информации к средствам контейнеризации.

То запустив там банальный поиск по слову «антивирус», то ничего не найдём.

Что я могу порекомендовать — полезные советы:

1. Получить письмо от руководства о разрешении не ставить антивирус на кластер Kubernetes. Мы часто встречаем такое у продвинутых клиентов.

2. Использовать специализированные контейнерные ОС для хоста, которые сейчас набирают популярность: Talos, Flatcar Container Linux, Fedora CoreOS, openSUSE, MicroOS, Bottlerocket, Container-Optimized OS.

Их гигантское преимущество — в минималистичности, там вырезано всё, что не требуется непосредственно для запуска контейнеров. Это значит, что гигантский attack surface просто убран. А ещё они, как правило, иммутабельные, поэтому закрепление, попадание атакующим серьезно усложняется. Там есть специальные сборки ядер и других компонентов. На этой операционке антивирус не нужен и смысла ставить его — нет, потому что записать туда ничего нельзя. Если захотите что-то записать, то придётся пересобрать этот образ и переналить всю ноду. Вредоносному коду нужно провернуть то же самое.

3. Посмотреть презентацию «Сочетание несочетаемого в Kubernetes: удобство, производительность, безопасность», HighLoad++ 2022.

Совет 2. Сканирование хостовой ОС на известные уязвимости в пакетах

Это очень холиварная тема, и у многих это требование всё равно прописано, так как они стремятся знать обо всех уязвимых пакетах и программном обеспечении в своей инфраструктуре. Цель — сканировать и исправлять всё, чтобы осталось ноль уязвимостей на периметре и внутри. Но в реальности вряд ли кто-нибудь встречал такую инфраструктуру. А у некоторых компаний даже есть термин vulnerability zero tolerance, то есть нулевая толерантность к уязвимостям — их вообще не должно быть. Но, по моему опыту, этого нереально добиться в современном мире.

Обычно это требование обосновывается так:

• Прописано в общем корпоративном стандарте информационной безопасности, составленном несколько лет назад.

• Нужно предотвратить компрометацию нод через известные уязвимости.

Последствия сканирования нод на известную уязвимость:

• Гигантские отчеты об уязвимостях с большим количеством false positive результатов.

Даже если использовать последнюю версию Ubuntu или другой ОС общего назначения, будет около сотни известных уязвимостей, и часть из них окажется ложными срабатываниями. То есть вы ещё ничего не сделали, а уже нужно писать отчёт, почему вы этого делать не будете и что вам это неактуально.

• Огромные временные затраты высокооплачиваемых инженеров.

Приходится тратить много времени на митинги и мало эффективную работу, объяснять, почему исправлений нет, или они неэффективны и неэксплуатируемые, вместо того, чтобы заниматься внедрением специализированной операционной системы. И так, по нашему опыту, буквально каждую неделю. Часто в компаниях даже есть практика еженедельных митингов с обсуждением того, какую уязвимость будем фиксить, а какую не будем. И это, на самом деле, бесконечно бессмысленная задача.

Как это работает в реальности?

• Контейнерные приложения используют пакеты из образа, а не с хоста — ведь окружение контейнизированное.

Все необходимые пакеты, которые используют приложения, уже лежат внутри образа, поэтому достаточно сканировать эти образы. При рассмотрении модели нарушителя: внешний или тот, кто каким-то образом уже попал в контейнер.

• Запуск ПО вне контейнеров на ноде.

Такое ПО правда использует пакеты с хоста. Но это и совсем другой класс проблем. Ведь придётся грамотно рассчитать, какое количество вычислительных ресурсов выделить на неконтейнризированое приложение на ноде Kubernetes. С помощью Node Allocatable для kubelet можно заранее просчитать, сколько будут потреблять все решения не в контейнерах.

Если вы рассчитаете неправильно и укажете неправильно в kubelet, то потратится больше ресурсов. И окажется, что при работе scheduler для kubelet для запуска Pods ресурсов уже и нет. А он продолжит думать, что для его бизнес-нагрузки вычислительные ресурсы в наличии. И, естественно, будет пытаться зайти и запустить как-то иначе. Это может длиться достаточно долго, а приложение не работать!

• На Node кластере и без уязвимостей хватает векторов.

С точки зрения опыта атакующего/аудитора/пентестера могу сказать, что если атакующий попал на ноду, то он уже вас взломал. Пакеты на ноде — это последнее, о чём задумается атакующий для своего продвижения и закрепления. И чтобы использовать из этих хостовых пакетов какие-то уязвимости, ему нужно сбежать из контейнера на ноду или оказаться там каким-то другим способом. Иначе нельзя взаимодействовать с этим кодом пакетов. Поверьте, на ноде достаточно так называемых низко висящих фруктов — более простых уязвимостей и способов, чем какие-то уязвимые пакеты на ноде.

• Container Runtime Socket.

Напрямую обратившись через Container Runtime Socket, можно создать привилегированный контейнер и делать что угодно. Любимая техника всех пентестеров, что попадают на машину с контейнерами.

• Сертификаты, ServiceAccount Token, Envs, секреты, лежащие в переменных окружениях — те же низко висящие фрукты.

За свою пятилетнюю практику анализа защищенности контейнеризированных окружений нам ни разу не приходилось повышать привилегии через уязвимости в пакетах, лежащих на Node. Всегда находилось что-то более интересное, простое и эффективное.

Всегда легче найти другие пути, чем реально уязвимые пакеты, ведь на node ещё надо эксплоит доставить и/или собрать и запустить там. И в этом случае возникает масса вариантов, которые могут выдать злоумышленника.

Развивая данную тему, появление человека на ноде — это нетипичная ситуация. Чаще всего доступ туда запрещён. Даже если есть такая необходимость, то современные версии Kubernetes позволяют непосредственно использовать kubectl debug, который способен дать через контейнер shell на ноде.

• Как правило, разработчики платформ на базе Kubernetes не рассматривают сценариев взаимодействия человека с нодами. Есть специальный Kubernetes оператор, который создаёт специальный custom ресурс и отправляет его в Kubernetes, а затем самостоятельно идёт по нодам. Но человек туда не ходит. Сам Kubernetes — это система не для человека, а для контейнеров. А если у вас там иммутабельная операционная система, то проще ноду потушить, и поднять новую из golden image. Это быстрее и эффективнее, и время инженера будет сэкономлено.

• Не забываем, конечно, что часто продакшн-окружение содержит критическую информации и присутствие там каких-либо специалистов не разрешено без четкого присмотра ИБ.

Что я могу порекомендовать — полезные советы:

1. Создавать и анализировать для своего кластера:

• модель угроз (threat modeling);

• поверхность атаки (attack surface);

• модели нарушителя (threat actors).

Делать это нужно не вслепую, когда отсканировали и исправили. Уязвимости есть всегда, а вы рискуете неэффективно потратить время, выбрав не те. Я считаю, что в современном мире время инженеров нужно тратить разумно, а не на бесконечный фиксинг уязвимости и объяснения, почему это не эксплуатабельно, нерелевантно либо сложно эксплутабельно. Лучше полностью исключить модель нарушителя, атакующего на ноде. И это будет куда эффективнее, а время инженеров направить на полезные задачи.

2. Использовать специализированные контейнерные ОС для хоста: Talos, Flatcar Container Linux, Fedora CoreOS, openSUSE, MicroOS, Bottlerocket, Container-Optimized OS. Это уже обязательно для современной эксплуатации Kubernetes. Приятно, что за последние два года Talos, Flatcar и аналогичные сервисы всё чаще используются в компаниях.

Облачные операторы у Google — это Container Optimized, у Amazone — Battlerocket. Компания-разработчик Flatcar выкуплен у Microsoft.

3. Обновлять ядро ОС.

4. И снова советую посмотреть презентацию «Сочетание несочетаемого в Kubernetes: удобство, производительность, безопасность», HighLoad++ 2022.

Совет 3. Блокировка выкатки образов с чувствительной информацией

Под чувствительной информацией будем понимать различные секреты, токены, сертификаты, пароли внутри образов контенйеров. Важный момент — совет предполагает не допускать именно выкатку таких образов.

Обычно это требование обосновывается так:

• Не допустить утечки критичной информации.

• На validating admission webhook проводят проверку YAML-файлов и при необходимости блокируют выкатку. Можно обращаться к сторонней системе и получить ответ, можно ли выкатить образ. Если хотя бы один из хуков ответит отрицательно, то YAML не выкатиться и не применится. Разработчик получает ответ, что ресурс не применён в кластере.

Последствия блокировки выкатки:

• Срывы релизов. Конечно, мы не хотим, чтобы атакующий получил доступ к чувствительной информации. Если движок обновился сигнатурами и начинает выкатываться, а его заблокировали, релиз сделать невозможно. Причина в том, что в релизе обнаружена строка, напоминающая ключ.

• Продолжение утечки критичной информации. Пока обновление движка блокируется и релиз на стопе, чувствительные данные продолжают утекать, просто через другие каналы.

Как это работает в реальности?

• Критичная информация может находиться в промежуточном слое образа и не попасть в финальный. Если мы рассматриваем кейс, где образ выкатывается, то атакующий получит доступ к этому секрету, если он лежит в верхнем слое либо попал в финальный. Иначе промежуточный он даже не увидит. В runtime для внешнего атакующего информация может быть недоступна.

• Критичная информация в образе уже лежит (раскрыта) в Image registry! При этом нужно понимать, что если мы этот образ выкатываем, он уже лежит в registry, а образ секрета (слой) — тоже лежит в registry. Любой сотрудник с pull доступом может извлечь как весь образ, так и отдельный слой из образа и тем самым скомпрометировать секрет. Это уже инцидент, требующий отзыва и ротации данных. По сути, когда в самом registry появляется образ с критичной информации, нужно заводить инцидент и ротировать данный секрет. То есть ещё до выкладки этого образа в продакшн, а не когда он только пытается выкатиться. Иначе это пустая трата времени. Так мы скорее будем срывать релизы и ставить разработчиков в неудобное положение, чем реально принесем пользу ИБ. 

Что я могу порекомендовать — полезные советы:

1. CI/CD pipeline должен падать при обнаружении чувствительной информации в слоях образа. Сканировать наличие секретов нужно прямо в пайплайне. Если секрет нашёлся, то пайплайн должен быть остановлен, а образ не должен попасть в registry к которому имеет доступ большое количество сотрудников.

2. Процесс CI/CD должен завершаться шагом подписи образа. Я рад, что в последнее время мы всё чаще встречаем эту практику в компаниях. Подпись образа — последняя стадия любого современного пайплайна. Если успешно прошли все анализаторы и сканеры, то в конце образ получите подпись.

3. На validating admission webhook (Policy Engine) должна быть проверка подписи образа. На этапе выкатки на этом webhook необходимо проверить только наличие подписи, подтверждающей, что образ прошёл сертифицированный пайплайн, все сканеры, и пайплайн при этом нигде не упал. Только тогда мы можем его выкатывать. Этот совет — must have в сегодняшнее время.

4. Для повышения безопасности, используйте не один, а несколько registry — это называется registry staging. Обычно один registry делается на dev и test окружение, а второй на stage и prod. 

Совет 4. Блокировка выкатки образов на основании информации об уязвимостях

Также популярно требование не давать выкатываться образам, у которых есть известные уязвимости.

Обычно это требование обосновывается так:

• Не допустить появления в окружении определенных уязвимостей.

• Провести проверку на validating admission webhook и, при необходимости, заблокировать выкатку. Цель кажется благой: мы не хотим, чтобы в нашем окружении появились образы с известными уязвимостями.

Последствия блокировки выкатки образов с известными уязвимостями:

• Деградация приложений.

• Аварийное завершение приложений.

• Отказ в обслуживании.

Как это работает в реальности?

Есть некая инфраструктура, содержащая image registry с образами. Эти образы сканируются на SBOM (Software Bill of Materials). По сути, это такая инвентаризация сторонних библиотек и их версий в вашем ПО (в данном случае в образе). Далее feed об уязвимостях ежедневно обновляется, и там собирается информация, в какой версии, в какой библиотеке, какие известные уязвимости есть. Мы сопоставляем информацию из SBOM с информацией из этого feed. Логика простая: если версия библиотеки ниже определённой, где фикс, значит есть уязвимость.

Давайте рассмотрим идеальную ситуацию: есть Image, в котором ноль уязвимостей. Ещё есть validation web hook, политика которого говорит, что мы не должны разрешать выкатку образов, у которых >= 1 critical и >= 2 high уязвимостей. И по этой политике он не даёт непосредственно выкатиться. Если у образа сейчас в текущий момент нет известных уязвимостей, значит, можно выкатываться.

Создается ReplicaSet с 4 копиями сервиса.

Выкатка прошла успешно, проходит некоторое время и обновляется feed уязвимостей. В котором могут присутствовать новая информация об уязвимостях в наших компонентах. И теперь оказывается, что в образе, который мы выкатили некоторое время назад, уже один Critical, два High и восемь Medium уязвимостей.

И это приложение у нас уже работает в продакшен, в рантайме, выходит в сеть, им пользуются наши клиенты! Но важно понимать, что не существует окружения без уязвимостей. Как бы мы ни хотели, чтобы уязвимости не выкатились, всегда есть окно между выпуском фикса и его выкаткой в продакшен. Часто пока мы делали один фикс, становится нужен уже другой. Умножьте это на количество образов окружений, микросервисов и получите ситуацию, когда окружение всегда содержит уязвимости. Абсолютное отсутствие уязвимостей, это, по мне, абсолютный миф.

Как вы понимаете с таким отчетом об уязвимостях мы бы уже не дали этому образу выкатиться. 

Далее может происходить следующие типичные/штатные ситуации — падают Pods, а set controller говорит, что replica set controller не сходится. Нам нужны четыре реплики, а по факту их меньше. Причин много: аварийно завершился, упала нода и вместе с ней завершили поды, нода обновилась, произошёл переезд подов, вытеснение одних нагрузок другими и т.д. Ситуаций, почему Pod завершился, и количество не стало сходиться с репликой, действительно много.

Получается следующее:

Одна копия работает в runtime, а три — нет. Их надо выкатить. Опять validation admission web hook с той же политикой в отношении critical и high. Выкатка запрещена! Kubernetes про это вообще не в курсе. Его задача, чтобы replica set controller отработал и сделал желаемое количество реплик и они были одинаковыми. А если у вас из-за наплыва нагрузки в сезон распродаж пришло пиковое значение в 100 000 пользователей, то надо масштабироваться, и нужны уже не четыре копии этого микросервиса, а пару десятков. Но они не выкатываются.

Приложение не выдерживает нагрузки, начинает падать, деградировать. За этим могут последовать и другие сервисы. Один не отвечает, другой копит очередь, а из-за того, что очередь уже переполнена, тоже становится плохо. И постепенно в зависимости от логики приложения вся система начинает падать. Вроде бы пришли с благой целью — не допускать выкатки уязвимых образов в рантайм, но, на самом деле, уронили приложение, деградировали систему и так далее.

И когда люди с этим сталкиваются, первое время кажется, что это классная фича, но потом понимают, что такую практику лучше не использовать. Я встречал кейсы, когда IT-отдел соглашается при условии разделения рисков c ИБ. Но ИБ обычно не соглашается разделять ответственность за риски падений поровну. И нужно ещё потом доказать, что это не средство безопасности сделало.

Что я могу порекомендовать — полезные советы:

1. Нужно знать обо всех уязвимостях не только на выкатке, а в любой момент времени. Не давать образам выкатываться с известными уязвимостями — это всего лишь странная полумера. Потому что всё равно при обновлении feed эти приложения уже работают в вашем окружении. И уже содержат уязвимости, и уже скорее всего доступны атакующему. Поэтому нужно строить безопасность с учётом того, что у вас в любой момент времени известные уязвимости будут работать в продакшене. Вспомните ситуацию непосредственно с log4j.

2. Уменьшайте поверхность атаки. Стройте окружение с учетом подходов к уменьшению поверхности атаки. Так, чтобы если даже у вас есть уязвимое приложение, то эксплуатируя эту уязвимость атакующий не мог нанести вред компании.

3. Используйте Distroless-образы, минималистичные образы и т.д.

4. Стройте ZeroTrust.

5. Используйте NetworkPolicy, AppArmor и т.д.

6. Посмотрите презентацию «SCAзка о SCAнерах», Positive Hack Days 12.

7. Посмотрите презентацию «Patch management не поможет, фиксики не спасут».

В этой статье мы познакомились далеко не со всеми «вредными» рекомендациями. Ещё можно вспомнить про:

• установку N штук агентских средств ИБ на Node;

• множество блокирующих admission controllers;

• повсеместную блокировку на Policy Engines;

• написание Network Policy вручную или на текущих данных network flow;

• использование blacklist-правил для Runtime Security с автоматической реакцией;

• …

В каждом из этих пунктов есть свои опасные подводные камни.

Выводы

Перечисленных мной «вредных» кейсов можно отыскать множество. И, хотя кажутся классными и должны помогать безопасности, на самом деле они малоэффективны или могут нанести ущерб окружению, которое должны защищать. Как сказал мой хороший товарищ, задача безопасности не в том, чтобы в окружении не было уязвимостей, а том, чтобы окружение стабильно работало и оставалось доступным, а бизнес зарабатывал деньги.

Когда безопасность приносит больше вреда и приводит к простоям систем — это не про защиту. Особенно если вы ещё и не понимаете первопричину сбоя. На разбирательства уходят часы отладки, траблшутинга. И всё это время клиентам недоступны оплаты или другие операции — а это ущерб и финансовые потери.

Очень важно учитывать особенности Kubernetes. Это очень специфичная система, у которой нет аналогов. Использование методов и подходов, привычных для Windows и Linux — в корне ошибочно. Можно набить болезненные шишки и навредить всей компании несмотря на благие намерения. Поэтому так важно выдерживать разумную грань между безопасностью и надёжностью эксплуатации. Они должны не противоречить друг другу, а помогать.