Всем привет!
GitOps – очень интересный подход к управлению deployment. Однако, как и все, он не лишен недостатков.
В статье «The pains of GitOps 1.0» приводятся размышления на тему возможных проблем подхода. Автор выделяет такие как:
🍭 Частичное покрытие жизненного цикла разработки ПО при помощи GitOps
🍭 Не всегда тривиальное разделение CI и CD частей
🍭 Сложность одновременного управления средами (Dev, Test, Prod и т.д.)
🍭 Autoscaling и динамические окружения (как реализовать, когда GitOps вернет все «обратно»?)
🍭 Недостаточная Observability (в management смысле, а не в техническом)
🍭 Не самый простой аудит событий (да, в Git все есть, но это «все» надо еще найти и найти быстро)
🍭 Сложности, связанные с GitOps-управлением большого количества deployments
🍭 Управление секретами и многое другое!
Для каждого тезиса приводится несколько аргументов, его подкрепляющих. Самое интересное – Автор приводит примеры в стиле «В теории – классно, а на практике есть нюансы…». Многие вопросы, поднимаемые в статье, характерны и для «классического» управления deployment’ами. Целью Автора было развенчать миф: «внедрил GitOps и все работает, «как по маслу!», показать что и у него есть недостатки при всех его достоинствах!
Какой можно сделать вывод? GitOps – еще один «маркетинг»? Не думаем. Скорее – «серебряной пули не существует», у всего есть свои сильные и слабые стороны и за все приходится платить. Удобство иногда снижает «гибкость», «гибкость» иногда негативно отображается на управляемости и т.д. Главное при внедрении любой технологии/подхода – понять, нужна ли она вам? И если да, то как ее правильно реализовать и на какие «жертвы» вы готовы пойти.
А что вы думаете о GitOps? Пишите в комментариях!
GitOps – очень интересный подход к управлению deployment. Однако, как и все, он не лишен недостатков.
В статье «The pains of GitOps 1.0» приводятся размышления на тему возможных проблем подхода. Автор выделяет такие как:
🍭 Частичное покрытие жизненного цикла разработки ПО при помощи GitOps
🍭 Не всегда тривиальное разделение CI и CD частей
🍭 Сложность одновременного управления средами (Dev, Test, Prod и т.д.)
🍭 Autoscaling и динамические окружения (как реализовать, когда GitOps вернет все «обратно»?)
🍭 Недостаточная Observability (в management смысле, а не в техническом)
🍭 Не самый простой аудит событий (да, в Git все есть, но это «все» надо еще найти и найти быстро)
🍭 Сложности, связанные с GitOps-управлением большого количества deployments
🍭 Управление секретами и многое другое!
Для каждого тезиса приводится несколько аргументов, его подкрепляющих. Самое интересное – Автор приводит примеры в стиле «В теории – классно, а на практике есть нюансы…». Многие вопросы, поднимаемые в статье, характерны и для «классического» управления deployment’ами. Целью Автора было развенчать миф: «внедрил GitOps и все работает, «как по маслу!», показать что и у него есть недостатки при всех его достоинствах!
Какой можно сделать вывод? GitOps – еще один «маркетинг»? Не думаем. Скорее – «серебряной пули не существует», у всего есть свои сильные и слабые стороны и за все приходится платить. Удобство иногда снижает «гибкость», «гибкость» иногда негативно отображается на управляемости и т.д. Главное при внедрении любой технологии/подхода – понять, нужна ли она вам? И если да, то как ее правильно реализовать и на какие «жертвы» вы готовы пойти.
А что вы думаете о GitOps? Пишите в комментариях!
Codefresh
The pains of GitOps 1.0
GitOps as a practice for releasing software has several advantages, but like all other solutions before it, has also several shortcomings. It seems that the honeymoon period is now over, and we can finally talk about the issues of GitOps (and the current…
Привет!
Недавно обновился HashiCorp Vault Plugin для Jenkins. Есть Breaking Changes, а есть bug fix, который может быть в разы значительнее, чем добавление
Речь идет о «fixing the fallback to get the config to access Vault». В plugin была возможность использовать Credentials для доступа к Vault, задаваемых на разных уровнях: Folder, либо Global. Достаточно удобно, если вы используете Folder, реализована ролевая модель доступа и вы хотите, чтобы каждый проект в Folder использовал собственные учетные данные для аутентификации в Vault, а не единые для всех (Global).
Однако, даже при наличии соответствующих настроек, учетные данные уровня Folder не всегда использовались. Например, использование конструкции
Именно эту проблему и устраняет рассматриваемое обновление! Теперь все должно работать корректно:
Недавно обновился HashiCorp Vault Plugin для Jenkins. Есть Breaking Changes, а есть bug fix, который может быть в разы значительнее, чем добавление
Secret File Credential Type (того самого breaking change).Речь идет о «fixing the fallback to get the config to access Vault». В plugin была возможность использовать Credentials для доступа к Vault, задаваемых на разных уровнях: Folder, либо Global. Достаточно удобно, если вы используете Folder, реализована ролевая модель доступа и вы хотите, чтобы каждый проект в Folder использовал собственные учетные данные для аутентификации в Vault, а не единые для всех (Global).
Однако, даже при наличии соответствующих настроек, учетные данные уровня Folder не всегда использовались. Например, использование конструкции
withCredentials все равно будет использовать параметры, заданные в Global.Именно эту проблему и устраняет рассматриваемое обновление! Теперь все должно работать корректно:
From pipeline => Possible parents (Folder Item) => Jenkins Global config. Таким образом, каждый проект в Folder будет использовать собственные учетные данные для аутентификации в Vault, а если они не указаны, то будет использована Global-конфигурация. Осталось только протестировать ☺️GitHub
Release 336.v182c0fbaaeb7 · jenkinsci/hashicorp-vault-plugin
💥 Breaking changes
Add secret file credential type (#178) @jamesrobson-secondmind
🚀 New features and improvements
Add credential type to authenticate with Google Container Registry (#179) @james...
Add secret file credential type (#178) @jamesrobson-secondmind
🚀 New features and improvements
Add credential type to authenticate with Google Container Registry (#179) @james...
Привет!
Детальный материал (с примерами и screenshots), в котором описан kill chain по «захвату» nodes кластера K8S. От эксплуатации уязвимости в запущенном на нем web-приложении до получения root-доступа на node.
Статья хоть и не самая новая (2018 год), но все равно может оказаться полезной.
Последовательность действий:
🍭 Анализ web-сайта, поиск уязвимостей (DirBuster)
🍭 «Проникновение» в контейнер через RCE-уязвимость. Установка необходимых «инструментов для дальнейшей работы» (Metasploit, Meterpreter)
🍭 Чтение Service Account (SA) Token. «Установка» kubectl. Изучение возможностей SA (list, create, exec и т.д.)
🍭 «Прыжок» в другой контейнер, SA которого обладает большими возможностями
🍭 Создание pod, с mount /root:/ - AttackerPod
🍭 Изменение пароля пользователя, входящего в sudo группу от имени root. SSH на node.
🍭 Но и этого оказалось мало для автора! Создание DaemonSet с AttackerPod и повтор аналогичных действий для компрометации всех nodes кластера
Статья - хорошо структурированный материал, который объединяет в себе несколько инструментов, тактик и техник, реализация которых привела к компрометации кластера. «Вишенкой» является интересный и простой слог автора ☺️
P.S. В конце статьи приводятся рекомендации – как можно было этого избежать? С одной стороны, достаточно простые меры и «все понятно». С другой – лишний повод задуматься о том, что даже встроенные возможности кластера K8S по ИБ могут дать многое и не стоит пренебрегать их настройками.
P.P.S. Preview к ссылке не работает, дублируем: https://www.inguardians.com/blog/attacking-and-defending-kubernetes-bust-a-kube-episode-1/
Детальный материал (с примерами и screenshots), в котором описан kill chain по «захвату» nodes кластера K8S. От эксплуатации уязвимости в запущенном на нем web-приложении до получения root-доступа на node.
Статья хоть и не самая новая (2018 год), но все равно может оказаться полезной.
Последовательность действий:
🍭 Анализ web-сайта, поиск уязвимостей (DirBuster)
🍭 «Проникновение» в контейнер через RCE-уязвимость. Установка необходимых «инструментов для дальнейшей работы» (Metasploit, Meterpreter)
🍭 Чтение Service Account (SA) Token. «Установка» kubectl. Изучение возможностей SA (list, create, exec и т.д.)
🍭 «Прыжок» в другой контейнер, SA которого обладает большими возможностями
🍭 Создание pod, с mount /root:/ - AttackerPod
🍭 Изменение пароля пользователя, входящего в sudo группу от имени root. SSH на node.
🍭 Но и этого оказалось мало для автора! Создание DaemonSet с AttackerPod и повтор аналогичных действий для компрометации всех nodes кластера
Статья - хорошо структурированный материал, который объединяет в себе несколько инструментов, тактик и техник, реализация которых привела к компрометации кластера. «Вишенкой» является интересный и простой слог автора ☺️
P.S. В конце статьи приводятся рекомендации – как можно было этого избежать? С одной стороны, достаточно простые меры и «все понятно». С другой – лишний повод задуматься о том, что даже встроенные возможности кластера K8S по ИБ могут дать многое и не стоит пренебрегать их настройками.
P.P.S. Preview к ссылке не работает, дублируем: https://www.inguardians.com/blog/attacking-and-defending-kubernetes-bust-a-kube-episode-1/
Пятница!
Debug – не самое простое занятие… Но его можно сделать немного более приятным, особенно, когда знаешь что искать и как сделать вывод наглядным!
В статье описываются 12 команд, которые, по мнению автора, помогут упростить debug нагрузок в кластере (workloads).
Команды сгруппированы для поиска проблем нескольких типов: «Workloads won’t run», «Cannot access workloads» и «Debug specific pods».
Примеры команд, которые приведены в статье:
🍭
P.S. Всем отличных выходных и вечера пятницы! До Нового Года осталась 1 неделя!!!
Debug – не самое простое занятие… Но его можно сделать немного более приятным, особенно, когда знаешь что искать и как сделать вывод наглядным!
В статье описываются 12 команд, которые, по мнению автора, помогут упростить debug нагрузок в кластере (workloads).
Команды сгруппированы для поиска проблем нескольких типов: «Workloads won’t run», «Cannot access workloads» и «Debug specific pods».
Примеры команд, которые приведены в статье:
🍭
kubectl get events –field-selector type=Warning –all-namespaces
🍭 kubectl resource-capacity –pods –util –sort cpu.util
🍭 kubectl lineage pod ${POD}
🍭 kubectl get endpointslices -o wide
🍭 kubectl debug pod –it –image=%image% $POD и другие
В статье приводится краткое описание причин использования команд и ссылки на open source утилиты, которые помогут еще больше упростить процесс поиска ошибок! Вместе с детальной debug-схемой (о которой мы писали тут) получается инструмент, которые отвечает на вопросы «Что искать? Как искать?». Если хочется чуть больше визуализации, можно посмотреть в сторону K9S (о которой мы писали тут).P.S. Всем отличных выходных и вечера пятницы! До Нового Года осталась 1 неделя!!!
The New Stack
Living with Kubernetes: 12 Commands to Debug Your Workloads
Kubernetes can’t fix broken code. But if your container won’t start or the application gets intermittent errors, here’s where you can start.
Привет!
По ссылке доступна статья, детализирующая проблематику управления GitOps с использованием branches (об иных «тонких местах» работы с GitOps мы писали вот тут).
Автор ставит простой вопрос – «How do I promote a release to the next environment?» и описывает, почему ветвление в Git (branches) не является лучшей практикой:
🍭 В теории – promotion == git merge, на практике, как обычно, бывают нюансы
🍭 Сложности использования pull/merge request при большом количестве сред
🍭 Возможный configuration drift (особенно явно это видно при внесении hotfix)
🍭 Потребность поддержки и управления большим количеством branches и другие
Что же делать? И как правильно организовать работу с Git? Автор, в лучших традициях Адриано Челентано интригует и просит подождать следующей статьи, где ответит на этот вопрос! 😊
По ссылке доступна статья, детализирующая проблематику управления GitOps с использованием branches (об иных «тонких местах» работы с GitOps мы писали вот тут).
Автор ставит простой вопрос – «How do I promote a release to the next environment?» и описывает, почему ветвление в Git (branches) не является лучшей практикой:
🍭 В теории – promotion == git merge, на практике, как обычно, бывают нюансы
🍭 Сложности использования pull/merge request при большом количестве сред
🍭 Возможный configuration drift (особенно явно это видно при внесении hotfix)
🍭 Потребность поддержки и управления большим количеством branches и другие
Что же делать? И как правильно организовать работу с Git? Автор, в лучших традициях Адриано Челентано интригует и просит подождать следующей статьи, где ответит на этот вопрос! 😊
Medium
Stop Using Branches for Deploying to Different GitOps Environments
In our big guide for GitOps problems, we briefly explained (see points 3 and 4) how the current crop of GitOps tools don’t really cover the…
Привет!
Существует большое количество frameworks, посвященных тематике защиты сред контейнерной оркестрации.
Как правило, все они содержат упоминания нижеуказанных доменов:
🍭 Лучшие практики по архитектуре
🍭 Безопасность в CI/CD
🍭 Защита ресурсов
🍭 Защита runtime
🍭 Безопасность цепочки поставок (supply chain)
🍭 Сетевая безопасность
🍭 Управление уязвимостями и compliance-несоответствиями
🍭 Управление секретами
В статье приводится небольшой обзор таких framework как: CIS Kubernetes Benchmark, The MITRE ATT&CK® Framework for Kubernetes, PCI DSS Compliance for Kubernetes, NIST Application Container Security Framework, NSA-CISA Kubernetes Hardening Guide. Для каждого из них приводится общее описание, его сильные/слабые стороны и небольшие рекомендации по его использованию/автоматизации.
Существует еще один checklist, который не попал в список, но достоин упоминания – «Kubernetes Security Checklist and Requirements» от автора канала «DevSecOps Wine». Материал доступен как на русском, так и на английском языках.
Существует большое количество frameworks, посвященных тематике защиты сред контейнерной оркестрации.
Как правило, все они содержат упоминания нижеуказанных доменов:
🍭 Лучшие практики по архитектуре
🍭 Безопасность в CI/CD
🍭 Защита ресурсов
🍭 Защита runtime
🍭 Безопасность цепочки поставок (supply chain)
🍭 Сетевая безопасность
🍭 Управление уязвимостями и compliance-несоответствиями
🍭 Управление секретами
В статье приводится небольшой обзор таких framework как: CIS Kubernetes Benchmark, The MITRE ATT&CK® Framework for Kubernetes, PCI DSS Compliance for Kubernetes, NIST Application Container Security Framework, NSA-CISA Kubernetes Hardening Guide. Для каждого из них приводится общее описание, его сильные/слабые стороны и небольшие рекомендации по его использованию/автоматизации.
Существует еще один checklist, который не попал в список, но достоин упоминания – «Kubernetes Security Checklist and Requirements» от автора канала «DevSecOps Wine». Материал доступен как на русском, так и на английском языках.
Medium
Comparing Kubernetes Security Frameworks and Guidance
TL;DR — Comparing popular Kubernetes security and compliance frameworks, how they differ, when to use, common goals, and suggested tools
👍1
Tracee — это runtime security утилита для контейнерных сред. Она использует технологию Linux eBPF для отслеживания событий в реальном времени и анализа шаблонов поведения.
Tracee позволяет увидеть развитие атаки и провести её расследование. К тому же, в отличие от многих freeware-продуктов, tracee имеет широкую поддержку вендора.
🍏 Например, в этом воркшопе (который является частью целого курса на гитхабе) показаны базовые функции Tracee и интеграция утилиты со Slack.
🍏 Эта статья в блоге Aquasec содержит руководство по установке Tracee в кластер Kubernetes и обнаружению атаки. Можно увидеть работу Tracee на примере эксплуатации уязвимого приложения.
🍏 А в этой статье описано создание кастомных правил, представляющих из себя сигнатуры тех или иных атак. В tracee есть неплохой набор правил "из коробки", но для обнаружения новейших атак его может оказаться недостаточно, поэтому важно уметь дописывать правила самому. К тому же, новые сигнатуры широко приветствуются вендором и помогают развивать продукт.
Tracee позволяет увидеть развитие атаки и провести её расследование. К тому же, в отличие от многих freeware-продуктов, tracee имеет широкую поддержку вендора.
🍏 Например, в этом воркшопе (который является частью целого курса на гитхабе) показаны базовые функции Tracee и интеграция утилиты со Slack.
🍏 Эта статья в блоге Aquasec содержит руководство по установке Tracee в кластер Kubernetes и обнаружению атаки. Можно увидеть работу Tracee на примере эксплуатации уязвимого приложения.
🍏 А в этой статье описано создание кастомных правил, представляющих из себя сигнатуры тех или иных атак. В tracee есть неплохой набор правил "из коробки", но для обнаружения новейших атак его может оказаться недостаточно, поэтому важно уметь дописывать правила самому. К тому же, новые сигнатуры широко приветствуются вендором и помогают развивать продукт.
GitHub
workshop-cloud-native-security/runtime.md at main · krol3/workshop-cloud-native-security
workshop about cloud-native security. Contribute to krol3/workshop-cloud-native-security development by creating an account on GitHub.
C Наступающим!!!
Этот год был непростым… Год получился очень насыщенным и интересным, тематика DevSecOps еще активнее начала развиваться на рынке РФ, что не может не радовать!
Надеемся, что в следующем году будет еще больше интересных тем для обсуждения, больше очных встреч community (не знаем как вам, но нам тоскливо без теплого лампового личного общения) и, конечно же, больше DevSecOps во всех его проявлениях!
Спасибо за то, что вы с нами, за обратную связь!!! Надеемся, что наши посты вам интересны и приносят некоторую пользу. А если чего-то не хватает – пишите в комментариях ☺️
Желаем вам, чтобы Новогодняя Ночь была воистину чудесной, здоровья вам и ваших близким!!! И пусть новый год принесет радость и удовольствие!!!
Спасибо и до встречи в Новом Году!!! - Ваша команда Jet DevSecOps Team ☺️
Надеемся, что в следующем году будет еще больше интересных тем для обсуждения, больше очных встреч community (не знаем как вам, но нам тоскливо без теплого лампового личного общения) и, конечно же, больше DevSecOps во всех его проявлениях!
Спасибо за то, что вы с нами, за обратную связь!!! Надеемся, что наши посты вам интересны и приносят некоторую пользу. А если чего-то не хватает – пишите в комментариях ☺️
Желаем вам, чтобы Новогодняя Ночь была воистину чудесной, здоровья вам и ваших близким!!! И пусть новый год принесет радость и удовольствие!!!
Спасибо и до встречи в Новом Году!!! - Ваша команда Jet DevSecOps Team ☺️
👍2
Всем привет!
Хорошая обзорная статья на тему ServiceMesh, в которой кратко описано назначение – управление трафиком между приложениями через создание mesh-сети и выгоды от использования подобной технологии:
🍭 Управление трафиком (например, dynamic service discovery и routing)
🍭 Повышение observability (ServiceMesh «видит» весь трафик и поможет в сборе большого количества метрик, необходимых для понимания общего состояния сети или при поиске ошибок)
🍭 Усиление информационной безопасности (mutual TLS, сетевое сегментирование)
Указанный выше перечень далеко не полный и сильно зависит от выбранной ServiceMesh технологии, а также от ее конкретной реализации.
Далее в статье приводится небольшой обзор Istio – из чего она состоит, зачем и как использует sidecar, как всем этим управлять через Istio Control Plane, кратко описывается функционал решения. А в завершении – как установить и немного примеров использования ☺️
Хорошая обзорная статья на тему ServiceMesh, в которой кратко описано назначение – управление трафиком между приложениями через создание mesh-сети и выгоды от использования подобной технологии:
🍭 Управление трафиком (например, dynamic service discovery и routing)
🍭 Повышение observability (ServiceMesh «видит» весь трафик и поможет в сборе большого количества метрик, необходимых для понимания общего состояния сети или при поиске ошибок)
🍭 Усиление информационной безопасности (mutual TLS, сетевое сегментирование)
Указанный выше перечень далеко не полный и сильно зависит от выбранной ServiceMesh технологии, а также от ее конкретной реализации.
Далее в статье приводится небольшой обзор Istio – из чего она состоит, зачем и как использует sidecar, как всем этим управлять через Istio Control Plane, кратко описывается функционал решения. А в завершении – как установить и немного примеров использования ☺️
Baeldung on Ops
Service Mesh Architecture with Istio | Baeldung on Ops
A comprehensive introduction to service meshes using Istio as an example.
Всем привет!
ThreatMapper – проект DeepFence, который позволяет визуализировать то, что запущено на кластере и проводить анализ уязвимостей. Получается некоторое объединение Observeability и Vulnerability Management.
Можно посмотреть общую информацию о среде:
🍭 Взаимосвязь объектов между собой
🍭 Информацию о сетевых взаимодействиях
🍭 Информацию о запущенных процессах
🍭 Metadata запущенных workloads
С уязвимостями чуть интереснее: у проекта есть отличительная особенность (например, от Trivy, которая просто предоставляет информацию об уязвимостях) – приоритизация уязвимостей на основании Risk-Of-Exploit. ThreatMapper предоставляет сведения о пути атаки (Attack Path) на основании информации об уязвимостях.
Доступны интеграции с Registry, Notification, Issue Management и SIEM системами.
Можно посмотреть на инструмент «в деле»: надо просто перейти по ссылке и аутентифицироваться (community@deepfence.io / mzHAmWa!89zRD$KMIZ@ot4SiO)
В git repo проекта есть небольшой обзорный ролик, в котором кратко представлен ключевой функционал решения ☺️
ThreatMapper – проект DeepFence, который позволяет визуализировать то, что запущено на кластере и проводить анализ уязвимостей. Получается некоторое объединение Observeability и Vulnerability Management.
Можно посмотреть общую информацию о среде:
🍭 Взаимосвязь объектов между собой
🍭 Информацию о сетевых взаимодействиях
🍭 Информацию о запущенных процессах
🍭 Metadata запущенных workloads
С уязвимостями чуть интереснее: у проекта есть отличительная особенность (например, от Trivy, которая просто предоставляет информацию об уязвимостях) – приоритизация уязвимостей на основании Risk-Of-Exploit. ThreatMapper предоставляет сведения о пути атаки (Attack Path) на основании информации об уязвимостях.
Доступны интеграции с Registry, Notification, Issue Management и SIEM системами.
Можно посмотреть на инструмент «в деле»: надо просто перейти по ссылке и аутентифицироваться (community@deepfence.io / mzHAmWa!89zRD$KMIZ@ot4SiO)
В git repo проекта есть небольшой обзорный ролик, в котором кратко представлен ключевой функционал решения ☺️
GitHub
GitHub - deepfence/ThreatMapper: Open Source Cloud Native Application Protection Platform (CNAPP)
Open Source Cloud Native Application Protection Platform (CNAPP) - deepfence/ThreatMapper
Привет!
Kubernetes сам по себе не собирает информацию о том, что происходит внутри pods. Для того, чтобы повысить observability и иметь удобный инструмент для поиска проблем необходимо самостоятельно настроить логирование событий и их последующую обработку.
Сделать это можно несколькими способами:
🍭 Установка Logging Agent на Node. Как правило, он ставится в качестве DaemonSet. Настраивается mount для pod/logging agent в директорию на node, куда попадают logs. Далее агент направляет их в соответствующий backend для обработки. Примером такого agent может быть FluentD, backend – ElasticSearch
🍭 Использование Sidecar Logging Agent. Иногда pod может писать logs только в определенные файлы. Как раз тут и может потребоваться sidecar – он перенаправляет данные из указанного файла в stdout/stderr. Далее схема ничем не отличается от вышеописанного варианта
🍭 Sidecar Logging Backend. Нечто среднее между описанными вариантами: установка agent на node не требуется, логи направляются в logging backend силами sidecar logging agent
Единственно правильного ответа на вопрос – «А какой вариант лучше?» - не существует. Все будет зависеть от приложения и от политик обработки логов отдельно взятой Компании. Бывают случаи, когда Компании используют сразу несколько из вышеописанных подходов
Kubernetes сам по себе не собирает информацию о том, что происходит внутри pods. Для того, чтобы повысить observability и иметь удобный инструмент для поиска проблем необходимо самостоятельно настроить логирование событий и их последующую обработку.
Сделать это можно несколькими способами:
🍭 Установка Logging Agent на Node. Как правило, он ставится в качестве DaemonSet. Настраивается mount для pod/logging agent в директорию на node, куда попадают logs. Далее агент направляет их в соответствующий backend для обработки. Примером такого agent может быть FluentD, backend – ElasticSearch
🍭 Использование Sidecar Logging Agent. Иногда pod может писать logs только в определенные файлы. Как раз тут и может потребоваться sidecar – он перенаправляет данные из указанного файла в stdout/stderr. Далее схема ничем не отличается от вышеописанного варианта
🍭 Sidecar Logging Backend. Нечто среднее между описанными вариантами: установка agent на node не требуется, логи направляются в logging backend силами sidecar logging agent
Единственно правильного ответа на вопрос – «А какой вариант лучше?» - не существует. Все будет зависеть от приложения и от политик обработки логов отдельно взятой Компании. Бывают случаи, когда Компании используют сразу несколько из вышеописанных подходов
Medium
Kubernetes Deep Dive: Log Management
Part 28 of a series of articles about learning k8s!
Всем привет!
Если вы всегда хотели знать, в чем разница между mono и poly repo, но боялись спросить, то эта статья для вас!
Автор кратко описывает что это такое:
🍭 Mono repo: единый repo для всех проектов
🍭 Poly repo: отдельный repo для каждого проекта
Казалось бы, все просто и зачем писать статьи про разницу этих подходов? Однако, она (разница) есть и достаточно ощутимая. В статье есть удобная таблица, в которой собраны ключевые отличия Mono/Poly Repo по таким критериям, как: Projects, Workflows, Changes, Testing, Releases и т.д.
Приведены сильные и слабые стороны обоих подходов и ссылки на статьи, в которых можно прочитать больше про «за и против». И, как обычно, универсального ответа на вопрос «Что лучше?» не существует и все выбирается, исходя из решаемой задачи.
Для ИБ-специалистов разница тоже есть – от того, как именно будут встроены проверки по ИБ до управления доступом специалистов к проектам: либо доступ дается ко всему (mono repo), либо доступом можно управлять на уровне отдельно взятого проекта (poly repo). Да, некоторые системы позволяют управлять доступом на ownership к отдельным папкам, но все-таки это труднее реализовать и поддерживать, чем доступ к проекту
Если вы всегда хотели знать, в чем разница между mono и poly repo, но боялись спросить, то эта статья для вас!
Автор кратко описывает что это такое:
🍭 Mono repo: единый repo для всех проектов
🍭 Poly repo: отдельный repo для каждого проекта
Казалось бы, все просто и зачем писать статьи про разницу этих подходов? Однако, она (разница) есть и достаточно ощутимая. В статье есть удобная таблица, в которой собраны ключевые отличия Mono/Poly Repo по таким критериям, как: Projects, Workflows, Changes, Testing, Releases и т.д.
Приведены сильные и слабые стороны обоих подходов и ссылки на статьи, в которых можно прочитать больше про «за и против». И, как обычно, универсального ответа на вопрос «Что лучше?» не существует и все выбирается, исходя из решаемой задачи.
Для ИБ-специалистов разница тоже есть – от того, как именно будут встроены проверки по ИБ до управления доступом специалистов к проектам: либо доступ дается ко всему (mono repo), либо доступом можно управлять на уровне отдельно взятого проекта (poly repo). Да, некоторые системы позволяют управлять доступом на ownership к отдельным папкам, но все-таки это труднее реализовать и поддерживать, чем доступ к проекту
GitHub
GitHub - joelparkerhenderson/monorepo-vs-polyrepo: Monorepo vs. polyrepo: architecture for source code management (SCM) version…
Monorepo vs. polyrepo: architecture for source code management (SCM) version control systems (VCS) - joelparkerhenderson/monorepo-vs-polyrepo
👍4
Всем пятница!
Самое время подумать о грядущих выходных, сладком сне и том, как сломать кластер! Да, вы угадали! Речь снова пойдет о Chaos Engineering!
На этот раз о проекте Kube-Chaos – интерактивной «игре», использующей возможности Unity для элегантной и веселой «поломки» кластера.
Что потребуется:
🍭 Настроенная kubectl с корректным context
🍭 Namespace, который нам не жалко
🍭 Достаточно ресурсов для запуска (как писали выше – используется Unity, это не совсем «утилита», а игровой движок)
Все! Можно ломать, а если ломать не хочется, но хочется посмотреть, как это выглядит – в ссылке на repo можно найти демонстрационный ролик ☺️
Если хочется чуть больше узнать про историю проекта, про то, как Автор совместил 2 своих хобби – game dev и Kubernetes – рекомендуем прочитать вот эту статью.
P.S. Всем отличного вечера пятницы и наипрекраснейших выходных!!!
Самое время подумать о грядущих выходных, сладком сне и том, как сломать кластер! Да, вы угадали! Речь снова пойдет о Chaos Engineering!
На этот раз о проекте Kube-Chaos – интерактивной «игре», использующей возможности Unity для элегантной и веселой «поломки» кластера.
Что потребуется:
🍭 Настроенная kubectl с корректным context
🍭 Namespace, который нам не жалко
🍭 Достаточно ресурсов для запуска (как писали выше – используется Unity, это не совсем «утилита», а игровой движок)
Все! Можно ломать, а если ломать не хочется, но хочется посмотреть, как это выглядит – в ссылке на repo можно найти демонстрационный ролик ☺️
Если хочется чуть больше узнать про историю проекта, про то, как Автор совместил 2 своих хобби – game dev и Kubernetes – рекомендуем прочитать вот эту статью.
P.S. Всем отличного вечера пятницы и наипрекраснейших выходных!!!
GitHub
GitHub - Shogan/kube-chaos: A chaos engineering style game where you seek out and destroy Kubernetes pods, twinstick shmup style.
A chaos engineering style game where you seek out and destroy Kubernetes pods, twinstick shmup style. - Shogan/kube-chaos
Всем привет!
Вопросы, связанные с Observeability, все чаще поднимаются при обсуждении Kubernetes. Возможно, именно поэтому ребята решили сделать tobs – инструмент, задача которого крайне проста: максимально простое и быстрое внедрение Observeability Stack в кластер Kubernetes.
По факту, tobs состоит из нескольких open source инструментов (приведены не все):
🍭 Prometheus – сбор метрик, фактически стандарт отрасли по мониторингу
🍭 AlertManager – создание уведомлений и alert
🍭 Grafana – визуализация
🍭 Node-exporter – экспорт метрик с nodes
🍭 Kube-State-Metrics – получение метрик от kube-apiserver
🍭 Promscale – долгосрочное хранение данных по метрикам для аналитики с PromQL и SQL
🍭 Promlens – быстрый и простой способ управления PromQL-запросами
Подробнее о составе tobs можно посмотреть в repo, включая графическую схему взаимодействия компонентов.
Для установки потребуется скачать cli и следовать дальнейшим инструкциям. Небольшой overview ролик доступен по ссылке.
Вопросы, связанные с Observeability, все чаще поднимаются при обсуждении Kubernetes. Возможно, именно поэтому ребята решили сделать tobs – инструмент, задача которого крайне проста: максимально простое и быстрое внедрение Observeability Stack в кластер Kubernetes.
По факту, tobs состоит из нескольких open source инструментов (приведены не все):
🍭 Prometheus – сбор метрик, фактически стандарт отрасли по мониторингу
🍭 AlertManager – создание уведомлений и alert
🍭 Grafana – визуализация
🍭 Node-exporter – экспорт метрик с nodes
🍭 Kube-State-Metrics – получение метрик от kube-apiserver
🍭 Promscale – долгосрочное хранение данных по метрикам для аналитики с PromQL и SQL
🍭 Promlens – быстрый и простой способ управления PromQL-запросами
Подробнее о составе tobs можно посмотреть в repo, включая графическую схему взаимодействия компонентов.
Для установки потребуется скачать cli и следовать дальнейшим инструкциям. Небольшой overview ролик доступен по ссылке.
GitHub
GitHub - timescale/tobs: tobs - The Observability Stack for Kubernetes. Easy install of a full observability stack into a k8s cluster…
tobs - The Observability Stack for Kubernetes. Easy install of a full observability stack into a k8s cluster with Helm charts. - timescale/tobs
👍1👎1
Всем привет!
Некий аналог awesome, но на этот раз чуть более интерактивный – Houdini: перечень образов для offensive security.
Добавить решение в перечень может кто угодно, главное:
🍭 Указать наименование инструмента
🍭 Предоставить ссылку на образ
🍭 Указать ссылку на документацию
🍭 Добавить вид «run-команды» и кратко описать решение!
На текущий момент в базе уже содержится большое количество инструментов (посмотреть их можно в директории tools).
Они удобно структурированы по группам: recon, reverse, cracker, backdoor и т.д.
Посмотреть на web интерфейс Houdini можно по ссылке.
Некий аналог awesome, но на этот раз чуть более интерактивный – Houdini: перечень образов для offensive security.
Добавить решение в перечень может кто угодно, главное:
🍭 Указать наименование инструмента
🍭 Предоставить ссылку на образ
🍭 Указать ссылку на документацию
🍭 Добавить вид «run-команды» и кратко описать решение!
На текущий момент в базе уже содержится большое количество инструментов (посмотреть их можно в директории tools).
Они удобно структурированы по группам: recon, reverse, cracker, backdoor и т.д.
Посмотреть на web интерфейс Houdini можно по ссылке.
GitHub
GitHub - cybersecsi/houdini: Hundreds of Offensive and Useful Docker Images for Network Intrusion. The name says it all.
Hundreds of Offensive and Useful Docker Images for Network Intrusion. The name says it all. - cybersecsi/houdini
Всем привет!
Функционал Admission Controller очень значим, как минимум, для ИБ-специалистов. Он позволяет контролировать запуск только тех сущностей, которые соответствуют требованиям по ИБ компании и позволяет повысить общий уровень защищенности сред контейнерной оркестрации.
Но кто будет охранять охранников? И как сделать так, чтобы Admission Controller был внедрен корректно и безопасно?
Ответы на эти вопросы можно найти в небольшой статье, доступной по ссылке. Автор выделяет 2 условные группы: защита webhook и корректная настройка кластера при использовании webhook.
Описаны такие контроли, как:
🍭 Настройка TLS между Admission и API Server
🍭 Обработка только аутентифицированных запросов
🍭 Максимально возможный контроль и ограничение запуска privileged-нагрузок
🍭 Использование отдельных webhook для каждого кластера (при использовании более 1)
🍭 Запрет запуска нагрузок в случае недоступности webhook (мера, которая подойдет далеко не всем, суть ее заключается в защите от обхода webhook) и т.д.
Если тема вам интересна, то можно ознакомиться с результатами моделирования угроз для Admission Controller, которое осуществляла SIG Security ☺️
Функционал Admission Controller очень значим, как минимум, для ИБ-специалистов. Он позволяет контролировать запуск только тех сущностей, которые соответствуют требованиям по ИБ компании и позволяет повысить общий уровень защищенности сред контейнерной оркестрации.
Но кто будет охранять охранников? И как сделать так, чтобы Admission Controller был внедрен корректно и безопасно?
Ответы на эти вопросы можно найти в небольшой статье, доступной по ссылке. Автор выделяет 2 условные группы: защита webhook и корректная настройка кластера при использовании webhook.
Описаны такие контроли, как:
🍭 Настройка TLS между Admission и API Server
🍭 Обработка только аутентифицированных запросов
🍭 Максимально возможный контроль и ограничение запуска privileged-нагрузок
🍭 Использование отдельных webhook для каждого кластера (при использовании более 1)
🍭 Запрет запуска нагрузок в случае недоступности webhook (мера, которая подойдет далеко не всем, суть ее заключается в защите от обхода webhook) и т.д.
Если тема вам интересна, то можно ознакомиться с результатами моделирования угроз для Admission Controller, которое осуществляла SIG Security ☺️
Kubernetes
Securing Admission Controllers
Author: Rory McCune (Aqua Security)
Admission control is a key part of Kubernetes security, alongside authentication and authorization. Webhook admission controllers are extensively used to help improve the security of Kubernetes clusters in a variety of…
Admission control is a key part of Kubernetes security, alongside authentication and authorization. Webhook admission controllers are extensively used to help improve the security of Kubernetes clusters in a variety of…
Всем привет!
Моделирование угроз в Kubernetes задачка не самая простая, но точно интересная!
В статье ребята рассуждает на тему того, что может пригодиться при ее решении:
🍭 Методика – в качестве нее авторы выбрали известный STRIDE
🍭 Средство автоматизации – Threat Modeler от Microsoft, MS TM (к которому ребята сделали template с «Kubernetes-тематикой»)
🍭 Пример – можно посмотреть наработки для KubeArmor. Примеры для KubeArmor и template для MS TM расположены в repo
В статье нет инструкций о том, как проводить моделирование угроз. В не содержатся справочная информация о том, какие практики можно использовать и какие средства автоматизации применять. С примером отчета, который генерируется упоминаемым в статье инструментом, можно ознакомиться по ссылке
Моделирование угроз в Kubernetes задачка не самая простая, но точно интересная!
В статье ребята рассуждает на тему того, что может пригодиться при ее решении:
🍭 Методика – в качестве нее авторы выбрали известный STRIDE
🍭 Средство автоматизации – Threat Modeler от Microsoft, MS TM (к которому ребята сделали template с «Kubernetes-тематикой»)
🍭 Пример – можно посмотреть наработки для KubeArmor. Примеры для KubeArmor и template для MS TM расположены в repo
В статье нет инструкций о том, как проводить моделирование угроз. В не содержатся справочная информация о том, какие практики можно использовать и какие средства автоматизации применять. С примером отчета, который генерируется упоминаемым в статье инструментом, можно ознакомиться по ссылке
Medium
Kubernetes Threat Modeling
Every security team has to deal with one question: “Are my services/deployments secure?”
Всем пятница!
Еще одна REGO-библиотека с правилами для анализа сущностей, запускаемых в среде контейнерной оркестрации.
Еще одна, да не совсем! Ребята из ARMO проделали отличную работу и сделали mapping проверок на MITRE ATT&CK. Практически по всем доменам доступны проверки:
🍭 Initial access
🍭 Execution
🍭 Persistence
🍭 Privilege Escalation
🍭 Defense Evasion
🍭 Credential Access
🍭 Discovery
🍭 Lateral Movement
🍭 Collection
🍭 Impact
Получился достаточно интересный материал ☺️
P.S. Желаем всем отличного вечера пятницы, теплых выходных и не болейте!
Еще одна REGO-библиотека с правилами для анализа сущностей, запускаемых в среде контейнерной оркестрации.
Еще одна, да не совсем! Ребята из ARMO проделали отличную работу и сделали mapping проверок на MITRE ATT&CK. Практически по всем доменам доступны проверки:
🍭 Initial access
🍭 Execution
🍭 Persistence
🍭 Privilege Escalation
🍭 Defense Evasion
🍭 Credential Access
🍭 Discovery
🍭 Lateral Movement
🍭 Collection
🍭 Impact
Получился достаточно интересный материал ☺️
P.S. Желаем всем отличного вечера пятницы, теплых выходных и не болейте!
GitHub
GitHub - kubescape/regolibrary: The regolibrary package contains the controls Kubescape uses for detecting misconfigurations in…
The regolibrary package contains the controls Kubescape uses for detecting misconfigurations in Kubernetes manifests. - kubescape/regolibrary
👍3
Всем привет!
По ссылке доступен базовый tutorial, описывающий установку ArgoCD и ключевые возможности этой системы.
Сперва рассматривается установка ArgoCD и создание первого “Application”: приводятся примеры manifest с кратким описанием наиболее важных параметров.
Далее на небольшом примере рассматриваются ключевые возможности ArgoCD:
🍭 Synchronize с GitHub (можно использовать не только GitHub, просто он приводится в самой статье)
🍭 Изменение manifest приложения, App Diff который покажет, что именно было изменено
🍭 Различные параметры настройки политики синхронизации ArgoCD (sync policy)
🍭 Механизмы History и Rollback
Все это с наглядными примерами, исходным кодом и screenshots итоговых результатов, которые должны получиться 😊
По ссылке доступен базовый tutorial, описывающий установку ArgoCD и ключевые возможности этой системы.
Сперва рассматривается установка ArgoCD и создание первого “Application”: приводятся примеры manifest с кратким описанием наиболее важных параметров.
Далее на небольшом примере рассматриваются ключевые возможности ArgoCD:
🍭 Synchronize с GitHub (можно использовать не только GitHub, просто он приводится в самой статье)
🍭 Изменение manifest приложения, App Diff который покажет, что именно было изменено
🍭 Различные параметры настройки политики синхронизации ArgoCD (sync policy)
🍭 Механизмы History и Rollback
Все это с наглядными примерами, исходным кодом и screenshots итоговых результатов, которые должны получиться 😊
Medium
Getting Started With ArgoCD on your Kubernetes Cluster
A step-by-step guide to set up ArgoCD on your Kubernetes cluster and synchronize your resources with your GitHub repository.
🔥1
Привет!
Одно из определений Observability заключается в измерении того, насколько хорошо работает система путем анализа ее (системы) выходных данных. Это подводит к нескольким вопросам: Какие именно данные надо собирать? При помощи чего это можно делать?
В статье автор размышляет на тему 3-х основных «столпов», которые можно и нужно исследовать: Metrics, Traces и Logs.
Для примера он использует Prometheus, который, de facto, является стандартом мониторинга сред контейнерной оркестрации.
В статье рассматриваются такие моменты как:
🍭 Общий взгляд на Prometheus и его компоненты, как установить (helm-чарты, операторы и т.д.)
🍭 Получение первичных данных (например, аналитика kube-state-metrics)
🍭 Сбор метрик с использованием Client и Exporters
🍭 Использование PromQL (Prometheus Query Language) для создание собственных запросов
В качестве «подопытного» для рассмотрения описанных выше концептов, используется небольшое приложение, состоящее из 3-х блоков: People Service («забирает» данные из MySQL базы данных), Format Service (обработка данных, полученных от People Service) и Hello Service (предоставление отформатированных данных пользователю).
На примере вышеописанного приложения демонстрируется, как можно собирать метрики из различных его компонент
Одно из определений Observability заключается в измерении того, насколько хорошо работает система путем анализа ее (системы) выходных данных. Это подводит к нескольким вопросам: Какие именно данные надо собирать? При помощи чего это можно делать?
В статье автор размышляет на тему 3-х основных «столпов», которые можно и нужно исследовать: Metrics, Traces и Logs.
Для примера он использует Prometheus, который, de facto, является стандартом мониторинга сред контейнерной оркестрации.
В статье рассматриваются такие моменты как:
🍭 Общий взгляд на Prometheus и его компоненты, как установить (helm-чарты, операторы и т.д.)
🍭 Получение первичных данных (например, аналитика kube-state-metrics)
🍭 Сбор метрик с использованием Client и Exporters
🍭 Использование PromQL (Prometheus Query Language) для создание собственных запросов
В качестве «подопытного» для рассмотрения описанных выше концептов, используется небольшое приложение, состоящее из 3-х блоков: People Service («забирает» данные из MySQL базы данных), Format Service (обработка данных, полученных от People Service) и Hello Service (предоставление отформатированных данных пользователю).
На примере вышеописанного приложения демонстрируется, как можно собирать метрики из различных его компонент
Medium
Hacking your way to Observability — Part 1
Have you ever seen someone trying to find how to solve an issue and a dozen people watching or suggesting to him/her what to look for as if they were trying to solve a mystery? . These situations…
👍2
Привет!
Подборка инструментов по анализу исходного кода (SAST), сгруппированная по языкам программирования.
В подборке есть:
🍭 Open Source инструменты
🍭 Enterprise-решения, отмеченные символом ©️
Перечень языков, для которых приведены инструменты анализа достаточно большой: С, С++, С#, DART, Go, Java, JavaScript, PHP, Python и многие другие.
Подборка может быть полезна в качестве «отправной точки» при выборе потенциального средства анализа исходного кода для конкретного языка. Судя по commit, repo периодически обновляется и поддерживается в около-актуальном состоянии.
Рекомендуем прочитать обозначения в repo. Они показывают Enterprise-версии (о чем писали выше); решения, НЕ рекомендованные community и решения, которые не обновлялись длительное время.
Подборка инструментов по анализу исходного кода (SAST), сгруппированная по языкам программирования.
В подборке есть:
🍭 Open Source инструменты
🍭 Enterprise-решения, отмеченные символом ©️
Перечень языков, для которых приведены инструменты анализа достаточно большой: С, С++, С#, DART, Go, Java, JavaScript, PHP, Python и многие другие.
Подборка может быть полезна в качестве «отправной точки» при выборе потенциального средства анализа исходного кода для конкретного языка. Судя по commit, repo периодически обновляется и поддерживается в около-актуальном состоянии.
Рекомендуем прочитать обозначения в repo. Они показывают Enterprise-версии (о чем писали выше); решения, НЕ рекомендованные community и решения, которые не обновлялись длительное время.
GitHub
GitHub - analysis-tools-dev/static-analysis: ⚙️ A curated list of static analysis (SAST) tools and linters for all programming…
⚙️ A curated list of static analysis (SAST) tools and linters for all programming languages, config files, build tools, and more. The focus is on tools which improve code quality. - analysis-tools-...
👍10