SecK8S: от хаоса к системе
Проблема безопасности Kubernetes часто не в нехватке средств защиты, а в хаосе вокруг них. Десятки решений, разрозненные процессы и размытая ответственность делают защиту несистемной. В этом докладе разберём, как навести порядок в сложной инфраструктуре:
- какую зону ответственности должна брать на себя команда ИБ;
- какие процессы действительно работают в масштабе;
- какие компетенции нужны, чтобы это поддерживать.
Также покажу практический подход к сборке команды безопасности K8S как конструктора: зона ответственности — процессы — компетенции — структура команды.
Зачем бизнесу нужна отдельная команда защиты Kubernetes?
С каждым днем растет проникновение Kubernetes систем как в коммерческие, так и государственные компании, организации. Контейнерные системы становятся целевым и /или более значимым местом размещения нагрузок. При этом команды безопасности этих компаний нередко не различают разницы между защитой виртуальных и контейнерных сред. В докладе мы ответим на вопрос зачем бизнесу отдельная команда защиты Kubernetes и обсудим основные цели этой команды.
Фреймворк JCSF: zero to hero в контейнерах
Контейнеризация стала стандартом де-факто для современных приложений, но безопасность контейнерных сред нередко остаётся зоной хаотичных точечных решений. Ведь из одних и тех же кирпичей можно построить разное по функционалу и этажности здание. Погрузимся в повесть о том, как мы прошли путь от «закрываем уязвимости по мере поступления» до системного подхода и как появился фреймворк оценки и построения безопасности сред контейнеризации JCSF
Дмитрий Селезнев | Инфосистемы Джет
Как не убить кластер и безопасность исключениями
К каждому безопаснику, который занимается k8s, рано или поздно приходят с просьбой добавить исключений в защитные меры. Разбираемся, как сделать так, чтобы кластеры не пострадали, а бизнес смог эффективно решать свои задачи.
Валерий Кунавин | Ozon Банк
ФСТЭК и контейнеры: от заявки до сертификата
В этом докладе будут разобраны проблемы и решения для прохождения сертификации контейнеризированных приложений, как со стороны регулятора, так и со стороны разработчика СЗИ. Будут рассмотрены аспекты организации документации, процессов взаимодействия внутри команды и тулинга, а в конце доклада будет представлен публичный pipeline от которого можно будет оттолкнуться тем, кто готовится или только начинает свой пусть для сертификации СЗИ.
«Оператор Всевластия» для разработки распределенных систем и управления сетевой безопасностью
В распределенных системах ручной контроль интеграционных взаимодействий невозможен. Мы покажем, как с помощью Platform Engineering и Shift Left создать процесс разработки, который автоматически генерирует необходимые NetworkPolicy и прочие настройки безопасности.
Одна упрощенная абстракция заменяет десятки разрозненных конфигураций, гарантируя соблюдение стандартов разработки и ИБ без лишних усилий со стороны продуктовых команд.
Контроль целостности в Kubernetes по взрослому
Пройдёмся от подписи образа в CI до runtime-проверки содержимого работающих контейнеров внутри containerd v2. Вы узнаете, как можно построить работающую цепочку доверия для контейнеров, какие точки интеграции есть в containerd и Kubernetes, и как защититься не только от подмены образов, но и от атак на уже запущенные рабочие нагрузки.
GitOps: мозг для политик безопасности
Разберём, как выстроить централизованное управление политиками безопасности Kubernetes, когда кластеров действительно много — на реальном кейсе крупного банка: ArgoCD + Gatekeeper + Vault, иерархия зон через лейблы, минимальные права на внешних кластерах и гранулярные исключения в Rego — и всё это под мониторингом в Grafana.
Validating Admission Policy замена Policy Engine?
Ваш веб-хук — это ахиллесова пята кластера.
Он тормозит, падает, требует сертификатов и мониторинга, выбора между безопасностью и доступностью. VAP — это момент, когда k8s наконец-то говорит: «Ребята, я сам справлюсь». Потому что теперь политики исполняются прямо в API-сервере. Разбираемся, где проходит граница между «достаточно VAP» и «без веб-хука не обойтись».
Контейнеры против майнеров или история по криптоджекинг в Kubernetes
Доклад посвящен практической защите контейнеров от криптоджекинга. Будут рассмотрены основные сценарии попадания майнеров в контейнерную среду, типовые ошибки конфигурации и ограничения инструментов защиты. На примерах будет показано, как комбинировать защиту образов, безопасность рантайма, сетевые политики, мониторинг и контроль цепочки поставок для выявления и противодействия криптоджекингу.
Максим Князев | К2 Кибербезопасность
Большинство команд безопасности понимают, что использование минимальной контейнерной ОС для K8s это обеспечение минимальной поверхности атаки в прод-окружении. Но не всегда в современной ситуации мы можем себе позволить использовать зарубежные решения для реализации инфраструктуры на контейнерных ОС.
Поэтому в докладе мы покажем путь, который прошли при создании первой отечественной версии контейнерной ОС ALT Orchestra, созданной на основе Talos Linux. Расскажем о проблемах с которыми столкнулись на пути и как их решили, а также поможем понять как жить с контейнерной ОС с точки зрения жизненного цикла нашей инфраструктуры.
Российская реализация ОС Talos
Контейнеры под защитой PARSEC: пополнение в рядах AppArmor, SELinux
Пройдем путь от назначения и задач SeLinux, AppArmor до внутренностей containerd и runc для внедрения своего мандатного контроля доступа для контейнеров на примере PARSEC.
Истории Kubernetes пентестов: путь через мисконфигурации
Вторая часть доклада про Kubernetes пентесты, в которой будут рассмотрены мисконфигурации в Kubernetes, которые приводят как к побегам из контейнеров так и полному захвату кластера и целых групп кластеров.
В докладе на реальных примерах мы покажем, как из стандартной Java сделать легковесного и безопасного обитателя контейнерной экосистемы. Пройдём все этапы: от выбора безопасного базового образа и сборки кастомного JRE до настройки JVM внутри контейнера.
Отдельно рассмотрим ускорение старта с AppCDS и Native Image, а также построение верифицируемой цепочки поставки (SBOM, подписи, VEX). В итоге вы получите готовый чек-лист из 12 шагов для создания образа, который выдерживает проверки сканеров уязвимостей и устойчив к атакам изнутри контейнера.
SSLSA — язык доверия: от CI до Runtime
Мы уже умеем собирать контейнеры в CI/CD, сканировать их на уязвимости и нередко подписывать. Но эти практики редко складываются в одну проверяемую цепочку доверия: кто собрал артефакт, из чего, в какой среде и где это проверяется перед запуском.
На примере компрометации Trivy и практического пути от L1 до runtime enforcement разберем, как SLSA помогает платформе и ИБ говорить об одном и том же — происхождении, подлинности и policy enforcement.