DevSecOps Talks

Всем привет! В repo доступна ссылка на Container Security Checklist от Carol Valencia, участницы команды Aqua Security. Подборка сделана с привязкой к жизненному циклу контейнера и покрывает аспекты ИБ, значимые как при создании образа, так и при последующей его эксплуатации в качестве контейнера (workload). Подборка структурирована по категориям: 🍭 Secure the Build. Повышение защищенности образов во время сборки, использование Hadolint для проверки Dockerfile, сканирование образов на наличие уязвимостей, подпись образов 🍭 Secure the Container Registry. Использование private registry, управление доступом с использованием RBAC 🍭 Secure the Container Runtime. Настройка runtime в соответствии с лучшими практиками (CIS Benchmark) 🍭 Secure the Infrastructure. Управление уязвимостями и обновлениями для хостов, настройка хостов в соответствии с рекомендациями CIS Benchmark 🍭 Secure the Data. Контроль доступа к файловой системе, корректная инъекция секретов 🍭 Secure the Workloads. Контроль действий контейнеров, применение практик контроля drift prevention для обеспечения неизменяемости (immutable) контейнеров Подборка содержит как общие советы по информационной безопасности, так и вполне конкретные действия. Также можно найти ссылки на open source инструменты и статьи, которые могут быть использованы для выполнения ряда требований

Привет! Хорошая обзорная статья про Persistent Volume и как его настроить. Каждый pod, по умолчанию, потеряет данные после того, как будет воссоздан заново. Для того, чтобы исправить это используются механизмы Volume (грубо говоря – папку на worker node) и Persistent Volume. Именно о вторых и пойдет речь в статье: 🍭 Что такое Persistent Volume (PV) и принципы его работы 🍭 В чем разница между Storage Class, Persistent Volume и Persistent Volume Claim 🍭 Режимы доступа (Access Modes): ROX, RWO, RWX, RWOP. Приводится краткое описание каждого режима доступа 🍭 Описание процесса выделения дискового пространства pod’у: выбор подходящего Storage Class, определение требуемого объема памяти (Persistent Volume), создание Persistent Volume Claim, чтобы у pod была возможность использования внешнего хранилища данных В завершении статьи приводится пример того, как это можно реализовать. Как всегда, с кодом, командами и небольшими пояснениями ☺️

Привет! Написание RBAC правил в Kubernetes не самое увлекательное занятие, в котором можно легко запутаться. Иногда хочется некоторого полиморфизма – «Мне нужна почти такая же роль, только с перламутровыми пуговицами с немного иными привилегиями…». И все заново – перечисляем ресурсы, права… Можно ли как-то иначе? Оказывается, можно! С проектом от Red Hat, который называется Dynamic RBAC-operator. Он как раз дает тот самый полиморфизм: мы указываем «родительскую» роль и на базе нее создаем нужную нам, внося небольшие правки и корректировки. В repo есть отличный пример создания роли «admin-without-users», наследованной от «cluster-admin», но с некоторыми отличиями ☺️

Привет! В продолжение темы проверки K8S-манифестов представляем kube-review! Небольшую утилиту, которая используется для трансформации манифеста в… AdmissionReview Request! Это может быть удобно для локального тестирования манифестов, без необходимости обращения к Kubernetes API. Можно тестировать: 🍭 Манифесты локально, в том числе с использованием OPA (kube-review... | opa eval...). Есть альтернативный вариант локального использования OPA, о нем мы писали тут 🍭 Манифесты, использованные для запуска сущностей на кластере (kubectl get pod -o yaml | kube-review... | opa eval...) Таким образом можно сделать небольшой инструмент аудита, в том числе уже запущенных сущностей. Подобный функционал есть и у Gatekeeper/Kyverno, но kube-review может быть попроще для начала (например, потому что не требуется создание и настройка дополнительных сущностей в кластере) Единственное, что не поддерживается kube-review – это CRD

Всем привет! В статье описывается интересный подход к созданию набора OPA-проверок, которые формируются на основании входных данных. Суть проста – у нас есть n проверок по различным группам, например, storage, network, compute, security и т.д. Скорее всего, за каждый тип проверок отвечают разные команды и разные люди. Как быть в такой ситуации? Писать единое «полотно» с указанием всевозможных проверок по группам? И так для каждого приложения? А если их много? Вероятно, такой подход не является самым оптимальным и правильным. В статье предлагается рассмотреть альтернативный подход – каждая команда создает свои проверки и создается общий main-файл, который возьмет на себя роль «роутера» и позволит перенаправлять запросы и получать обратную связь по проверкам. Это придаст гибкость и повысит управляемость использования OPA-проверок. Небольшой пример описанного концепта приводится в статье ☺️

Всем привет! Linux Capabilities – не самая простая, но очень интересная тема. Можно даже немного почувствовать себя исследователем и разобраться какому процессу/файлу какие привилегии (полномочия) нужны. В цикле статей Автор простыми словами рассказывает про то, что это такое: первая часть теоретическая, а вторая – практическая (много примеров, в том числе про то, как читать и понимать вывод утилит, помогающих идентифицировать capabilities). В статьях Автор рассматривает такие аспекты, как: 🍭 Типы capabilities: effective, inherited, permit, ambient и bounding; основные отличия между ними 🍭 Как происходит определение итогового перечня capabilities дочернего (нового) процесса. Автор показывает, как это работает на примере ping. Кстати, если Вы не знали, то ping не совсем прост и обладает интересными особенностями ☺️ Если тема интересна, то рекомендуем держать рядом с собой man на capabilities открытым, т.к. Автор к нему часто отсылается. Управление capabilities, в том числе, может быть использовано для повышения ИБ сред контейнерной оркестрации. Наглядно об этом можно посмотреть в статье и интерактивном уроке от SNYK: 🍭 Container does not drop all default capabilities 🍭 Kubernetes securityContext: Linux capabilities in Kubernetes P.S. Preview работает только для первой статьи, но мы рекомендуем прочитать обе ☺️

Всем привет! Небольшая статья о том, как Citi сделали Secure Software Factory. В качестве основы они выбрали «Software Supply Chain Best Practices» и «The Secure Software Factory». Оба документа содержат интересные мысли по теме и там есть, что почитать (каждый ~ 20 страниц). В итоге получился следующий конструктор: 🍭 Подпись с использованием Sigstore Cosign 🍭 Автоматизация Pipeline: Tekton – Pipelines и Chains 🍭 Admission Controller – Kyverno 🍭 Identity Attestation – Spire 🍭 Оркестрация контейнеров – Kubernetes С деталями и Quick Start Guide можно ознакомиться по ссылке ☺️

Привет! Очень-очень большая статья, посвященная теме управления секретами (~21 минута, если верить Medium). Да, она 2018 года, но все равно многое из того, что в ней написано актуально и по сей день. В начале статьи приводится проблематика, с которой можно столкнуться: как для «классического ИТ», так и для Cloud и DevOps-окружений. Отдельно хочется выделить часть статьи, в которой описано с какими сложностями столкнулись компании (Pinterest, Square) и почему они решили разработать собственные инструменты (Knox, Keywhiz). Далее идет обзор-перечисление open source решений, которые могут быть использованы: Torus, Credstash, Sneaker и другие. В завершении – описаны возможности поставщиков облачных услуг и размышления на тему вызовов информационной безопасности, с которыми можно столкнуться, погружаясь в тему управления секретами.

Привет! Сайт, посвященный RBAC Kubernetes. Все удобно сгруппировано по разделам: 🍭 Официальная документация Kubernetes 🍭 Статьи, посвященные RBAC 🍭 Средства автоматизации В части автоматизации есть интересное деление – можно выбрать утилиты для проведения аудита настроек RBAC кластера (KubiScan, Krane). Другие утилиты позволяют упростить взаимодействие с Kubernetes для получения информации о возможностях учетных записей и ролей (kubectl-who-can, rakkess). Задача третьих – визуализировать управление доступом (rback-view, rbac). P.S. А вы знали, что при помощи RBAC можно тренировать дельфинов? ☺️ P.P.S. Preview не работает, поэтому дублируем ссылку: https://rbac.dev/

Всем привет! Небольшое демо по использованию Cosign – инструмента генерации и проверки электронной подписи для образов контейнеров. Подобные практики можно использовать для противодействия supply chain атакам – гарантировать, что запускаются только доверенные и подписанные образы. Демо описывает следующий процесс: 🍭 Установка Cosign 🍭 Генерация ключевой пары – закрытый и открытый ключи 🍭 Подпись образа с использованием закрытого ключа 🍭 Помещение образа вместе с подписью в Container Registry 🍭 Использование открытого ключа для верификации подписи образа Помимо указанного в демо приводится пример подписи Software Bill of Materials (SBOM). Сама SBOM генерируется при помощи Syft (о нем мы писали ранее) и подписывается при помощи Cosign.

Всем привет! Ребята из Apiiro Security Research Team обнаружили уязвимость CVE-2022-24348 в ArgoCD. Эксплуатация уязвимости позволяет злоумышленнику получить доступ к чувствительной информации, такой как секреты, пароли и API-ключи. Attack Flow состоит из нескольких этапов: 🍭 Злоумышленник подготавливает malicious Helm chart 🍭 Через использование parsing confusion уязвимости получает доступ к чувствительной информации. Эта уязвимость связана с особенностями разбора (parsing) Values-файлов 🍭 Извлекает необходимые ему данные, которые он может использовать для последующих атак Для реализации подобной атаки необходимо обладать правами на создание и/или обновление Applications в ArgoCD. Чтобы понять, подвержена ли ваша инсталляция этой уязвимости можно использовать, например Kubescape. Устранение уязвимости осуществляется путем установки обновления, доступного для версий 2.3.0, 2.2.4, 2.1.9.

Всех с пятницей! Продолжение статьи про Observeability! В предыдущий раз Автор закончил на том, что подготовил Prometheus и начал собирать метрики. Тема второй статьи – Alerts и их обработка. Задачу, условно, можно разделить на два блока: 🍭 Написание Alert Rules, определяющих, когда необходимо «подать сигнал» 🍭 Настройка Alert Manager, который определяет, что делать с Alert и за то, куда его можно направить Далее описывается как создать свое собственное правило и про правила, доступные «из коробки» при установке Prometheus. Рассматриваются примеры настройки Alert Manager для группировки аналогичных Alert (чтобы, не «DDoS-ить» команду поддержки) и самое интересное – интеграция со Slack для быстрого и удобного получения уведомлений! Все материалы, которые использовал Автор, можно найти в repo. P.S. Всем хорошего отдыха! Не болейте! ☺️

Всем привет! Представьте что вам необходимо произвести настройку нескольких тысяч единиц оборудования! Как это сделать? 🤔 На помощь приходит функционал Zero Touch Provisioning В статье расшифровывается понятие Zero Touch Provisioning и какие преимущества это даёт. Вкратце: 🍉 Автоматическое разворачивание ПО с типовой конфигурацией на удалённом оборудовании с применением GitOps-практик 🍉 Обновление конфигурации в 2 клика 🍉 Шаблонизация параметров 🍉 Централизованное управление

Привет! Подборка инструментов по анализу исходного кода (SAST), сгруппированная по языкам программирования. В подборке есть: 🍭 Open Source инструменты 🍭 Enterprise-решения, отмеченные символом ©️ Перечень языков, для которых приведены инструменты анализа достаточно большой: С, С++, С#, DART, Go, Java, JavaScript, PHP, Python и многие другие. Подборка может быть полезна в качестве «отправной точки» при выборе потенциального средства анализа исходного кода для конкретного языка. Судя по commit, repo периодически обновляется и поддерживается в около-актуальном состоянии. Рекомендуем прочитать обозначения в repo. Они показывают Enterprise-версии (о чем писали выше); решения, НЕ рекомендованные community и решения, которые не обновлялись длительное время.

Привет! Одно из определений Observability заключается в измерении того, насколько хорошо работает система путем анализа ее (системы) выходных данных. Это подводит к нескольким вопросам: Какие именно данные надо собирать? При помощи чего это можно делать? В статье автор размышляет на тему 3-х основных «столпов», которые можно и нужно исследовать: Metrics, Traces и Logs. Для примера он использует Prometheus, который, de facto, является стандартом мониторинга сред контейнерной оркестрации. В статье рассматриваются такие моменты как: 🍭 Общий взгляд на Prometheus и его компоненты, как установить (helm-чарты, операторы и т.д.) 🍭 Получение первичных данных (например, аналитика kube-state-metrics) 🍭 Сбор метрик с использованием Client и Exporters 🍭 Использование PromQL (Prometheus Query Language) для создание собственных запросов В качестве «подопытного» для рассмотрения описанных выше концептов, используется небольшое приложение, состоящее из 3-х блоков: People Service («забирает» данные из MySQL базы данных), Format Service (обработка данных, полученных от People Service) и Hello Service (предоставление отформатированных данных пользователю). На примере вышеописанного приложения демонстрируется, как можно собирать метрики из различных его компонент

Всем привет! По ссылке доступен базовый tutorial, описывающий установку ArgoCD и ключевые возможности этой системы. Сперва рассматривается установка ArgoCD и создание первого “Application”: приводятся примеры manifest с кратким описанием наиболее важных параметров. Далее на небольшом примере рассматриваются ключевые возможности ArgoCD: 🍭 Synchronize с GitHub (можно использовать не только GitHub, просто он приводится в самой статье) 🍭 Изменение manifest приложения, App Diff который покажет, что именно было изменено 🍭 Различные параметры настройки политики синхронизации ArgoCD (sync policy) 🍭 Механизмы History и Rollback Все это с наглядными примерами, исходным кодом и screenshots итоговых результатов, которые должны получиться 😊

Всем пятница! Еще одна REGO-библиотека с правилами для анализа сущностей, запускаемых в среде контейнерной оркестрации. Еще одна, да не совсем! Ребята из ARMO проделали отличную работу и сделали mapping проверок на MITRE ATT&CK. Практически по всем доменам доступны проверки: 🍭 Initial access 🍭 Execution 🍭 Persistence 🍭 Privilege Escalation 🍭 Defense Evasion 🍭 Credential Access 🍭 Discovery 🍭 Lateral Movement 🍭 Collection 🍭 Impact Получился достаточно интересный материал ☺️ P.S. Желаем всем отличного вечера пятницы, теплых выходных и не болейте!

Всем привет! Моделирование угроз в Kubernetes задачка не самая простая, но точно интересная! В статье ребята рассуждает на тему того, что может пригодиться при ее решении: 🍭 Методика – в качестве нее авторы выбрали известный STRIDE 🍭 Средство автоматизации – Threat Modeler от Microsoft, MS TM (к которому ребята сделали template с «Kubernetes-тематикой») 🍭 Пример – можно посмотреть наработки для KubeArmor. Примеры для KubeArmor и template для MS TM расположены в repo В статье нет инструкций о том, как проводить моделирование угроз. В не содержатся справочная информация о том, какие практики можно использовать и какие средства автоматизации применять. С примером отчета, который генерируется упоминаемым в статье инструментом, можно ознакомиться по ссылке

Всем привет! Функционал Admission Controller очень значим, как минимум, для ИБ-специалистов. Он позволяет контролировать запуск только тех сущностей, которые соответствуют требованиям по ИБ компании и позволяет повысить общий уровень защищенности сред контейнерной оркестрации. Но кто будет охранять охранников? И как сделать так, чтобы Admission Controller был внедрен корректно и безопасно? Ответы на эти вопросы можно найти в небольшой статье, доступной по ссылке. Автор выделяет 2 условные группы: защита webhook и корректная настройка кластера при использовании webhook. Описаны такие контроли, как: 🍭 Настройка TLS между Admission и API Server 🍭 Обработка только аутентифицированных запросов 🍭 Максимально возможный контроль и ограничение запуска privileged-нагрузок 🍭 Использование отдельных webhook для каждого кластера (при использовании более 1) 🍭 Запрет запуска нагрузок в случае недоступности webhook (мера, которая подойдет далеко не всем, суть ее заключается в защите от обхода webhook) и т.д. Если тема вам интересна, то можно ознакомиться с результатами моделирования угроз для Admission Controller, которое осуществляла SIG Security ☺️