Всем привет!

В 18-19 августа 2021 года пройдет eBPF Summit! Зарегистрироваться можно по ссылке. Программа пока что не утверждена окончательно, но можно ознакомиться с темами, на которые будут разговоры:

🍭 Introduction & Getting Started with eBPF
🍭 eBPF-based Networking, Load-Balancing, & Network Security
🍭 Securing Systems, CI/CD pipelines, Networks, ... with eBPF
🍭 eBPF Projects (bpftrace, Cilium, Falco, ...) и многое другое

Множество интересных спикеров, среди которых будет и Liz Rice (эксперт по контейнеризации и автор множества интересных книг и статей по обеспечению их безопасности), которая является частью команды Isovalent (Cilium)

P.S. Регистрация бесплатная ☺️

Всем привет!

ThreatMapper – проект, который позволяет анализировать состояние ИБ кластера:

🍭 Визуализирует workloads кластера для упрощения восприятия
🍭 Идентифицирует уязвимости в образах контейнеров
🍭 Интегрируется с registry, CI/CD для сканирования образов
🍭 Анализирует запущенные контейнеры

Отличие ThreatMapper, например, от Trivy в том, что у первого есть приятный интерфейс, который может быть использован для последующей аналитики и запуска сканирований. Помимо этого, присутствует интеграция с SIEM

P.S. Для просмотра demo можно воспользоваться ссылкой: https://deepfence.io/community-demo-form/ (требуется электронная почта)

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

Kubernetes-external-secrets – проект, основная задача которого состоит в извлечении секрета из стороннего хранилища и передачи его сущностям кластера в качестве Secret.

Состоит из двух частей:
🍭 ExternalSecret – CRD – описывает какие данные необходимо извлечь
🍭 Controller – «конвертирует» ExternalSecret в Secret K8S

На текущий момент поддерживаются следующие внешние хранилища: AWS Secrets Manager, AWS System Manager, Akeyless, Hashicorp Vault, Azure Key Vault, Google Secret Manager and Alibaba Cloud KMS Secret Manager.

P.S. Больше информации - архитектура, настройка, примеры использования и т.д. находится в самом repo

Привет!

Что общего у статического анализа исходного кода и Elasticsearch? Например, проект BugHound! Простой SAST, анализирующий PHP и Java (в будущем планируется расширение перечня поддерживаемых языков).

Принцип работы BugHound достаточно прост:
🍭 Построение дерева файлов, находящихся в проекте
🍭 Анализ файлов для идентификации небезопасных функций/методов (в большей степени реализовано через regex)
🍭 Сбор результатов с последующей передачей в Kibana для отображения на преднастроенных dashboard

Полноценным SAST назвать такое решение нельзя, но проект интересен тем, как автор связал несколько технологий. Возможно, такой подход будет кому-то интересен для реализации у себя. Больше про BugHound можно почитать по ссылке.

Привет!

Управление RBAC не самая простая задача, а зачастую около-избыточная (например, когда требуется создавать несколько RoleBinding, которые практически ничем не отличаются).

Для того, чтобы упростить жизнь был разработан RBAC-manager.
Он переопределяет подход к созданию RBAC через дополнительную сущность – RBACDefinition, которая описывает целевое (желаемое) состояние: «Instead of managing role bindings or service accounts directly, you can specify a desired state and RBAC Manager will make the necessary changes to achieve that state».

RBAC-manager может быть полезен в таких случаях как:
🍭 Обновление прав: не надо удалять/создавать новый RoleBinding, необходимо только обновить RBACDefinition и утилита сделает все остальное
🍭 Удаление RoleBinding: аналогично, необходимо лишь удалить интересующую сущность из RBACDefinition
🍭 И что очень приятно - можно задавать права доступа к нескольким namespace в едином конфигурационном файле

С документацией можно ознакомиться по ссылке. Также можно быстро "познакомиться" с решением и пользой от него в небольшом примере.

Приглашаем на цикл вебинаров DevSecOps, 2-й сезон!

Уже в этот четверг стартует 2-й сезон вебинаров DevSecOps для всех интересующихся. Наша команда Jet DevSecOps Team, включающая спецов по разработке, эксплуатации и безопасности поделится «боевыми» примерами и лайфхаками, полученными в реальных проектах: от мониторинга k8s и организации конвейера GitOps до резервного копирования в Kubernetes и управления «секретами».

На всех вебинарах будет live demo решений! Как всегда вас ждут минимум слайдов, максимум хардкора и полное погружение.

Участие будет интересно DevOps инженерам, разработчикам, ИТ и ИБ специалистам, ИТ-менеджменту.

Расписание вебинаров:
🔹 22 июля, 16:00–17:30 Мониторинг/аудит k8s. Что такое Audit Policy и как ей пользоваться?
🔹 29 июля, 16:00–17:30 Зачем GitOps в Enterprise
🔹 5 августа, 16:00–17:30 Управление «секретами»: основы
🔹 12 августа, 16:00–17:30 Persistent данные и резервное копирование в кластере

Регистрируйтесь и зовите друзей)

Всем привет!

Если сказать: «Подпись образов», то большинство подумает про проект «Notary». Однако, Notary не единственный способ реализации, есть альтернатива – «Cosign»!
Подход очень похож – использование Cosign для подписи и OPA для последующей ее валидации перед deploy в кластер. С небольшим примером можно ознакомиться по ссылке.

Принцип работы Cosign достаточно прост:
🍭 Генерация ключевой пары
🍭 Подпись образа контейнера при помощи закрытого ключа, помещение подписи в registry
🍭 Проверка наличия подписи у образа при помощи открытого ключа

На текущий момент Cosign поддерживает реестры: AWS Elastic Container Registry, GCP's Artifact, Registry and Container Registry, Docker Hub, Azure Container Registry, JFrog Artifactory Container Registry, The CNCF distribution/distribution Registry, GitLab Container Registry, GitHub Container Registry, The CNCF Harbor Registry, Digital Ocean Container Registry, Sonatype Nexus Container Registry

P.S. Последний release Notary был в 2018 году, возможно в скором времени будет обновление v2, с большим количеством нововведений. Очень советуем посмотреть видео по ссылке целиком

Всем привет!

Вышел ежегодный 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. Всем отличной пятницы и выходных! ☺️

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