Привет!

Чем заняться на новогодних праздниках? Конечно же – учиться! Тем более, что интересных курсов очень много. Одним из таких порадовали ребята из Sysdig!

Они выпустили курс «Falco 101», который очень лаконично описали: «All you need to learn to get started with Falco».

Суммарно курс состоит из ~ 5,5 часов видеоматериалов и включает в себя такие разделы, как:
🍭 What is runtime security
🍭 Falco installation and basic settings
🍭 Falco event sources
🍭 Falco rules: basics and deep dives

И другие! Кстати, недавно мы писали про лабораторные работы от Sysdig, посвященные Falco. Их можно использовать вместе с курсом для совмещения теории и практики 😊

​​Сотни продуктов пострадали от уязвимости в Log4J и это, в основном, известные и часто используемые.

А сколько внутренних проектов уязвимо? Еще предстоит узнать.

Как оперативно находить подобные уязвимости в своих проектах, исправлять опасные настройки Kubernetes с помощью KSPM (близкий родственник CSPM) и контролировать контейнеры на уровне Runtime ?

Расскажет Aqua Security в серии коротких вебинаров:

Aqua: Начинаем погружение!
Серия 30 минутных вебинаров по безопасности Cloud Native:
1. Сканирование образов контейнеров
2. Безопасность Kubernetes (KSPM)
3. Новый термин - CNAPP
4. Compliance for Cloud Native
5. Runtime Security и многое другое.

Ближайший вебинар уже завтра, регистрация -
https://info.aquasec.com/jump-start-russia

Всем привет!

Продолжаем тему с интересными обучениями, которые доступны бесплатно и могут дать представление о чем-то новом!

Сегодня – GitOps! Точнее – курс от CodeFresh, посвященный этому подходу и его реализации при помощи ArgoCD.

Курс состоит из 5 основных блоков:
🍭 About GitOps. Декларативное описание инфраструктуры, использование Git в качестве «источника истины», обзор плюсов и минусов подхода
🍭 ArgoCD basics. Обзор возможностей ArgoCD для управления нагрузками на кластере
🍭 Using ArgoCD. Реализация операций «второго дня» с использованием Argo
🍭 Progressive Delivery. Использование Argo Rollouts для Blue/Green и Canary Deployment
🍭 Summary and examination. Обзор пройденного материала, небольшой тест для закрепления

Если курс понравится, можно ознакомиться еще с двумя – GitOps at Edge и GitOps at Scale (по мере их появления) ☺️

Всем привет!

Еще один интересный обучающий проект, достойный внимания – Styra Academy! Отличный курс, который рассказывает про OPA, как и зачем использовать этот инструмент.

Курс состоит из нескольких частей:
🍭 Overview of OPA. Какие задачи решает, какими возможностями обладает
🍭 Rego Expressions. Основа языка Rego, используемого для написания OPA-политик
🍭 Basic Rego Rules. Описание концепции вычисления правил, создание «цепочки» правил
🍭 Partial Rego Rules. Использование Partial Object и Functional Rules
🍭 Rego Iteration. Взаимодействие с Arrays, Objects и Sets
🍭 Rego Packages. «Упаковка» политик в предопределенные packages

Курс содержит теорию, практические задания и предоставляется бесплатно! ☺️

Поздравляем, друзья, нас уже больше 1000! Ура! 🥳

Спасибо, что вы были и остаетесь с нами, впереди вас ждет еще больше полезностей из мира DevSecOps.

С вами на связи
Jet DevSecOps Team

Stay tuned!

Всем привет!

Вот и настал конец года. Самое время заняться ретроспективой, подведением итогов года и планированием следующих шагов своего карьерного развития или развития вашей команды!

По ссылке ниже доступна интерактивная карта сертификаций по направлению ИБ. Сама карта разбита на домены (например, IAM, Software Security...), в каждом из которых указаны названия сертификаций (например, CISSP, CSSLP...). Вендорских тут нет. При нажатии на название выполняется переход на официальный источник, где уже представлено детальное описание.

P.S. Цены карта тоже отображает, но лучше проверять их на официальных сайтах.

Ссылка: https://pauljerimy.com/security-certification-roadmap/

Всем привет!

Есть 2 команды, которые, на первый взгляд очень похожи, делают аналогичные вещи и не очень понятно, чем именно они отличаются. Речь идет об attach и exec.

В своей новой статье Ivan Velichko приводит наглядное описание разницы. Как и везде, дьявол кроется в деталях – а именно в реализации attach и exec.

Если коротко, то:
🍭 Attach – как бы «присоединяется» (attached) к stdio запущенного контейнера
🍭 Exec – вообще не подключается к запущенному контейнеру... тут лучше прочитать самим, не хотим делать спойлеры ☺️ Если не знаете, как именно это работает, то очень сильно удивитесь!

Ранее мы уже писали про блог Ivan, его Телеграм-канал и Learning Path по контейнерам. Очень рекомендуем материалы автора и согласны с его мыслью – «Зачем запоминать, если можно понять?»

P.S. Всем отличной рабочей недели! Да, до Нового Года осталось 2 недели!

Всем привет!

GitOps – очень интересный подход к управлению deployment. Однако, как и все, он не лишен недостатков.

В статье «The pains of GitOps 1.0» приводятся размышления на тему возможных проблем подхода. Автор выделяет такие как:
🍭 Частичное покрытие жизненного цикла разработки ПО при помощи GitOps
🍭 Не всегда тривиальное разделение CI и CD частей
🍭 Сложность одновременного управления средами (Dev, Test, Prod и т.д.)
🍭 Autoscaling и динамические окружения (как реализовать, когда GitOps вернет все «обратно»?)
🍭 Недостаточная Observability (в management смысле, а не в техническом)
🍭 Не самый простой аудит событий (да, в Git все есть, но это «все» надо еще найти и найти быстро)
🍭 Сложности, связанные с GitOps-управлением большого количества deployments
🍭 Управление секретами и многое другое!

Для каждого тезиса приводится несколько аргументов, его подкрепляющих. Самое интересное – Автор приводит примеры в стиле «В теории – классно, а на практике есть нюансы…». Многие вопросы, поднимаемые в статье, характерны и для «классического» управления deployment’ами. Целью Автора было развенчать миф: «внедрил GitOps и все работает, «как по маслу!», показать что и у него есть недостатки при всех его достоинствах!

Какой можно сделать вывод? GitOps – еще один «маркетинг»? Не думаем. Скорее – «серебряной пули не существует», у всего есть свои сильные и слабые стороны и за все приходится платить. Удобство иногда снижает «гибкость», «гибкость» иногда негативно отображается на управляемости и т.д. Главное при внедрении любой технологии/подхода – понять, нужна ли она вам? И если да, то как ее правильно реализовать и на какие «жертвы» вы готовы пойти.

А что вы думаете о GitOps? Пишите в комментариях!

Привет!

Недавно обновился HashiCorp Vault Plugin для Jenkins. Есть Breaking Changes, а есть bug fix, который может быть в разы значительнее, чем добавление Secret File Credential Type (того самого breaking change).

Речь идет о «fixing the fallback to get the config to access Vault». В plugin была возможность использовать Credentials для доступа к Vault, задаваемых на разных уровнях: Folder, либо Global. Достаточно удобно, если вы используете Folder, реализована ролевая модель доступа и вы хотите, чтобы каждый проект в Folder использовал собственные учетные данные для аутентификации в Vault, а не единые для всех (Global).

Однако, даже при наличии соответствующих настроек, учетные данные уровня Folder не всегда использовались. Например, использование конструкции withCredentials все равно будет использовать параметры, заданные в Global.

Именно эту проблему и устраняет рассматриваемое обновление! Теперь все должно работать корректно: From pipeline => Possible parents (Folder Item) => Jenkins Global config. Таким образом, каждый проект в Folder будет использовать собственные учетные данные для аутентификации в Vault, а если они не указаны, то будет использована Global-конфигурация. Осталось только протестировать ☺️

Привет!

Детальный материал (с примерами и screenshots), в котором описан kill chain по «захвату» nodes кластера K8S. От эксплуатации уязвимости в запущенном на нем web-приложении до получения root-доступа на node.
Статья хоть и не самая новая (2018 год), но все равно может оказаться полезной.

Последовательность действий:
🍭 Анализ web-сайта, поиск уязвимостей (DirBuster)
🍭 «Проникновение» в контейнер через RCE-уязвимость. Установка необходимых «инструментов для дальнейшей работы» (Metasploit, Meterpreter)
🍭 Чтение Service Account (SA) Token. «Установка» kubectl. Изучение возможностей SA (list, create, exec и т.д.)
🍭 «Прыжок» в другой контейнер, SA которого обладает большими возможностями
🍭 Создание pod, с mount /root:/ - AttackerPod
🍭 Изменение пароля пользователя, входящего в sudo группу от имени root. SSH на node.
🍭 Но и этого оказалось мало для автора! Создание DaemonSet с AttackerPod и повтор аналогичных действий для компрометации всех nodes кластера

Статья - хорошо структурированный материал, который объединяет в себе несколько инструментов, тактик и техник, реализация которых привела к компрометации кластера. «Вишенкой» является интересный и простой слог автора ☺️

P.S. В конце статьи приводятся рекомендации – как можно было этого избежать? С одной стороны, достаточно простые меры и «все понятно». С другой – лишний повод задуматься о том, что даже встроенные возможности кластера K8S по ИБ могут дать многое и не стоит пренебрегать их настройками.

P.P.S. Preview к ссылке не работает, дублируем: https://www.inguardians.com/blog/attacking-and-defending-kubernetes-bust-a-kube-episode-1/

Пятница!

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

В статье описываются 12 команд, которые, по мнению автора, помогут упростить debug нагрузок в кластере (workloads).

Команды сгруппированы для поиска проблем нескольких типов: «Workloads won’t run», «Cannot access workloads» и «Debug specific pods».

Примеры команд, которые приведены в статье:
🍭 kubectl get events –field-selector type=Warning –all-namespaces
🍭 kubectl resource-capacity –pods –util –sort cpu.util
🍭 kubectl lineage pod ${POD}
🍭 kubectl get endpointslices -o wide
🍭 kubectl debug pod –it –image=%image% $POD и другие

В статье приводится краткое описание причин использования команд и ссылки на open source утилиты, которые помогут еще больше упростить процесс поиска ошибок! Вместе с детальной debug-схемой (о которой мы писали тут) получается инструмент, которые отвечает на вопросы «Что искать? Как искать?». Если хочется чуть больше визуализации, можно посмотреть в сторону K9S (о которой мы писали тут).

P.S. Всем отличных выходных и вечера пятницы! До Нового Года осталась 1 неделя!!!

Привет!

По ссылке доступна статья, детализирующая проблематику управления GitOps с использованием branches (об иных «тонких местах» работы с GitOps мы писали вот тут).

Автор ставит простой вопрос – «How do I promote a release to the next environment?» и описывает, почему ветвление в Git (branches) не является лучшей практикой:
🍭 В теории – promotion == git merge, на практике, как обычно, бывают нюансы
🍭 Сложности использования pull/merge request при большом количестве сред
🍭 Возможный configuration drift (особенно явно это видно при внесении hotfix)
🍭 Потребность поддержки и управления большим количеством branches и другие

Что же делать? И как правильно организовать работу с Git? Автор, в лучших традициях Адриано Челентано интригует и просит подождать следующей статьи, где ответит на этот вопрос! 😊

Привет!

Существует большое количество frameworks, посвященных тематике защиты сред контейнерной оркестрации.

Как правило, все они содержат упоминания нижеуказанных доменов:
🍭 Лучшие практики по архитектуре
🍭 Безопасность в CI/CD
🍭 Защита ресурсов
🍭 Защита runtime
🍭 Безопасность цепочки поставок (supply chain)
🍭 Сетевая безопасность
🍭 Управление уязвимостями и compliance-несоответствиями
🍭 Управление секретами

В статье приводится небольшой обзор таких framework как: CIS Kubernetes Benchmark, The MITRE ATT&CK® Framework for Kubernetes, PCI DSS Compliance for Kubernetes, NIST Application Container Security Framework, NSA-CISA Kubernetes Hardening Guide. Для каждого из них приводится общее описание, его сильные/слабые стороны и небольшие рекомендации по его использованию/автоматизации.

Существует еще один checklist, который не попал в список, но достоин упоминания – «Kubernetes Security Checklist and Requirements» от автора канала «DevSecOps Wine». Материал доступен как на русском, так и на английском языках.

Tracee — это runtime security утилита для контейнерных сред. Она использует технологию Linux eBPF для отслеживания событий в реальном времени и анализа шаблонов поведения.

Tracee позволяет увидеть развитие атаки и провести её расследование. К тому же, в отличие от многих freeware-продуктов, tracee имеет широкую поддержку вендора.

🍏 Например, в этом воркшопе (который является частью целого курса на гитхабе) показаны базовые функции Tracee и интеграция утилиты со Slack.

🍏 Эта статья в блоге Aquasec содержит руководство по установке Tracee в кластер Kubernetes и обнаружению атаки. Можно увидеть работу Tracee на примере эксплуатации уязвимого приложения.

🍏 А в этой статье описано создание кастомных правил, представляющих из себя сигнатуры тех или иных атак. В tracee есть неплохой набор правил "из коробки", но для обнаружения новейших атак его может оказаться недостаточно, поэтому важно уметь дописывать правила самому. К тому же, новые сигнатуры широко приветствуются вендором и помогают развивать продукт.

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 ролик доступен по ссылке.