C Наступающим!!!

Этот год был непростым… Год получился очень насыщенным и интересным, тематика DevSecOps еще активнее начала развиваться на рынке РФ, что не может не радовать!

Надеемся, что в следующем году будет еще больше интересных тем для обсуждения, больше очных встреч community (не знаем как вам, но нам тоскливо без теплого лампового личного общения) и, конечно же, больше DevSecOps во всех его проявлениях!

Спасибо за то, что вы с нами, за обратную связь!!! Надеемся, что наши посты вам интересны и приносят некоторую пользу. А если чего-то не хватает – пишите в комментариях ☺️

Желаем вам, чтобы Новогодняя Ночь была воистину чудесной, здоровья вам и ваших близким!!! И пусть новый год принесет радость и удовольствие!!!

Спасибо и до встречи в Новом Году!!! - Ваша команда Jet DevSecOps Team ☺️

Всем привет!

Хорошая обзорная статья на тему ServiceMesh, в которой кратко описано назначение – управление трафиком между приложениями через создание mesh-сети и выгоды от использования подобной технологии:
🍭 Управление трафиком (например, dynamic service discovery и routing)
🍭 Повышение observability (ServiceMesh «видит» весь трафик и поможет в сборе большого количества метрик, необходимых для понимания общего состояния сети или при поиске ошибок)
🍭 Усиление информационной безопасности (mutual TLS, сетевое сегментирование)

Указанный выше перечень далеко не полный и сильно зависит от выбранной ServiceMesh технологии, а также от ее конкретной реализации.

Далее в статье приводится небольшой обзор Istio – из чего она состоит, зачем и как использует sidecar, как всем этим управлять через Istio Control Plane, кратко описывается функционал решения. А в завершении – как установить и немного примеров использования ☺️

Всем привет!

ThreatMapper – проект DeepFence, который позволяет визуализировать то, что запущено на кластере и проводить анализ уязвимостей. Получается некоторое объединение Observeability и Vulnerability Management.

Можно посмотреть общую информацию о среде:
🍭 Взаимосвязь объектов между собой
🍭 Информацию о сетевых взаимодействиях
🍭 Информацию о запущенных процессах
🍭 Metadata запущенных workloads

С уязвимостями чуть интереснее: у проекта есть отличительная особенность (например, от Trivy, которая просто предоставляет информацию об уязвимостях) – приоритизация уязвимостей на основании Risk-Of-Exploit. ThreatMapper предоставляет сведения о пути атаки (Attack Path) на основании информации об уязвимостях.

Доступны интеграции с Registry, Notification, Issue Management и SIEM системами.

Можно посмотреть на инструмент «в деле»: надо просто перейти по ссылке и аутентифицироваться (community@deepfence.io / mzHAmWa!89zRD$KMIZ@ot4SiO)

В git repo проекта есть небольшой обзорный ролик, в котором кратко представлен ключевой функционал решения ☺️

Привет!

Kubernetes сам по себе не собирает информацию о том, что происходит внутри pods. Для того, чтобы повысить observability и иметь удобный инструмент для поиска проблем необходимо самостоятельно настроить логирование событий и их последующую обработку.

Сделать это можно несколькими способами:
🍭 Установка Logging Agent на Node. Как правило, он ставится в качестве DaemonSet. Настраивается mount для pod/logging agent в директорию на node, куда попадают logs. Далее агент направляет их в соответствующий backend для обработки. Примером такого agent может быть FluentD, backend – ElasticSearch
🍭 Использование Sidecar Logging Agent. Иногда pod может писать logs только в определенные файлы. Как раз тут и может потребоваться sidecar – он перенаправляет данные из указанного файла в stdout/stderr. Далее схема ничем не отличается от вышеописанного варианта
🍭 Sidecar Logging Backend. Нечто среднее между описанными вариантами: установка agent на node не требуется, логи направляются в logging backend силами sidecar logging agent

Единственно правильного ответа на вопрос – «А какой вариант лучше?» - не существует. Все будет зависеть от приложения и от политик обработки логов отдельно взятой Компании. Бывают случаи, когда Компании используют сразу несколько из вышеописанных подходов

Всем привет!

Если вы всегда хотели знать, в чем разница между mono и poly repo, но боялись спросить, то эта статья для вас!

Автор кратко описывает что это такое:
🍭 Mono repo: единый repo для всех проектов
🍭 Poly repo: отдельный repo для каждого проекта

Казалось бы, все просто и зачем писать статьи про разницу этих подходов? Однако, она (разница) есть и достаточно ощутимая. В статье есть удобная таблица, в которой собраны ключевые отличия Mono/Poly Repo по таким критериям, как: Projects, Workflows, Changes, Testing, Releases и т.д.

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

Для ИБ-специалистов разница тоже есть – от того, как именно будут встроены проверки по ИБ до управления доступом специалистов к проектам: либо доступ дается ко всему (mono repo), либо доступом можно управлять на уровне отдельно взятого проекта (poly repo). Да, некоторые системы позволяют управлять доступом на ownership к отдельным папкам, но все-таки это труднее реализовать и поддерживать, чем доступ к проекту

Всем пятница!

Самое время подумать о грядущих выходных, сладком сне и том, как сломать кластер! Да, вы угадали! Речь снова пойдет о Chaos Engineering!

На этот раз о проекте Kube-Chaos – интерактивной «игре», использующей возможности Unity для элегантной и веселой «поломки» кластера.

Что потребуется:
🍭 Настроенная kubectl с корректным context
🍭 Namespace, который нам не жалко
🍭 Достаточно ресурсов для запуска (как писали выше – используется Unity, это не совсем «утилита», а игровой движок)

Все! Можно ломать, а если ломать не хочется, но хочется посмотреть, как это выглядит – в ссылке на repo можно найти демонстрационный ролик ☺️

Если хочется чуть больше узнать про историю проекта, про то, как Автор совместил 2 своих хобби – game dev и Kubernetes – рекомендуем прочитать вот эту статью.

P.S. Всем отличного вечера пятницы и наипрекраснейших выходных!!!

Всем привет!

Вопросы, связанные с Observeability, все чаще поднимаются при обсуждении Kubernetes. Возможно, именно поэтому ребята решили сделать tobs – инструмент, задача которого крайне проста: максимально простое и быстрое внедрение Observeability Stack в кластер Kubernetes.

По факту, tobs состоит из нескольких open source инструментов (приведены не все):
🍭 Prometheus – сбор метрик, фактически стандарт отрасли по мониторингу
🍭 AlertManager – создание уведомлений и alert
🍭 Grafana – визуализация
🍭 Node-exporter – экспорт метрик с nodes
🍭 Kube-State-Metrics – получение метрик от kube-apiserver
🍭 Promscale – долгосрочное хранение данных по метрикам для аналитики с PromQL и SQL
🍭 Promlens – быстрый и простой способ управления PromQL-запросами

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

Для установки потребуется скачать cli и следовать дальнейшим инструкциям. Небольшой overview ролик доступен по ссылке.

Всем привет!

Некий аналог awesome, но на этот раз чуть более интерактивный – Houdini: перечень образов для offensive security.

Добавить решение в перечень может кто угодно, главное:
🍭 Указать наименование инструмента
🍭 Предоставить ссылку на образ
🍭 Указать ссылку на документацию
🍭 Добавить вид «run-команды» и кратко описать решение!

На текущий момент в базе уже содержится большое количество инструментов (посмотреть их можно в директории tools).

Они удобно структурированы по группам: recon, reverse, cracker, backdoor и т.д.

Посмотреть на web интерфейс Houdini можно по ссылке.

Всем привет!

Функционал Admission Controller очень значим, как минимум, для ИБ-специалистов. Он позволяет контролировать запуск только тех сущностей, которые соответствуют требованиям по ИБ компании и позволяет повысить общий уровень защищенности сред контейнерной оркестрации.

Но кто будет охранять охранников? И как сделать так, чтобы Admission Controller был внедрен корректно и безопасно?

Ответы на эти вопросы можно найти в небольшой статье, доступной по ссылке. Автор выделяет 2 условные группы: защита webhook и корректная настройка кластера при использовании webhook.

Описаны такие контроли, как:
🍭 Настройка TLS между Admission и API Server
🍭 Обработка только аутентифицированных запросов
🍭 Максимально возможный контроль и ограничение запуска privileged-нагрузок
🍭 Использование отдельных webhook для каждого кластера (при использовании более 1)
🍭 Запрет запуска нагрузок в случае недоступности webhook (мера, которая подойдет далеко не всем, суть ее заключается в защите от обхода webhook) и т.д.

Если тема вам интересна, то можно ознакомиться с результатами моделирования угроз для Admission Controller, которое осуществляла SIG Security ☺️

Всем привет!

Моделирование угроз в Kubernetes задачка не самая простая, но точно интересная!

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

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

Всем пятница!

Еще одна REGO-библиотека с правилами для анализа сущностей, запускаемых в среде контейнерной оркестрации.

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

Получился достаточно интересный материал ☺️

P.S. Желаем всем отличного вечера пятницы, теплых выходных и не болейте!

Всем привет!

По ссылке доступен базовый tutorial, описывающий установку ArgoCD и ключевые возможности этой системы.

Сперва рассматривается установка ArgoCD и создание первого “Application”: приводятся примеры manifest с кратким описанием наиболее важных параметров.

Далее на небольшом примере рассматриваются ключевые возможности ArgoCD:
🍭 Synchronize с GitHub (можно использовать не только GitHub, просто он приводится в самой статье)
🍭 Изменение manifest приложения, App Diff который покажет, что именно было изменено
🍭 Различные параметры настройки политики синхронизации ArgoCD (sync policy)
🍭 Механизмы History и Rollback

Все это с наглядными примерами, исходным кодом и screenshots итоговых результатов, которые должны получиться 😊

Привет!

Одно из определений 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 (предоставление отформатированных данных пользователю).

На примере вышеописанного приложения демонстрируется, как можно собирать метрики из различных его компонент

Привет!

Подборка инструментов по анализу исходного кода (SAST), сгруппированная по языкам программирования.

В подборке есть:
🍭 Open Source инструменты
🍭 Enterprise-решения, отмеченные символом ©️

Перечень языков, для которых приведены инструменты анализа достаточно большой: С, С++, С#, DART, Go, Java, JavaScript, PHP, Python и многие другие.

Подборка может быть полезна в качестве «отправной точки» при выборе потенциального средства анализа исходного кода для конкретного языка. Судя по commit, repo периодически обновляется и поддерживается в около-актуальном состоянии.

Рекомендуем прочитать обозначения в repo. Они показывают Enterprise-версии (о чем писали выше); решения, НЕ рекомендованные community и решения, которые не обновлялись длительное время.

Всем привет!

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

🍉 Автоматическое разворачивание ПО с типовой конфигурацией на удалённом оборудовании с применением GitOps-практик
🍉 Обновление конфигурации в 2 клика
🍉 Шаблонизация параметров
🍉 Централизованное управление

Всех с пятницей!

Продолжение статьи про Observeability! В предыдущий раз Автор закончил на том, что подготовил Prometheus и начал собирать метрики.

Тема второй статьи – Alerts и их обработка. Задачу, условно, можно разделить на два блока:
🍭 Написание Alert Rules, определяющих, когда необходимо «подать сигнал»
🍭 Настройка Alert Manager, который определяет, что делать с Alert и за то, куда его можно направить

Далее описывается как создать свое собственное правило и про правила, доступные «из коробки» при установке Prometheus. Рассматриваются примеры настройки Alert Manager для группировки аналогичных Alert (чтобы, не «DDoS-ить» команду поддержки) и самое интересное – интеграция со Slack для быстрого и удобного получения уведомлений!

Все материалы, которые использовал Автор, можно найти в repo.

P.S. Всем хорошего отдыха! Не болейте! ☺️

Всем привет!

Ребята из 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.

Всем привет!

Небольшое демо по использованию Cosign – инструмента генерации и проверки электронной подписи для образов контейнеров.

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

Демо описывает следующий процесс:
🍭 Установка Cosign
🍭 Генерация ключевой пары – закрытый и открытый ключи
🍭 Подпись образа с использованием закрытого ключа
🍭 Помещение образа вместе с подписью в Container Registry
🍭 Использование открытого ключа для верификации подписи образа

Помимо указанного в демо приводится пример подписи Software Bill of Materials (SBOM). Сама SBOM генерируется при помощи Syft (о нем мы писали ранее) и подписывается при помощи Cosign.

Привет!

Сайт, посвященный 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/

Привет!

Очень-очень большая статья, посвященная теме управления секретами (~21 минута, если верить Medium). Да, она 2018 года, но все равно многое из того, что в ней написано актуально и по сей день.

В начале статьи приводится проблематика, с которой можно столкнуться: как для «классического ИТ», так и для Cloud и DevOps-окружений.

Отдельно хочется выделить часть статьи, в которой описано с какими сложностями столкнулись компании (Pinterest, Square) и почему они решили разработать собственные инструменты (Knox, Keywhiz).

Далее идет обзор-перечисление open source решений, которые могут быть использованы: Torus, Credstash, Sneaker и другие.

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

Всем привет!

Небольшая статья о том, как 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 можно ознакомиться по ссылке ☺️