Всем привет!

Вышел ежегодный State of DevOps Report. Отчет содержит в себе общую информацию по таким темам, как:

🍭 Что же такое DevOps? Размышления на тему 😊
🍭 Какие структуры команд наиболее часто встречаются?
🍭 Что мешает развитию DevOps внутри Компаний?
🍭 Используются ли облачные вычисления и насколько часто?
🍭 Попытки предугадать что будет дальше – «The (future) state of DevOps»

Отчет для чтения, статистика присутствует, но ее не то, чтобы много

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

Если вы хотите поближе познакомиться с eBPF, то рекомендуем посмотреть видео от Liz Rice: «A Beginner's Guide to eBPF Programming with Go».

В видео:
🍭 Приводится краткий обзор того, что такое eBPF
🍭 Как написать простое «Hello world» приложение
🍭 Множество demo, кода и примеров!

Желаем отличных выходных и прекрасного отдыха!

Привет!

Визуализация помогает упростить восприятие информации, особенно, если «уровней абстракции» очень много, а возможностей «тонкой настройки» - еще больше!

По ссылке доступен проект – rback – который позволяет визуализировать RBAC в Kubernetes. В независимости от сложности реализованной структуры, rback проанализирует все созданные сущности и построит граф, на котором будут отображены Service Accounts/(Cluster) Roles, соответствующие bindings и возможности ☺️

Всем привет!

В статье автор описывает подход к созданию и управлению Network Policy. Материал разбит на несколько частей:

🍭 Основы. Что такое Network Policy и зачем они нужны (мы писали об этом тут и вот тут): ingress/egress, использование matchExpression, online-редактор политик от Cilium
🍭 Governance. Использование git для управления политиками, например:

1. Разработчику предоставляется доступ к repo, где описана Network Policy
2. Разработчик делает отдельный branch, вносит изменения при необходимости
3. Создается pull request
4. ИБ-специалисты либо принимают, либо не принимают request разработчика. Если НЕ принимают, то описывают почему именно, что не понравилось
5. В случае «успешного» принятия request изменения применяются на кластер

🍭 Автоматизация. Использование OPA для частичного автоматизации процесса внесения изменений в Network Policy
🍭 Debug. Как и откуда получать информацию для отладки политик

P.S. В статье много ссылок на полезные материалы по теме, включая ссылки на repo с «готовыми» Network Policies

Привет!

Тема безопасности software supply chain не прекращает быть актуальной. Недавно GitLab «предоставил» Package Hunter для community. Инструмент разработан GitLab и ранее использовался «внутри» конторы с ноября 2020 года.

Package Hunter анализирует зависимости на наличие вредоносного кода и иного нетипичного поведения через установку в изолированной среде (песочнице) с дальнейшим мониторингом активности. Интересно, что для его работы необходим Falco, правила находятся в repo проекта и их достаточно много.

На текущий момент поддерживается только NodeJS и Ruby. Подробности (ссылки на документацию, информацию по использованию, код) можно найти в статье по ссылке

P.S. Важно - This is beta software. Don't run on production servers.

Всем привет!

Awesome++. На этот раз он посвящен OPA. Как и во всех Awesome в repo можно найти множество ссылок на полезные и интересные материалы по теме:

🍭 Ссылки на repo проектов (OPA, Gatekeeper, Conftest)
🍭 Документация (включая Styra Academy – курсы, где можно пройти тренинги по OPA)
🍭 Использование OPA совместно с языками программирования (Python, Go, Java и т.д.)
🍭 И, наверное, самое интересное – наборы готовых политик:
- Community-owned policy library for OPA
- Rego policies from the the Red Hat community of practice
- Open Database of rego policies for common Infrastructure as Code files (от Aqua Security)

И многое другое! Надеемся, что подборка будет для вас полезной! ☺️

Хоп хэй, ла-ла-лэй!
Вот и пятница настала, а вместе с ней предвкушение долгожданного и не менее заслуженного отдыха!

😎 Commit’ы пушатся - приклады крутятся! 😎

А мы рады разбавить ожидание уикенда очередным любопытным постом!

Сегодня тема нашего поста *голосом Якубовича* - О-о-обсервабилити!

Славная команда талантливых разработчиков из Imhotep Software LLC заботливо представила общественности свою очень простую, но в то же время не менее полезную тулзу под прямо-таки кричащим названием k9s!

Утилита представляет собой альтернативное видение управления кластером Kubernetes. В сущности, это простая утилита CLI, и такой бы она и осталась, если бы не чудесный ее баланс возможностей, удобства и простоты.
Понятно, что платформа Kubernetes настолько пронизана невидимыми нитями YAML и JSON, а комьюнити настолько большое, что все это в совокупности позволяет лепить какие душе угодно модули для взаимодействие с кластерным API, однако, не всегда итоговый продукт оказывается действительно стоящим внимания.
В случае с k9s это внимание вполне оправдано, так как утилита позволяет работать практически со всеми ресурсами кластера при помощи удобного интерфейса с псевдографикой, не только для отображения информации о ресурсах, как например логи или состояние подов деплойметов, но и управления ими «на лету».

Теперь можно уйти от постоянного набора длинных команд, а можно просто перемещаться по ресурсам и менять их конфигурацию при помощи простых диалоговых окон!

Из коробки утилита умеет:

🍩 удобное отображение различных метрик (выглядит как “$ top”)
🍩 выполнение всех нативных команд kubectl
🍩 наглядное отображение сложных ресурсов вроде манифестов RBAC
🍩 отображение зависимостей ресурсов
И наконец, это просто красиво!

И главное, утилита, являясь под капотом почти нативным инструментом взаимодействия с Kubernetes, имеет куда более user-friendly интерфейс. Таким образом утилита может быть одинаково полезна как опытным специалистам, не боящимся консоли с kubectl, так и начинающим инженерам, делающим первые шаги в k8s!

Утилита бесплатная, распространяется под любимой лицензия Apache 2.0 и доступна по ссылке на сайте и GitHub разработчика (для Windows, Linux и MacOS)

👇Приятного использования! 👇

https://github.com/derailed/k9s

Всем привет!

Connaisseur – admission controller, используемый для валидации подписи образов контейнеров (про подпись образов мы писали вот тут).

Работает достаточно просто: «перехватывает» запрос на создание/обновление ресурса в кластере, анализирует подписи образов на основе открытых ключей. По результатам анализа принимается решение – разрешить выполнение запроса или запретить.

Решение поддерживает следующие технологии подписей образов:
🍭 Notary V1 / Docker Content Trust
🍭 Sigstore / Cosign
🍭 Notary V2 //планируется

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

С обзорной статьей (установка, базовая настройка и использование) можно ознакомиться по ссылке. Документация располагается вот тут.

Привет!

В приложении можно скачать отчет о безопасности сред контейнерной оркестрации, подготовленный компанией Red Hat – «State of Kubernetes Security Report».

В отчете можно ознакомиться с ответами респондентов на такие вопросы как:
🍭 С какими инцидентами пришлось столкнуться за последние 12 месяцев?
🍭 Что больше всего смущает/волнует в стратегии развития контейнеризации Компании?
🍭 Кто несет ответственность за ИБ контейнерной инфраструктуры?
Какие оркестраторы используются?
🍭 С какими open source инструментами по ИБ вы работаете?

И многое другое!

Привет!

K8SPurger – решение, которое позволяет найти неиспользуемые ресурсы в кластере среды контейнерной оркестрации.

Под «неиспользуемыми» понимается следующее:
🍭 Secret – отсутствуют mount (в качестве ENV, файла)
🍭 ServiceAccount – отстутсвуют pods, которые его используют
🍭 Deployment – количество replica равное 0
🍭 RoleBinding – «привязка» к ServiceAccount, которого не существует или который не используется каким-либо pod
🍭 В repo указаны критерии для ConfigMap, PVC, Services, Ingress и StatefulSet

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

Привет!

Мы часто пишем об использовании OPA в качестве инструмента для проверок безопасности. Однако, OPA – это policy engine, который можно использовать не только для целей ИБ, но и для целей ИТ!

В статье рассматривается отличный пример, где показано, как реализовать анализ нарушений OPA-политик при помощи Prometheus и Grafana:
🍭 Применение OPA-политик к кластеру в режиме dry-run (не блокируют, но оповещают о нарушениях)
🍭 Сбор метрик о нарушениях при помощи Prometheus. Для этого Автор статьи написал небольшую программу на Go – «Constraint Violation Prometheus Exporter», которая обращается к kube-apiserver для получения данных о нарушениях и передает информацию в Prometheus в надлежащем формате
🍭 Создание dashboard в Grafana, отображающего полученную информацию

В конце статьи приведен алгоритм воспроизведения demo – с командами, с ссылками на инструментами и утилиты, которыми надо воспользоваться.

Если развить идею, то при правильном взаимодействии Sec и Ops можно реализовать аналогичный dashboard в том числе и для ИБ-проверок, что позволит получать наглядную информацию о наиболее проблемных областях ИБ кластера на основании данных, получаемых от OPA

Всем привет!

ENISA недавно выпустила еще один Threat Landscape-отчет, посвященный Supply Chain атакам.

Аналитики выделили 4 ключевых элемента:
🍭 Supplier: сущность, поставляющая Продукт или Услугу другой сущности
🍭 Supplier Assets: ресурсы, используемые Supplier для подготовки Продукта или Услуги
🍭 Customer: сущность, потребляющая Продукт или Услугу
🍭 Customer Assets: ресурсы Customer

Таким образом получается, что Supply Chain – всегда комбинация 2-ух атак: атака на Supplier, которая продолжается атакой на Customer для доступа к его Assets.
Для обобщения угроз была предложена Threat Taxonomy (отдельно для Supplier и для Customer). Taxonomy содержит 2 основных блока:
🍭 Техники, используемые для компрометации Supplier/Customer
🍭 Assets Supplier/Customer, которые являются целью атаки

Как "пользоваться" указанной Taxonomy объяснили на примере Codecov: в процессе создания образов контейнеров Codecov был bug, при помощи которого были компрометированы credentials. Использование ранее полученных credentials позволило модифицировать "Bash Uploader Script". "Обновленное" ПО распространилось Клиентам, благодаря чему злоумышленники смогли получить доступ к их данным. Получается что были задействованы техники «Exploiting Configuration Vulnerability» и «Trusted Relationship [T1199]» для воздействия на Assets – «Code» и «Software»

Аналогичный разбор приведен и для других известных атак, реализованных за последние годы (Solarwinds Orion, Mimecast, Ledger, Kaseya и т.д.). Показан timeline supply chain атак, описаны верхнеуровневые рекомендации по противодействию и многое другое.

В целом отчет получился достаточно «массивным» и интересным, рекомендуем к ознакомлению!

P.S. Всем отличной пятницы и выходных! ☺️

И сам отчет в приложении ☺️

Всем привет!

В новой версии Kubernetes – 1.22 появилось много интересных изменений, в том числе по безопасности.

Ребята из Aqua Security сделали небольшой обзор нововведений:
🍭 PodSecurity Admission Controller
🍭 Default Seccomp Profile
🍭 NetworkPolicyEndPort (перенесен в статус Beta)
🍭 Поддержка Rootless Containers

Все указанные возможности пока что в Alpha Phase, но уже заметно в какую сторону движется community и что можно ожидать в следующих релизах.

Аналогичный разбор сделала команда Sysdig, заодно указав deprecations версии 1.22

12 августа коллеги делают интересный вебинар по хранению persistent данных и резервному копированию в кубере

Вендоры, традиционно поставляющие продукты backup & recovery, сравнительно недавно начали выпускать функционал работы с Kubernetes, он часто сырой и требует доработки напильником.

О чем пойдет речь:
📌 Persistent данные в Kubernetes: особенности, требования, pros & cons.
📌 Как обеспечить резервное копирование приложений и баз данных.
📌 Какие инструменты поддерживают резервное копирование в Kubernetes, в чем их особенности
📌⚡️ Live демо: Резервное копирование в Kubernetes с помощью Cоmmvault Backup and Recovery и Veeam Kasten.

Регистрируйтесь по ссылке
https://events.webinar.ru/jet/PersistentDevSecOps

Привет!

По ссылке собрана удобная коллекция решений по DevSecOps, разбитая по классам:

🍭 Application Security Testing: SAST, DAST, SCA, ASOC, MAST
🍭 Protection: WAF, WaaP, RASP, Bot Mitigation, CI/CD Security
🍭 Services: Penetration Testing, Bug Bounty, Training, EASM

Для каждого класса приводится перечень решений (Enterprise, Open Source) и краткое описание назначения класса. О похожей подборке мы уже писали в этом посте.
Такие агрегаторы могут быть удобны, например, если у кого-то возникает вопрос – «А что вообще есть?». Помимо многочисленных awesome можно кидать ссылку на рассматриваемую подборку для первичного ознакомления

P.S. При желании можно добавить инструмент через функционал "Submit Tool" ☺️

Всем привет!

Ребята из Bridgecrew проделали колоссальную работу по анализу общедоступных Helm charts: «We scanned thousands of open-source Helm charts available for reuse on ArtifactHub against common Kubernetes security and compliance policies via Checkov»

Результаты своей работы Bridgecrew описали в цикле статей (раз, два, три)

Первая статья посвящена статистике и ключевым findings:
🍭 71% просканированных repo содержит misconfigurations (всего было просканировано 618)
🍭 В 60% манифестов не были корректно реализованы resource quotas
🍭 Множество манифестов, где были допустимы privelegeEscalation
🍭 Манифесты не содержат readiness/liveness probes (25%), некорректные настройки тэгов для образов (latest или отсутствие)

Можно сделать очень простой вывод – «Доверяй, но проверяй». Helm chart очень удобный инструмент для deploy приложений. Однако, не следует «слепо ему доверять», например, можно его доработать с точки зрения ИБ и использовать у себя!
Подробности (по второй и третьей статье) в следующих постах ☺️

P.S. Это еще не все, ребята также поделились инструментом по сканированию ArtifuctHub (для работы требуется artifacthub API token/secret token), под капотом все тот же Checkov

Привет!

Продолжение истории Bridgecrew! После сбора статистических данных команда решила проанализировать наиболее часто встречающиеся Helm-dependencies.

Задача отчасти похожа на создание Software Bill of Materials (SBOM), только для Helm-chart: необходимо понять какие именно компоненты являются «зависимыми» и насколько они корректны с точки зрения ИБ.

В статье продемонстрированы графы с легендой:
🍭 Зеленый: сканируемый chart
🍭 Синий: зависимость (URI) ссылается на тот же Helm repository, что и сам chart
🍭 Черный: «локальные» зависимости chart (отсутствует URI, только local file path)
🍭 Красный: Все остальные зависимости

В результате анализа получилось собрать статистику о наиболее часто используемых зависимостях (одной из которых стала bitnami/postgresql) и сделать вывод, что существует большая фрагментация зависимостей, их массовое дублирование, которые можно было бы переиспользовать. В конце статьи Bridgecrew привели несколько рекомендаций о том, как можно повысить уровень ИБ в такой ситуации: Embed static analysis into your CI/CD pipeline, Understand your runtime posture, Audit third-party Infrastructure code, Increase awareness of IaC security, Automate posture information at the point of consumption

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

Завершающая часть захватывающей трилогии анализа Helm chart от Bridgecrew! В прошлой серии ребята выяснили, что самая популярная зависимость - bitnami/postgresql.

Ее chart проанализировали при помощи Checkov, чтобы понять насколько он безопасен. Примеры того, что удалось узнать (с точки зрения failed-проверок, приведены не все результаты):

High
🍭 «Ensure Containers Do Not Run With AllowPrivilegeEscalation». Контроль возможности повышения привилегий, например, дочерним процессом
Medium
🍭 «Ensure that the seccomp profile is set to docker/default or runtime/default». Ограничение возможностей контейнера. В версии Kubernetes 1.22 «Default Seccomp» находится в стадии Alpha (можно почитать тут и тут)
🍭 «Use read-only filesystem for containers where possible». Сохранение immutable-подхода контейнеров
Low
🍭 «Memory and CPU limits should be set». Ограничение ресурсов, потребляемых контейнером, например, для предупреждения DoS-атак
🍭 «Minimize the admission of containers with capabilities assigned». Ограничение Linux-capabilities контейнеров

В статье также разобраны варианты remediation указанных недостатков с отсылками на идеи «как сделать лучше» и с указанием «точек» в Helm chart, где нужно реализовать изменение.

Получается, что самая популярная зависимость, которую использовали во многих Helm chart содержит целый перечень потенциальных улучшений по ИБ, что вновь подводит к выводу - "Доверяй, но проверяй!"

Привет!

Lens – достаточно удобная “IDE для Kubernetes”, возможности которой можно расширять при помощи extensions.

Например:
🍭 Aqua Security Starboard: отображение информации по уязвимостям в образах контейнеров и ошибках в конфигурации кластера
🍭 Certificate Info: удобное отображение информации об используемых сертификатах
🍭 Resource Map: графическое представление информации о взаимосвязи сущностей в кластере
🍭 Debug pods: extension, предоставляющий возможность debug из интерфейса Lens

Больше информации доступно по ссылке ☺️