Всем привет!
ESO – это Kubernetes оператор (набор CRD), который интегрируется с внешними системами управления секретами (такими как HashiCorp Vault, Senhasegura и пр) и синхронизирует получаемые значения в объекты Secret кластера. Хотя, кроме систем управления секретами, возможна интеграция как с GitLab, так и с Kubernetes. Полный перечень систем представлен в документации вместе с примерами настройки.
Устанавливается ESO в кластер через HELM. После установки необходимо создать:
🍡Secret с токеном для подключения
🍡SecretStore (или ClusterSecretStore) с конфигурацией подключения к системе управления секретами и референсом на секрет
🍡ExternalSecret (или ClusterExternalSecret) с конфигурацией самого секрета и референсом на SecretStore
В случае успеха новые Secrets создаются в кластере, которые в дальнейшем могут использоваться приложениями (в случае изменения секрета на уровне системы, они автоматически синхронизируются с кластером). Более подробную информацию можно почитать тут - https://external-secrets.io/v0.5.6/
ESO – это Kubernetes оператор (набор CRD), который интегрируется с внешними системами управления секретами (такими как HashiCorp Vault, Senhasegura и пр) и синхронизирует получаемые значения в объекты Secret кластера. Хотя, кроме систем управления секретами, возможна интеграция как с GitLab, так и с Kubernetes. Полный перечень систем представлен в документации вместе с примерами настройки.
Устанавливается ESO в кластер через HELM. После установки необходимо создать:
🍡Secret с токеном для подключения
🍡SecretStore (или ClusterSecretStore) с конфигурацией подключения к системе управления секретами и референсом на секрет
🍡ExternalSecret (или ClusterExternalSecret) с конфигурацией самого секрета и референсом на SecretStore
В случае успеха новые Secrets создаются в кластере, которые в дальнейшем могут использоваться приложениями (в случае изменения секрета на уровне системы, они автоматически синхронизируются с кластером). Более подробную информацию можно почитать тут - https://external-secrets.io/v0.5.6/
GitHub
GitHub - external-secrets/external-secrets: External Secrets Operator reads information from a third-party service like AWS Secrets…
External Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets. - external-secrets/external-secrets
👍1
Предотвращение tag mutation с использованием kbld и ArgoCD
Всем привет!
Существует хорошее правило не использовать tag: latest при разворачивании чего-либо в средах контейнерной оркестрации. Впрочем, это применимо не только к образам контейнеров, но и к зависимостям, артефактам и т.д.
Более того – это правило можно расширить еще больше и применить ко всем tag, т.к. не всегда можно гарантировать на что именно ссылается этот самый tag. С другой стороны, он всегда будет ссылаться на уникальный image digest.
Авторы статьи размышляют над тем, как можно проще перейти на использование этих самых digest. Одной из проблем является то, что они не очень human readable, длинные и есть вероятность ошибки/описки.
Для того, чтобы автоматизировать процесс работы с ними можно использовать kbld – open source утилиту, которая, в том числе обладает функционалом «замены» явного указания image:tag на его digest.
Далее, можно автоматизировать deploy процесс при помощи ArgoCD, ведь он отлично «понимает» манифесты, которые были сгенерированы при помощи kbld.
P.S. Если кто-то хочет посмотреть на это «в действии», в статье есть ссылка на youtube-ролик с демонстрацией.
Всем привет!
Существует хорошее правило не использовать tag: latest при разворачивании чего-либо в средах контейнерной оркестрации. Впрочем, это применимо не только к образам контейнеров, но и к зависимостям, артефактам и т.д.
Более того – это правило можно расширить еще больше и применить ко всем tag, т.к. не всегда можно гарантировать на что именно ссылается этот самый tag. С другой стороны, он всегда будет ссылаться на уникальный image digest.
Авторы статьи размышляют над тем, как можно проще перейти на использование этих самых digest. Одной из проблем является то, что они не очень human readable, длинные и есть вероятность ошибки/описки.
Для того, чтобы автоматизировать процесс работы с ними можно использовать kbld – open source утилиту, которая, в том числе обладает функционалом «замены» явного указания image:tag на его digest.
Далее, можно автоматизировать deploy процесс при помощи ArgoCD, ведь он отлично «понимает» манифесты, которые были сгенерированы при помощи kbld.
P.S. Если кто-то хочет посмотреть на это «в действии», в статье есть ссылка на youtube-ролик с демонстрацией.
Medium
Preventing Tag Mutation With kbld And Argo CD
You’re probably aware that it is best practice not to use the latest tag when deploying to Kubernetes because that tag can be changed to…
Развитие проекта Horusec
Всем привет!
В 2020 году мы писали про проект Horusec – multi-tool из различных инструментов по анализу кода. На тот момент он включал в себя не так много решений, а документация была… на португальском!
Прошло 2 года… Проект не только обзавелся отличным сайтом, но и развил свой функционал. И да, появилась документация на английском!
Что есть внутри:
🍭 Cli, запуск которой анализирует на чем написан код и выбирает оптимальный инструмент анализа
🍭 Web-Application – по факту console, в которой отображаются результаты, есть различные метрики: уязвимости по разработчикам/языкам/проектам, сводная информация по уязвимостям во времени и т.д.
🍭 Количество «встроенных» инструментов также увеличилось. Теперь внутри содержатся: Bandit, Checkov, GitLeaks, GoSec, TFSec, Trivy, DependencyCheck и другие.
🍭 Работает в нескольких «режимах»: SAST, Leaks и Dependency Audit
Изменений/нововведений крайне много, поэтому рекомендуем ознакомиться с документацией.
Всем привет!
В 2020 году мы писали про проект Horusec – multi-tool из различных инструментов по анализу кода. На тот момент он включал в себя не так много решений, а документация была… на португальском!
Прошло 2 года… Проект не только обзавелся отличным сайтом, но и развил свой функционал. И да, появилась документация на английском!
Что есть внутри:
🍭 Cli, запуск которой анализирует на чем написан код и выбирает оптимальный инструмент анализа
🍭 Web-Application – по факту console, в которой отображаются результаты, есть различные метрики: уязвимости по разработчикам/языкам/проектам, сводная информация по уязвимостям во времени и т.д.
🍭 Количество «встроенных» инструментов также увеличилось. Теперь внутри содержатся: Bandit, Checkov, GitLeaks, GoSec, TFSec, Trivy, DependencyCheck и другие.
🍭 Работает в нескольких «режимах»: SAST, Leaks и Dependency Audit
Изменений/нововведений крайне много, поэтому рекомендуем ознакомиться с документацией.
GitHub
GitHub - ZupIT/horusec: Horusec is an open source tool that improves identification of vulnerabilities in your project with just…
Horusec is an open source tool that improves identification of vulnerabilities in your project with just one command. - ZupIT/horusec
👍1
Шифрование трафика в Kubernetes
Всем привет!
Первое, что приходит на ум при фразе «шифрование трафика в Kubernetes» - использование Service Mesh и их функционала mTLS.
Но что, если по какой-то причине не хочется использовать указанную выше технологию? Можно ли решить задачу как-то иначе?
В статье Автор рассматривает вариант использования Cert Manager. Сам подход состоит из нескольких этапов (при условии, что Cert Manager уже установлен и произведена базовая настройка):
🍭 Создание Issuer для CA-сертификата
🍭 Выпуск CA-сертификата
🍭 Распространение CA-сертификата во все необходимые namespace с использованием возможности Trust от Cert Manager (по факту – создание ConfigMap с необходимыми данными)
🍭 Создание ClusterIssuer для выпуска сертификатов
🍭 Выпуск сертификата и его дальнейшее использование
Больше про возможности Cert Manager можно прочитать в документации, доступной по ссылке.
Всем привет!
Первое, что приходит на ум при фразе «шифрование трафика в Kubernetes» - использование Service Mesh и их функционала mTLS.
Но что, если по какой-то причине не хочется использовать указанную выше технологию? Можно ли решить задачу как-то иначе?
В статье Автор рассматривает вариант использования Cert Manager. Сам подход состоит из нескольких этапов (при условии, что Cert Manager уже установлен и произведена базовая настройка):
🍭 Создание Issuer для CA-сертификата
🍭 Выпуск CA-сертификата
🍭 Распространение CA-сертификата во все необходимые namespace с использованием возможности Trust от Cert Manager (по факту – создание ConfigMap с необходимыми данными)
🍭 Создание ClusterIssuer для выпуска сертификатов
🍭 Выпуск сертификата и его дальнейшее использование
Больше про возможности Cert Manager можно прочитать в документации, доступной по ссылке.
Medium
Kubernetes in-cluster traffic encryption using cert-manager
There are several cases when people need to implement traffic encryption of services running within their Kubernetes cluster but a service…
Kubernetes API Server: что внутри?
Всем привет!
Когда схематично отображают архитектуру Kubernetes, зачастую рисуют всего один «квадратик» для обозначения API Server. Но так ли это?
Есть две статьи, которые отлично описывают, что происходит, когда выполняется команда
🍭 Получение запроса HTTP Handler’ом
🍭 Аутентификация (есть ли у вас доступ к кластеру)
🍭 Авторизация (можете ли вы делать то, что собрались)
🍭 Mutation Admission Controller (добавление «недостающего», например, ImagePullPolicy: always, если вы не указали иное)
🍭 Schema Validation (убеждаемся, что «все на своих местах и ничего не забыто»)
🍭 Validation Admission Controller (можно ли создать то, что вы просите? А если указан валидный, но не существующий Namespace?)
🍭 Resource Handler (десериализация сущности, создание объекта в памяти и помещение в etcd)
При этом многие из указанных «уровней» можно расширять – Mutating (например, Istio или Vault, которые добавляют свои параметры на основе аннотаций), Validating (тот самый OPA Gatekeeper и Kyverno), можно даже регистрировать собственные API. Да, k8s по факту – это большой «конструктор».
Во второй статье в разы больше деталей. Она дает еще большее представление о том, что происходит «под капотом»!!!
Поэтому, для беглого ознакомления рекомендуем прочесть первую статью (~ 4 минуты), а для вдумчивого погружения, когда есть достаточно времени – вторую.
Всем привет!
Когда схематично отображают архитектуру Kubernetes, зачастую рисуют всего один «квадратик» для обозначения API Server. Но так ли это?
Есть две статьи, которые отлично описывают, что происходит, когда выполняется команда
kubectl apply -f pod.yaml.
В первой меньше деталей, но очень наглядно и понятно описываются шаги:🍭 Получение запроса HTTP Handler’ом
🍭 Аутентификация (есть ли у вас доступ к кластеру)
🍭 Авторизация (можете ли вы делать то, что собрались)
🍭 Mutation Admission Controller (добавление «недостающего», например, ImagePullPolicy: always, если вы не указали иное)
🍭 Schema Validation (убеждаемся, что «все на своих местах и ничего не забыто»)
🍭 Validation Admission Controller (можно ли создать то, что вы просите? А если указан валидный, но не существующий Namespace?)
🍭 Resource Handler (десериализация сущности, создание объекта в памяти и помещение в etcd)
При этом многие из указанных «уровней» можно расширять – Mutating (например, Istio или Vault, которые добавляют свои параметры на основе аннотаций), Validating (тот самый OPA Gatekeeper и Kyverno), можно даже регистрировать собственные API. Да, k8s по факту – это большой «конструктор».
Во второй статье в разы больше деталей. Она дает еще большее представление о том, что происходит «под капотом»!!!
Поэтому, для беглого ознакомления рекомендуем прочесть первую статью (~ 4 минуты), а для вдумчивого погружения, когда есть достаточно времени – вторую.
Medium
The Kubernetes API architecture
The API has a single block in the diagram, but the reality is that several components are involved in processing your request in sequence. You can register your noscripts and design your checks to…
👍2
Kubernetes Secrets: так ли небезопасно?
Всем привет!
Известно, что Secrets в Kubernetes это просто base64 encoded строка. В связи с этим очень часто встречается мнение, что это не безопасно и надо управлять секретами как-то «иначе».
В статье Автор пытается разобраться, а так ли это на самом деле? Он рассматривает следующие возможные угрозы:
🍭 Извлечение секретов из памяти
🍭 Root-доступ на Master/Worker Nodes
🍭 Физический доступ к Control Plane node
🍭 Иные атаки, которые могут появиться в будущем
Далее для каждой из них он описывает возможные способы противодействия – от использования возможностей k8s до применения key management systems (в том числе HashiCorp Vault).
Какой вывод сделал Автор? Рекомендуем прочитать статью, чтобы узнать ответ: она достаточно короткая и в ней много полезных размышлений.
Всем привет!
Известно, что Secrets в Kubernetes это просто base64 encoded строка. В связи с этим очень часто встречается мнение, что это не безопасно и надо управлять секретами как-то «иначе».
В статье Автор пытается разобраться, а так ли это на самом деле? Он рассматривает следующие возможные угрозы:
🍭 Извлечение секретов из памяти
🍭 Root-доступ на Master/Worker Nodes
🍭 Физический доступ к Control Plane node
🍭 Иные атаки, которые могут появиться в будущем
Далее для каждой из них он описывает возможные способы противодействия – от использования возможностей k8s до применения key management systems (в том числе HashiCorp Vault).
Какой вывод сделал Автор? Рекомендуем прочитать статью, чтобы узнать ответ: она достаточно короткая и в ней много полезных размышлений.
Macchaffee
Plain Kubernetes Secrets are fine
Mac's Tech Blog
Chaos Engineering в Expedia Group
Привет!
Отличная статья, посвященная развитию практики Chaos Engineering в Expedia Group. В ней описан полный жизненный цикл – от идеи до реализации.
Авторы прошли следующий путь:
🍭 Понимание важности анализа доступности сервисов при различных обстоятельствах («смерть» pod, ограничение пропускной способности сети, наличие disk pressure и т.д.)
🍭 Выбор инструмента (spoiler: им стал Chaos Controller от DataDog)
🍭 Определение актуальных сценариев (fault injection) для Компании
🍭 Интеграция с кластером k8s, системами мониторинга, CD (в качестве которой был Spinnaker)
🍭 Создание собственного продукта – Chaos Engineering Product – который включил в себя опыт, полученный при реализации предыдущих этапов
Каждый шаг пути неплохо описан в статье, есть примеры и объяснения, как ребята к этом пришли. Отдельно рекомендуем прочитать про Chaos Controller от DataDog и примеры его использования.
Привет!
Отличная статья, посвященная развитию практики Chaos Engineering в Expedia Group. В ней описан полный жизненный цикл – от идеи до реализации.
Авторы прошли следующий путь:
🍭 Понимание важности анализа доступности сервисов при различных обстоятельствах («смерть» pod, ограничение пропускной способности сети, наличие disk pressure и т.д.)
🍭 Выбор инструмента (spoiler: им стал Chaos Controller от DataDog)
🍭 Определение актуальных сценариев (fault injection) для Компании
🍭 Интеграция с кластером k8s, системами мониторинга, CD (в качестве которой был Spinnaker)
🍭 Создание собственного продукта – Chaos Engineering Product – который включил в себя опыт, полученный при реализации предыдущих этапов
Каждый шаг пути неплохо описан в статье, есть примеры и объяснения, как ребята к этом пришли. Отдельно рекомендуем прочитать про Chaos Controller от DataDog и примеры его использования.
Medium
Chaos Engineering at Expedia Group
Building platforms requires connecting building blocks
Deserealization Labs
Всем привет!
Ребята из NotSoSecure подготовили playground, посвященный уязвимостям, связанным с десериализацией (deserealization).
Он представляет из себя виртуальную машину, в которой собраны уязвимые приложения, написанные на:
🍭 Java
🍭 PHP
🍭 Python
🍭 Node
При решении лабораторных можно воспользоваться Serialized Payload Generator. А если совсем не получается, то в repo есть ссылки на решения, в которых все детально описано.
P.S. Все материалы, связанные с offensive предназначены только для обучения.
Всем привет!
Ребята из NotSoSecure подготовили playground, посвященный уязвимостям, связанным с десериализацией (deserealization).
Он представляет из себя виртуальную машину, в которой собраны уязвимые приложения, написанные на:
🍭 Java
🍭 PHP
🍭 Python
🍭 Node
При решении лабораторных можно воспользоваться Serialized Payload Generator. А если совсем не получается, то в repo есть ссылки на решения, в которых все детально описано.
P.S. Все материалы, связанные с offensive предназначены только для обучения.
GitHub
GitHub - NotSoSecure/NotSoCereal-Lab: NotSoCereal: A Deserialization exploit playground
NotSoCereal: A Deserialization exploit playground. Contribute to NotSoSecure/NotSoCereal-Lab development by creating an account on GitHub.
👍3
Хранение k8s Secrets в git с использованием Bitnami Sealed Secrets
Всем привет!
Если вы любите/хотите использовать IaC подход при работе с Kubernetes, то он «сработает» для всего, за исключением Secrets.
Для решения этой задачи ребята из Bitnami сделали (и продолжают развивать) open source продукт Sealed Secrets.
В статье приводится обзор технологии и пример использования. Само решение состоит из нескольких компонентов:
🍭 Утилита/агент Kubeseal. Ее задача «создавать» Sealed Secret, в котором будет зашифрован интересующий нас Kubernetes Secret
🍭 Cluster Controller/Operator. Его задача следить за «трансформацией» (расшифровкой и превращением Sealed Secret в Kubernetes Secret). У него есть API endpoint, через который с ним можно взаимодействовать
Помимо этого, есть готовый dashboard для Grafana – на нем можно посмотреть сведения о Unsealed Secrets и ошибках.
Если хочется узнать больше, то рекомендуем ознакомиться с информацией в repo. Там, помимо прочего, есть сведения о ротации секретов и что под этим понимается в Sealed Secrets.
Всем привет!
Если вы любите/хотите использовать IaC подход при работе с Kubernetes, то он «сработает» для всего, за исключением Secrets.
Для решения этой задачи ребята из Bitnami сделали (и продолжают развивать) open source продукт Sealed Secrets.
В статье приводится обзор технологии и пример использования. Само решение состоит из нескольких компонентов:
🍭 Утилита/агент Kubeseal. Ее задача «создавать» Sealed Secret, в котором будет зашифрован интересующий нас Kubernetes Secret
🍭 Cluster Controller/Operator. Его задача следить за «трансформацией» (расшифровкой и превращением Sealed Secret в Kubernetes Secret). У него есть API endpoint, через который с ним можно взаимодействовать
Помимо этого, есть готовый dashboard для Grafana – на нем можно посмотреть сведения о Unsealed Secrets и ошибках.
Если хочется узнать больше, то рекомендуем ознакомиться с информацией в repo. Там, помимо прочего, есть сведения о ротации секретов и что под этим понимается в Sealed Secrets.
Medium
How to manage all my K8s secrets in git securely with Bitnami sealed secrets
I can manage all my K8s config in git, except Secrets.
Chain-Bench от Aqua Security: анализ безопасности Software Supply Chain
Всем привет!
Недавно и без того немалое семейство OSS продуктов от Aqua Security (которое включает в себя Kube-Bench, Kube-Hunter, Trivy, TFSec, Postee, Tracee, Starboard) пополнилось еще одним решением – Chain-Bench!
В отличие от своих «братьев и сестер» Chain-Bench направлен на анализ не k8s, а… Software Supply Chain.
«Под капотом» все достаточно стандартно:
🍭 Набор OPA-проверок, реализующих CIS Software Supply Chain Security Guide
🍭 И поддержка GitHub (надеемся, что будет расширение)
Для оценки качества работы необходимо провести некоторые тесты, но выглядит достаточно интересно.
Кстати, тот самый CIS также вышел совсем недавно (июнь 2022). Его мы приложим сразу после этого поста.
И в заключение немного про Trivy! В последнем release (0.29.0) была добавлена возможность анализ RBAC k8s и не только! Подробнее можно прочесть тут.
Всем привет!
Недавно и без того немалое семейство OSS продуктов от Aqua Security (которое включает в себя Kube-Bench, Kube-Hunter, Trivy, TFSec, Postee, Tracee, Starboard) пополнилось еще одним решением – Chain-Bench!
В отличие от своих «братьев и сестер» Chain-Bench направлен на анализ не k8s, а… Software Supply Chain.
«Под капотом» все достаточно стандартно:
🍭 Набор OPA-проверок, реализующих CIS Software Supply Chain Security Guide
🍭 И поддержка GitHub (надеемся, что будет расширение)
Для оценки качества работы необходимо провести некоторые тесты, но выглядит достаточно интересно.
Кстати, тот самый CIS также вышел совсем недавно (июнь 2022). Его мы приложим сразу после этого поста.
И в заключение немного про Trivy! В последнем release (0.29.0) была добавлена возможность анализ RBAC k8s и не только! Подробнее можно прочесть тут.
GitHub
GitHub - aquasecurity/chain-bench: An open-source tool for auditing your software supply chain stack for security compliance based…
An open-source tool for auditing your software supply chain stack for security compliance based on a new CIS Software Supply Chain benchmark. - aquasecurity/chain-bench
👍4
CIS_SSC.pdf
642.9 KB
И тот самый CIS Software Supply Chain Security Guide.
Документ «разбит» на части:
🍭 Source Code
🍭 Build Pipelines
🍭 Dependencies
🍭 Artifacts
🍭 Deployment
Каждый из вышеуказанных разделов содержит небольшие подразделы, всего в документе ~ 66 страниц. Приятного изучения!
Документ «разбит» на части:
🍭 Source Code
🍭 Build Pipelines
🍭 Dependencies
🍭 Artifacts
🍭 Deployment
Каждый из вышеуказанных разделов содержит небольшие подразделы, всего в документе ~ 66 страниц. Приятного изучения!
👍1
Пропадающие Secrets в Kubernetes
Всем привет!
Интересная статья от Rory McCune, где он размышляет о секретах в Kubernetes. При создании ServiceAccount (SA) Kubernetes создает ей Secret. Но можно сделать и наоборот – при создании Secret с использованием Annotations можно указать к какой SA он должен «прикрепиться».
А что, если указать несуществующую SA? Применить такой манифест получится, в ответ мы получим, что Secret был создан, вот только… его не будет. Rory попробовал сделать аналогичное упражнение с существующей SA – все работает. Забавно, что при Edit-операции и изменения существующей SA на несуществующую Secret опять пропадет. При этом он пропадет и из ETCD.
Причиной стал один их многих Controllers K8S, а именно – Token Controller, который, в том числе «watches ServiceAccount token Secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the Secret if needed», но удаляет ли он что-либо?
Для проверки гипотезы (что Token Controller удаляет Secret при отсутствии валидной SA) Rory сделал простенькую Audit Policy и посмотрел, что именно ему вернет Kube-ApiServer при попытке создания Secret. Итог –
Всем привет!
Интересная статья от Rory McCune, где он размышляет о секретах в Kubernetes. При создании ServiceAccount (SA) Kubernetes создает ей Secret. Но можно сделать и наоборот – при создании Secret с использованием Annotations можно указать к какой SA он должен «прикрепиться».
А что, если указать несуществующую SA? Применить такой манифест получится, в ответ мы получим, что Secret был создан, вот только… его не будет. Rory попробовал сделать аналогичное упражнение с существующей SA – все работает. Забавно, что при Edit-операции и изменения существующей SA на несуществующую Secret опять пропадет. При этом он пропадет и из ETCD.
Причиной стал один их многих Controllers K8S, а именно – Token Controller, который, в том числе «watches ServiceAccount token Secret addition, and ensures the referenced ServiceAccount exists, and adds a token to the Secret if needed», но удаляет ли он что-либо?
Для проверки гипотезы (что Token Controller удаляет Secret при отсутствии валидной SA) Rory сделал простенькую Audit Policy и посмотрел, что именно ему вернет Kube-ApiServer при попытке создания Secret. Итог –
"kind": "DeleteOptions". Такое вот интересное поведение, подробнее о котором можно прочесть в самой статье.raesene.github.io
Fun with secrets - Where did they go?
StateofOSS.pdf
26.3 MB
State of Open Source Security, 2022 от Snyk
Привет!
В приложении доступен отчет, посвященный безопасности использования open source, подготовленный Snyk.
Внутри можно найти информацию:
🍭 Мнение компаний о важности анализа OSS, наличия практик контроля
🍭 Кто развивает практики обеспечения ИБ OSS
🍭 Небольшая статистика по использованию зависимостей, связанная с языками программирования
🍭 «Каналы» получения информации об уязвимостях и многое другое
Сам по себе отчет достаточно небольшой, всего 35 страниц.
Привет!
В приложении доступен отчет, посвященный безопасности использования open source, подготовленный Snyk.
Внутри можно найти информацию:
🍭 Мнение компаний о важности анализа OSS, наличия практик контроля
🍭 Кто развивает практики обеспечения ИБ OSS
🍭 Небольшая статистика по использованию зависимостей, связанная с языками программирования
🍭 «Каналы» получения информации об уязвимостях и многое другое
Сам по себе отчет достаточно небольшой, всего 35 страниц.
Exposed Kubernetes Clusters
Всем привет!
Ребята из Cyble провели небольшое исследование по анализу кластеров Kubernetes, доступных из сети интернет.
Получились неоднозначные результаты: с одной стороны все не так и плохо, с другой misconfigurations все же встречаются, чем может воспользоваться потенциальный злоумышленник. Самыми частыми exposed ports оказались: 443/6443 и 10250.
Статистика примерно такая:
🍭 ~ 975k вернуло 403 ошибку, forbidden, RBAC «не пропустил»
🍭~ 5k вернуло 401 ошибку, unauthorized
🍭~ 800 вернуло 200 (!), что означает возможность взаимодействия с кластером
Вывод простой – не надо пренебрегать настройками Kubernetes, которыми можно воспользоваться для повышения уровня ИБ кластера. Подробнее с результатами исследования можно ознакомиться в самой статье.
Всем привет!
Ребята из Cyble провели небольшое исследование по анализу кластеров Kubernetes, доступных из сети интернет.
Получились неоднозначные результаты: с одной стороны все не так и плохо, с другой misconfigurations все же встречаются, чем может воспользоваться потенциальный злоумышленник. Самыми частыми exposed ports оказались: 443/6443 и 10250.
Статистика примерно такая:
🍭 ~ 975k вернуло 403 ошибку, forbidden, RBAC «не пропустил»
🍭~ 5k вернуло 401 ошибку, unauthorized
🍭~ 800 вернуло 200 (!), что означает возможность взаимодействия с кластером
Вывод простой – не надо пренебрегать настройками Kubernetes, которыми можно воспользоваться для повышения уровня ИБ кластера. Подробнее с результатами исследования можно ознакомиться в самой статье.
Cyble
Exposed Kubernetes Clusters - Cyble
Cyble analyzes the instances of misconfigured Kubernetes clusters and how they could potentially be exploited by Threat Actors.
Обучающий курс по Sigstore!
Всем привет!
Недавно ребята из Chainguard совместно с Linux Foundation и OpenSSF запустили бесплатный обучающий курс, направленный на изучение инструментов Sigstore.
Курс включает в себя:
🍭 Introducing Sigstore
🍭 Cosign: Container Signing, Verification, and Storage in an OCI Registry
🍭 Fulcio: A New Kind of Root Certificate Authority For Code Signing
🍭 Rekor: Software Supply Chain Transparency Log
🍭 Sigstore: Using the Tools and Getting Involved with the Community
Курс содержит теоретическую часть и лабораторные работы. После завершения «главы» есть небольшой Knowledge Check, а в самом конце будет Final Exam!
Всем привет!
Недавно ребята из Chainguard совместно с Linux Foundation и OpenSSF запустили бесплатный обучающий курс, направленный на изучение инструментов Sigstore.
Курс включает в себя:
🍭 Introducing Sigstore
🍭 Cosign: Container Signing, Verification, and Storage in an OCI Registry
🍭 Fulcio: A New Kind of Root Certificate Authority For Code Signing
🍭 Rekor: Software Supply Chain Transparency Log
🍭 Sigstore: Using the Tools and Getting Involved with the Community
Курс содержит теоретическую часть и лабораторные работы. После завершения «главы» есть небольшой Knowledge Check, а в самом конце будет Final Exam!
www.chainguard.dev
Get started with Sigstore (Free Course!)
Secure your software supply chain with Sigstore! Enroll in our free course, taught by Chainguard experts, and learn how to implement this powerful new standard. Everything you need to know about securing the software supply chain.
👍2
KubeClarity: SBOM и обзор уязвимостей в образах контейнеров
Всем привет!
KubeClarity – инструмент визуализации информации об уязвимостях в образах контейнерах и о том, что находится «внутри» (Software Bill of Materials, SBOM).
Отличительной особенностью решения является наличие графического интерфейса и dashboards, содержащих информацию:
🍭 Уязвимости, которые можно устранить с разбивкой по уровню критичности
🍭 Top 5 уязвимых компонент (приложения, ресурсы, пакеты)
🍭 Тренды по уязвимостям
🍭 Пакеты по типу лицензий
🍭 Пакеты по языкам программирования
В качестве «анализаторов» используются Grype и Syft, которые предоставляют информацию по уязвимостям и компонентному составу.
О том, что еще есть внутри, как установить и какой roadmap развития продукта можно почитать в самой repo.
Всем привет!
KubeClarity – инструмент визуализации информации об уязвимостях в образах контейнерах и о том, что находится «внутри» (Software Bill of Materials, SBOM).
Отличительной особенностью решения является наличие графического интерфейса и dashboards, содержащих информацию:
🍭 Уязвимости, которые можно устранить с разбивкой по уровню критичности
🍭 Top 5 уязвимых компонент (приложения, ресурсы, пакеты)
🍭 Тренды по уязвимостям
🍭 Пакеты по типу лицензий
🍭 Пакеты по языкам программирования
В качестве «анализаторов» используются Grype и Syft, которые предоставляют информацию по уязвимостям и компонентному составу.
О том, что еще есть внутри, как установить и какой roadmap развития продукта можно почитать в самой repo.
Medium
KubeClarity — Cloud-Native Security Scanning for your Kubernetes Cluster and more
KubeClarity is the latest integrated app to be added to Otomi and can be installed via drag-and-drop to get you running scans in minutes —…
Buildg: интерактивный debugger для Dockerfile
Всем привет!
При помощи buildg можно упростить процесс поиска ошибок при проработке Dockerfile. При помощи него можно:
🍭 Управлять процессом выполнения команды, устанавливать breakpoints
🍭 Взаимодействовать с образом через interactive shell
С перечнем команд, доступных утилите, можно ознакомиться здесь. А в последнем релизе была добавлена интеграция с IDE (в том числе VS Code), чтобы сделать debug-процесс еще более наглядным и удобным.
Для ознакомления с принципами и процессом работы можно ознакомиться со статьей от Авторов buildg.
Всем привет!
При помощи buildg можно упростить процесс поиска ошибок при проработке Dockerfile. При помощи него можно:
🍭 Управлять процессом выполнения команды, устанавливать breakpoints
🍭 Взаимодействовать с образом через interactive shell
С перечнем команд, доступных утилите, можно ознакомиться здесь. А в последнем релизе была добавлена интеграция с IDE (в том числе VS Code), чтобы сделать debug-процесс еще более наглядным и удобным.
Для ознакомления с принципами и процессом работы можно ознакомиться со статьей от Авторов buildg.
GitHub
GitHub - ktock/buildg: Interactive debugger for Dockerfile, with support for IDEs (VS Code, Emacs, Neovim, etc.)
Interactive debugger for Dockerfile, with support for IDEs (VS Code, Emacs, Neovim, etc.) - ktock/buildg
Inspektor Gadget: анализ действий контейнера
Всем привет!
Inspektor Gadget – набор утилит, которые могут быть использованы для повышения уровня ИБ кластера.
Функционально он разделен на блоки:
🍭 Advice. Поможет с генерацией network policy на основе анализа трафика или с созданием seccomp профиля через анализ записанных syscalls
🍭 Audit. Передача сведений о syscalls в лог-файл
🍭 Profile. Получение данных о stack traces
🍭 Snapshot. Сбор сведений о запущенных процессах
🍭 Top. «Визуализация» чего-либо (активных сессий, чтения/записи и т.д.)
🍭 Trace. Сведения о создании новых процессов
Функционала достаточно много, рекомендуем ознакомиться с ним лично. Что удобно – для каждой функции есть описание того, что она делает, примеры запуска и наглядные результаты ее работы.
Всем привет!
Inspektor Gadget – набор утилит, которые могут быть использованы для повышения уровня ИБ кластера.
Функционально он разделен на блоки:
🍭 Advice. Поможет с генерацией network policy на основе анализа трафика или с созданием seccomp профиля через анализ записанных syscalls
🍭 Audit. Передача сведений о syscalls в лог-файл
🍭 Profile. Получение данных о stack traces
🍭 Snapshot. Сбор сведений о запущенных процессах
🍭 Top. «Визуализация» чего-либо (активных сессий, чтения/записи и т.д.)
🍭 Trace. Сведения о создании новых процессов
Функционала достаточно много, рекомендуем ознакомиться с ним лично. Что удобно – для каждой функции есть описание того, что она делает, примеры запуска и наглядные результаты ее работы.
GitHub
GitHub - inspektor-gadget/inspektor-gadget: The eBPF tool and systems inspection framework for Kubernetes, containers and Linux…
The eBPF tool and systems inspection framework for Kubernetes, containers and Linux hosts. - GitHub - inspektor-gadget/inspektor-gadget: The eBPF tool and systems inspection framework for Kubernete...
Architecture as Code
Привет!
Многие слышали про Compliance as Code, Infrastructure as Code, Documentation as Code и т.д. Суть простая – описать что-либо в формате исходного кода (будь то конфигурация или описание процесса), разместить на условном GitHub и взаимодействовать (развивать) как с обычным «приложением».
Вероятно, автор Diagrams подумал, а почему бы не сделать такое для описания архитектуры? В итоге получился проект, который поддерживает написание архитектуры на Python для следующих платформ: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud.
Например, вот такой код:
P.S. Если вам в целом интересна тема автоматизации создания диаграмм/процессов, то рекомендуем обратить внимание вот на эту подборку.
P.P.S. Вообще есть много разных "XXX as Code". В этой статье автор попытался собрать все возможные случаи и их получилось больше 50.
Привет!
Многие слышали про Compliance as Code, Infrastructure as Code, Documentation as Code и т.д. Суть простая – описать что-либо в формате исходного кода (будь то конфигурация или описание процесса), разместить на условном GitHub и взаимодействовать (развивать) как с обычным «приложением».
Вероятно, автор Diagrams подумал, а почему бы не сделать такое для описания архитектуры? В итоге получился проект, который поддерживает написание архитектуры на Python для следующих платформ: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud.
Например, вот такой код:
# importsНарисует красивую схему exposed pods, с количеством replica равным 3. Как это будет выглядеть «по факту» можно узнать в документации, а заодно поближе познакомиться с Diagrams.
with Diagram("Exposed Pod with 3 Replicas", show=False):
net = Ingress("domain.com") >> Service("svc")
net >> [Pod("pod1"),
Pod("pod2"),
Pod("pod3")] << ReplicaSet("rs") << Deployment("dp") << HPA("hpa")
P.S. Если вам в целом интересна тема автоматизации создания диаграмм/процессов, то рекомендуем обратить внимание вот на эту подборку.
P.P.S. Вообще есть много разных "XXX as Code". В этой статье автор попытался собрать все возможные случаи и их получилось больше 50.
Mingrammer
Diagrams · Diagram as Code
🔥6
Хранение секретов в git: подходы и способы автоматизации
Всем привет!
Мы писали про разные способы безопасного хранения секретов в git, но нигде не было единого материала, в котором вся эта информация систематизирована и доступно описана.
И вот он появился! Статья от Jann Fischer и Raffaele Spazzoli, посвященная тому, как можно безопасно хранить секреты в git.
Ребята разбирают 2 группы подходов:
🍭 Шифрование секретов в git. При использовании такого подхода в git хранятся секреты в зашифрованном виде (например, Custom Resource – Sealed Secret для k8S). Использование Sealed Secrets, Mozilla SOPS
🍭 Указание «ссылок» на секреты. В этом сценарии в самих конфигурационных файлах хранятся не секреты, а указатели на системы, где эти самые секреты можно получить. Использование External Secrets и Kubernetes Secret Store CSI
Каждый концепт и подход описан, приводятся примеры использования, а также много ссылок на полезные материалы по теме.
Всем привет!
Мы писали про разные способы безопасного хранения секретов в git, но нигде не было единого материала, в котором вся эта информация систематизирована и доступно описана.
И вот он появился! Статья от Jann Fischer и Raffaele Spazzoli, посвященная тому, как можно безопасно хранить секреты в git.
Ребята разбирают 2 группы подходов:
🍭 Шифрование секретов в git. При использовании такого подхода в git хранятся секреты в зашифрованном виде (например, Custom Resource – Sealed Secret для k8S). Использование Sealed Secrets, Mozilla SOPS
🍭 Указание «ссылок» на секреты. В этом сценарии в самих конфигурационных файлах хранятся не секреты, а указатели на системы, где эти самые секреты можно получить. Использование External Secrets и Kubernetes Secret Store CSI
Каждый концепт и подход описан, приводятся примеры использования, а также много ссылок на полезные материалы по теме.
Redhat
A Guide to Secrets Management with GitOps and Kubernetes
Storing confidential data in Git represents a security vulnerability and should not be allowed, even when the Git repository is considered private and implements access controls to limit the audience. How can we overcome this limitation?
👍1
«Гигиена» CI/CD credentials
Всем привет!
Статья, в которой собраны размышления о том, как можно повысить уровень ИБ и снизить вероятность компрометации секретов, используемых в CI/CD.
Авторы рассматривают 3 основных вектора:
🍭 Unrotated Static Credentials. В качестве «противодействия» предлагается использование 3-ей стороны и OIDC provider
🍭 Overly Accessible Credentials. Грамотная настройка прав доступа на различных «уровнях» (Global/User/Repo/Branch)
🍭 Credentials Exposed in Console Logs. Использование возможностей по маскированию
Кроме общих рекомендаций приводится небольшой обзор возможностей таких CI/CD-систем как: GitHub Actions, CircleCI, Jenkins и GitLab CI.
Всем привет!
Статья, в которой собраны размышления о том, как можно повысить уровень ИБ и снизить вероятность компрометации секретов, используемых в CI/CD.
Авторы рассматривают 3 основных вектора:
🍭 Unrotated Static Credentials. В качестве «противодействия» предлагается использование 3-ей стороны и OIDC provider
🍭 Overly Accessible Credentials. Грамотная настройка прав доступа на различных «уровнях» (Global/User/Repo/Branch)
🍭 Credentials Exposed in Console Logs. Использование возможностей по маскированию
Кроме общих рекомендаций приводится небольшой обзор возможностей таких CI/CD-систем как: GitHub Actions, CircleCI, Jenkins и GitLab CI.