Привет!
Визуализация помогает упростить восприятие информации, особенно, если «уровней абстракции» очень много, а возможностей «тонкой настройки» - еще больше!
По ссылке доступен проект – rback – который позволяет визуализировать RBAC в Kubernetes. В независимости от сложности реализованной структуры, rback проанализирует все созданные сущности и построит граф, на котором будут отображены Service Accounts/(Cluster) Roles, соответствующие bindings и возможности ☺️
Визуализация помогает упростить восприятие информации, особенно, если «уровней абстракции» очень много, а возможностей «тонкой настройки» - еще больше!
По ссылке доступен проект – rback – который позволяет визуализировать RBAC в Kubernetes. В независимости от сложности реализованной структуры, rback проанализирует все созданные сущности и построит граф, на котором будут отображены Service Accounts/(Cluster) Roles, соответствующие bindings и возможности ☺️
GitHub
GitHub - team-soteria/rback: RBAC in Kubernetes visualizer
RBAC in Kubernetes visualizer . Contribute to team-soteria/rback development by creating an account on GitHub.
Всем привет!
В статье автор описывает подход к созданию и управлению 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
В статье автор описывает подход к созданию и управлению 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
Medium
Lifecycle of Kubernetes Network Policies and Best Practices
In this blog post, we will talk about the whole lifecycle of Kubernetes Network Policies and best practices
Привет!
Тема безопасности 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.
Тема безопасности 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.
Gitlab
Meet Package Hunter: A tool for detecting malicious code in your dependencies
We developed, tested and open sourced a new tool to analyze program dependencies and protect the supply chain.
Всем привет!
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)
И многое другое! Надеемся, что подборка будет для вас полезной! ☺️
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)
И многое другое! Надеемся, что подборка будет для вас полезной! ☺️
GitHub
GitHub - StyraInc/awesome-opa: A curated list of OPA related tools, frameworks and articles
A curated list of OPA related tools, frameworks and articles - StyraInc/awesome-opa
Хоп хэй, ла-ла-лэй!
Вот и пятница настала, а вместе с ней предвкушение долгожданного и не менее заслуженного отдыха!
😎 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
Вот и пятница настала, а вместе с ней предвкушение долгожданного и не менее заслуженного отдыха!
😎 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
GitHub
GitHub - derailed/k9s: 🐶 Kubernetes CLI To Manage Your Clusters In Style!
🐶 Kubernetes CLI To Manage Your Clusters In Style! - derailed/k9s
Всем привет!
Connaisseur – admission controller, используемый для валидации подписи образов контейнеров (про подпись образов мы писали вот тут).
Работает достаточно просто: «перехватывает» запрос на создание/обновление ресурса в кластере, анализирует подписи образов на основе открытых ключей. По результатам анализа принимается решение – разрешить выполнение запроса или запретить.
Решение поддерживает следующие технологии подписей образов:
🍭 Notary V1 / Docker Content Trust
🍭 Sigstore / Cosign
🍭 Notary V2 //планируется
Помимо проверки может работать в режиме мониторинга: запрос не будет заблокирован в любом случае, однако, оператор получит уведомление об отсутствии подписи. Можно указать проверки подписи образов только для конкретных namespace.
С обзорной статьей (установка, базовая настройка и использование) можно ознакомиться по ссылке. Документация располагается вот тут.
Connaisseur – admission controller, используемый для валидации подписи образов контейнеров (про подпись образов мы писали вот тут).
Работает достаточно просто: «перехватывает» запрос на создание/обновление ресурса в кластере, анализирует подписи образов на основе открытых ключей. По результатам анализа принимается решение – разрешить выполнение запроса или запретить.
Решение поддерживает следующие технологии подписей образов:
🍭 Notary V1 / Docker Content Trust
🍭 Sigstore / Cosign
🍭 Notary V2 //планируется
Помимо проверки может работать в режиме мониторинга: запрос не будет заблокирован в любом случае, однако, оператор получит уведомление об отсутствии подписи. Можно указать проверки подписи образов только для конкретных namespace.
С обзорной статьей (установка, базовая настройка и использование) можно ознакомиться по ссылке. Документация располагается вот тут.
GitHub
GitHub - sse-secure-systems/connaisseur: An admission controller that integrates Container Image Signature Verification into a…
An admission controller that integrates Container Image Signature Verification into a Kubernetes cluster - sse-secure-systems/connaisseur
K8S_Security_Report.pdf
1.2 MB
Привет!
В приложении можно скачать отчет о безопасности сред контейнерной оркестрации, подготовленный компанией Red Hat – «State of Kubernetes Security Report».
В отчете можно ознакомиться с ответами респондентов на такие вопросы как:
🍭 С какими инцидентами пришлось столкнуться за последние 12 месяцев?
🍭 Что больше всего смущает/волнует в стратегии развития контейнеризации Компании?
🍭 Кто несет ответственность за ИБ контейнерной инфраструктуры?
Какие оркестраторы используются?
🍭 С какими open source инструментами по ИБ вы работаете?
И многое другое!
В приложении можно скачать отчет о безопасности сред контейнерной оркестрации, подготовленный компанией 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. От аналогичных решений его отличает наличие графического интерфейса, в котором информация представлена наглядно и просто для восприятия
K8SPurger – решение, которое позволяет найти неиспользуемые ресурсы в кластере среды контейнерной оркестрации.
Под «неиспользуемыми» понимается следующее:
🍭 Secret – отсутствуют mount (в качестве ENV, файла)
🍭 ServiceAccount – отстутсвуют pods, которые его используют
🍭 Deployment – количество replica равное 0
🍭 RoleBinding – «привязка» к ServiceAccount, которого не существует или который не используется каким-либо pod
🍭 В repo указаны критерии для ConfigMap, PVC, Services, Ingress и StatefulSet
По умолчанию кластер сканируется каждые 15 минут, что может быть изменено при конфигурировании K8SPurger. От аналогичных решений его отличает наличие графического интерфейса, в котором информация представлена наглядно и просто для восприятия
GitHub
GitHub - yogeshkk/K8sPurger: Hunt Unused Resources In Kubernetes
Hunt Unused Resources In Kubernetes. Contribute to yogeshkk/K8sPurger development by creating an account on GitHub.
Привет!
Мы часто пишем об использовании 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
Мы часто пишем об использовании 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
Medium
Expose Open Policy Agent/Gatekeeper Constraint Violations for Kubernetes Applications with Prometheus and Grafana
A Grafana dashboard for a succinct view about which Gatekeeper constraints are violated
Всем привет!
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. Всем отличной пятницы и выходных! ☺️
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. Всем отличной пятницы и выходных! ☺️
ENISA Threat Landscape for Supply Chain Attacks.pdf
4.8 MB
И сам отчет в приложении ☺️
Всем привет!
В новой версии Kubernetes – 1.22 появилось много интересных изменений, в том числе по безопасности.
Ребята из Aqua Security сделали небольшой обзор нововведений:
🍭 PodSecurity Admission Controller
🍭 Default Seccomp Profile
🍭 NetworkPolicyEndPort (перенесен в статус Beta)
🍭 Поддержка Rootless Containers
Все указанные возможности пока что в Alpha Phase, но уже заметно в какую сторону движется community и что можно ожидать в следующих релизах.
Аналогичный разбор сделала команда Sysdig, заодно указав deprecations версии 1.22
В новой версии Kubernetes – 1.22 появилось много интересных изменений, в том числе по безопасности.
Ребята из Aqua Security сделали небольшой обзор нововведений:
🍭 PodSecurity Admission Controller
🍭 Default Seccomp Profile
🍭 NetworkPolicyEndPort (перенесен в статус Beta)
🍭 Поддержка Rootless Containers
Все указанные возможности пока что в Alpha Phase, но уже заметно в какую сторону движется community и что можно ожидать в следующих релизах.
Аналогичный разбор сделала команда Sysdig, заодно указав deprecations версии 1.22
Aqua
Kubernetes Version 1.22: Security Features You Need to Know
A review of the security features in Kubernetes version 1.22 incl. PodSecurity admission controller, new sysctl support, rootless containers support & more
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
Вендоры, традиционно поставляющие продукты 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" ☺️
По ссылке собрана удобная коллекция решений по 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" ☺️
Appsecmap
AppSec Map
A map of AppSec service providers and solutions
Всем привет!
Ребята из 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 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
Part 1: Top trends from analyzing the security posture of open-source Helm charts
In this open-source Helm security research, we scanned thousands of Helm charts available on Artifact Hub and are sharing our findings and trends.
Привет!
Продолжение истории 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
Продолжение истории 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
Bridgecrew
Part 2: Top trends from analyzing the security posture of open-source Helm charts - Bridgecrew Blog
In part two of our open-source Helm security research, we analyze Helm chart dependencies and provide recommendations for security best practices.
Всех с пятницей!
Завершающая часть захватывающей трилогии анализа 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 содержит целый перечень потенциальных улучшений по ИБ, что вновь подводит к выводу - "Доверяй, но проверяй!"
Завершающая часть захватывающей трилогии анализа 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 содержит целый перечень потенциальных улучшений по ИБ, что вновь подводит к выводу - "Доверяй, но проверяй!"
Bridgecrew
Part 3: Top trends from analyzing the security posture of open-source Helm charts - Bridgecrew Blog
In part three of our open-source Helm security research, we analyze one of the most commonly used dependencies from a security standpoint.
Привет!
Lens – достаточно удобная “IDE для Kubernetes”, возможности которой можно расширять при помощи extensions.
Например:
🍭 Aqua Security Starboard: отображение информации по уязвимостям в образах контейнеров и ошибках в конфигурации кластера
🍭 Certificate Info: удобное отображение информации об используемых сертификатах
🍭 Resource Map: графическое представление информации о взаимосвязи сущностей в кластере
🍭 Debug pods: extension, предоставляющий возможность debug из интерфейса Lens
Больше информации доступно по ссылке ☺️
Lens – достаточно удобная “IDE для Kubernetes”, возможности которой можно расширять при помощи extensions.
Например:
🍭 Aqua Security Starboard: отображение информации по уязвимостям в образах контейнеров и ошибках в конфигурации кластера
🍭 Certificate Info: удобное отображение информации об используемых сертификатах
🍭 Resource Map: графическое представление информации о взаимосвязи сущностей в кластере
🍭 Debug pods: extension, предоставляющий возможность debug из интерфейса Lens
Больше информации доступно по ссылке ☺️
GitHub
GitHub - lensapp/lens-extensions: List of Lens Extensions
List of Lens Extensions. Contribute to lensapp/lens-extensions development by creating an account on GitHub.
Всем привет!
«Масштаб» может привносить затруднения, про которые не думаешь на малых объемах. Это применимо и к манифестам Kubernetes: чем больше становится приложение, растет его функционал и возможности, тем в большую «кашу» превращается папка с конфигурациями.
В статье автор предлагает интересный подход к структуре хранения манифестов. Все строится вокруг создания пространства папок, где каждая из них представляет отдельный Kind (Deployment, Service, ConfigMap и т.д.).
Приводится наглядный пример использования подобного подхода и рекомендации автора:
🍭 Сокращайте длинные аббревиатуры привычными аналогами при именовании файлов (например,
🍭 Используйте идентичные имена файлов между «Kind-директориями»
🍭 Не используйте тип сущности в ее названии (например nginx-service.yaml)
🍭 Именуйте ресурсы по аналогии с именами файлов, в которых они определяются
Такой подход упрощает восприятие конфигурации приложения и сокращает вероятность ошибки (например, из-за разных способов написания service/svc). Удобен ли Вам подобный подход к хранению манифестов приложений, стали бы вы его использовать?
«Масштаб» может привносить затруднения, про которые не думаешь на малых объемах. Это применимо и к манифестам Kubernetes: чем больше становится приложение, растет его функционал и возможности, тем в большую «кашу» превращается папка с конфигурациями.
В статье автор предлагает интересный подход к структуре хранения манифестов. Все строится вокруг создания пространства папок, где каждая из них представляет отдельный Kind (Deployment, Service, ConfigMap и т.д.).
Приводится наглядный пример использования подобного подхода и рекомендации автора:
🍭 Сокращайте длинные аббревиатуры привычными аналогами при именовании файлов (например,
hpas вместо horizontalpodautoscalers)🍭 Используйте идентичные имена файлов между «Kind-директориями»
🍭 Не используйте тип сущности в ее названии (например nginx
🍭 Именуйте ресурсы по аналогии с именами файлов, в которых они определяются
Такой подход упрощает восприятие конфигурации приложения и сокращает вероятность ошибки (например, из-за разных способов написания service/svc). Удобен ли Вам подобный подход к хранению манифестов приложений, стали бы вы его использовать?
Boxunix
A Better Way of Organizing Your Kubernetes Manifest Files | Boxunix
How to organize your kubernetes files with a consitent, modular and adaptable approach
Привет!
Интересный подход к динамическому тестированию безопасности приложений и анализу API представили ребята из StackHawk.
Интеграция осуществляется через… GitHub (который уже поддерживает возможность использования Dependabot, CodeQL и предоставляет возможность реализации интеграций со сторонними решениями)
Все очень просто:
🍭 Добавляем StackHawk (Security, Codescanning alerts), это создаст workflow для анализа приложения
🍭 Адаптируем конфигурацию, генерируемую «по умолчанию»
🍭 Производим настройки на стороне StackHawk, осуществляем onboarding приложения, формируется файл конфигурации
🍭 Помещаем полученную конфигурацию в корень проекта. Все!
Теперь можно просматривать результаты анализа в GitHub, есть удобные ссылки на StackHawk. Возможно, подобные решения будут реализованы и другими vendor’ами.
Революционного ничего нет, но реализовано очень просто и удобно для пользователей GitHub, что не может не радовать ☺️
P.S. Короткое видео по настройке и использованию можно найти по ссылке
Интересный подход к динамическому тестированию безопасности приложений и анализу API представили ребята из StackHawk.
Интеграция осуществляется через… GitHub (который уже поддерживает возможность использования Dependabot, CodeQL и предоставляет возможность реализации интеграций со сторонними решениями)
Все очень просто:
🍭 Добавляем StackHawk (Security, Codescanning alerts), это создаст workflow для анализа приложения
🍭 Адаптируем конфигурацию, генерируемую «по умолчанию»
🍭 Производим настройки на стороне StackHawk, осуществляем onboarding приложения, формируется файл конфигурации
🍭 Помещаем полученную конфигурацию в корень проекта. Все!
Теперь можно просматривать результаты анализа в GitHub, есть удобные ссылки на StackHawk. Возможно, подобные решения будут реализованы и другими vendor’ами.
Революционного ничего нет, но реализовано очень просто и удобно для пользователей GitHub, что не может не радовать ☺️
P.S. Короткое видео по настройке и использованию можно найти по ссылке
StackHawk
API and Application Security Testing in GitHub Code Scanning
The new StackHawk code scanning integration in GitHub enables developers to find API and application security vulnerabilities where they're already working.