Привет!
В разговорах про DevSecOps очень часто упоминают культуру и необходимость вовлеченности (именно вовлеченности, а не «кнута») разработчиков в ИБ процессы для повышения защищенности Продукта.
Есть несколько подходов для того, чтобы заинтересовать кого-то в чем-либо. Один из них – понимание. Возможно, разработчики не знают, «что может пойти не так» или думают, что «это случается со всеми, только не со мной». С другой стороны, у ИБ-специалистов не всегда хватает времени/знаний/возможностей для того, чтобы повышать осведомленность.
Тут может помочь… геймификация! Очень удобный, простой и наглядный способ объяснить базовые концепты на простых примерах, наглядно и интерактивно!
Рекомендуем посмотреть на KONTRA, которая предлагает несколько free-уроков:
🍭 OWASP Top-10, Web (SQLi, Reflected XSS, User enumeration, Clickjacking и другие)
🍭 OWASP Top-10, API (Improper asset management, Broken user authentication, Insufficient logging and monitoring и другие)
Из альтернатив – Codebashing от Checkmarx (решение платное, но можно его «попробовать» бесплатно).
Да, уроков не супер много, но ими можно пользоваться, чтобы «на пальцах» объяснить проблематику и что необходимо делать, чтобы ее избежать ☺️
В разговорах про DevSecOps очень часто упоминают культуру и необходимость вовлеченности (именно вовлеченности, а не «кнута») разработчиков в ИБ процессы для повышения защищенности Продукта.
Есть несколько подходов для того, чтобы заинтересовать кого-то в чем-либо. Один из них – понимание. Возможно, разработчики не знают, «что может пойти не так» или думают, что «это случается со всеми, только не со мной». С другой стороны, у ИБ-специалистов не всегда хватает времени/знаний/возможностей для того, чтобы повышать осведомленность.
Тут может помочь… геймификация! Очень удобный, простой и наглядный способ объяснить базовые концепты на простых примерах, наглядно и интерактивно!
Рекомендуем посмотреть на KONTRA, которая предлагает несколько free-уроков:
🍭 OWASP Top-10, Web (SQLi, Reflected XSS, User enumeration, Clickjacking и другие)
🍭 OWASP Top-10, API (Improper asset management, Broken user authentication, Insufficient logging and monitoring и другие)
Из альтернатив – Codebashing от Checkmarx (решение платное, но можно его «попробовать» бесплатно).
Да, уроков не супер много, но ими можно пользоваться, чтобы «на пальцах» объяснить проблематику и что необходимо делать, чтобы ее избежать ☺️
Kontra
Application Security Training For Developers | Kontra
Kontra is an Application Security Training platform built for modern development teams.
Всем привет!
До чего же круто работать в IT, где так много талантливых людей, не лишенных иронии и способных с задором делать полезные вещи!
Понять потребность, придумать решение и продвинуть его - в этом и кроется суть разработки практически любого софта.
Так получилось и в этом случае!
С радостью делимся ярким примером раскрытия такой сути!
Команда разработчиков Imhotep сделала весьма полезную утилиту, не без иронии в названии - Popeye!
Утилита позиционируется как sanitizer (это не про COVID) Kubernetes-based кластеров и предназначена, как нетрудно догадаться для очистки от мусора.
Утилита может обнаружить и показать:
🍩 Проблемные ноды кластера, с ошибками Mem/Disk, PID, disk и т.д.
🍩 Неактивные namespace
🍩 Некорректные поды, аллоцирующие слишком много ресурсов, с образами без тегов, с непроцденными liveness probe и т.д.
🍩 Missconfig в deployment, serviceaccounts, daemonsets
🍩 Обнаружение и удаление неиспользуемых секретов
🍩 Неиспользуемые PVC
И многое другое!
Работает как on-prem, так и в облачных инсталляциях.
Помимо этого, утилита поддерживает работягу с отчетами, в том числе автоматическое сохранение в S3 в различных форматах.
А ещё может устанавливаться различными способами, включая запуск локального Docker контейнера и внутрикластерный deployment!
Отдельная мякотка: конфигурационный файл называется Spinach.YAML 🤣
Распространяется под лицензией Apache v2.
Добро пожаловать на GitHub разработчика👇
https://github.com/derailed/popeye
До чего же круто работать в IT, где так много талантливых людей, не лишенных иронии и способных с задором делать полезные вещи!
Понять потребность, придумать решение и продвинуть его - в этом и кроется суть разработки практически любого софта.
Так получилось и в этом случае!
С радостью делимся ярким примером раскрытия такой сути!
Команда разработчиков Imhotep сделала весьма полезную утилиту, не без иронии в названии - Popeye!
Утилита позиционируется как sanitizer (это не про COVID) Kubernetes-based кластеров и предназначена, как нетрудно догадаться для очистки от мусора.
Утилита может обнаружить и показать:
🍩 Проблемные ноды кластера, с ошибками Mem/Disk, PID, disk и т.д.
🍩 Неактивные namespace
🍩 Некорректные поды, аллоцирующие слишком много ресурсов, с образами без тегов, с непроцденными liveness probe и т.д.
🍩 Missconfig в deployment, serviceaccounts, daemonsets
🍩 Обнаружение и удаление неиспользуемых секретов
🍩 Неиспользуемые PVC
И многое другое!
Работает как on-prem, так и в облачных инсталляциях.
Помимо этого, утилита поддерживает работягу с отчетами, в том числе автоматическое сохранение в S3 в различных форматах.
А ещё может устанавливаться различными способами, включая запуск локального Docker контейнера и внутрикластерный deployment!
Отдельная мякотка: конфигурационный файл называется Spinach.YAML 🤣
Распространяется под лицензией Apache v2.
Добро пожаловать на GitHub разработчика👇
https://github.com/derailed/popeye
GitHub
GitHub - derailed/popeye: 👀 A Kubernetes cluster resource sanitizer
👀 A Kubernetes cluster resource sanitizer. Contribute to derailed/popeye development by creating an account on GitHub.
Всем привет!
Если вы любите и используете Semgrep (статический анализатор исходного кода, open source) и вам не хватало поддержки YAML…
То этот пост для вас! Поддержка реализована, правда пока в Alpha-режиме!
Попробовать можно по ссылке: https://semgrep.dev/s/Ppb3
Если вы любите и используете Semgrep (статический анализатор исходного кода, open source) и вам не хватало поддержки YAML…
То этот пост для вас! Поддержка реализована, правда пока в Alpha-режиме!
Попробовать можно по ссылке: https://semgrep.dev/s/Ppb3
Всем привет!
Ни для кого не секрет что наступившая декада в вопросах разработки приложений проходит под эгидой снижения «time-to-market” и максимальной автоматизации всего и вся. Что поделать - DevOps шагает семимильными шагами.
Разработка инфраструктурных решений под эти цели все больше смещается в сторону эфемерных облачных сред даже у нас, не говоря уже о западе.
За последние годы множество облавных провайдеров научились предлагать managed service под различные продукты , призванные упростить и ускорить развертывание инфраструктуры для приложений на базе готовых шаблонов.
Не остался в стороне и отечественный IT гигант - Яндекс. Со своим Yandex.Cloud, предлагающим множество готовых решений, в том числе Managed Service for Kubernetes, призванным облегчить подготовку инфраструктуры для разработки и поставки микросервисных приложений.
Мы же сейчас хотим поделиться полезным вебинаром от Яндекс на тему использования подобных инсталляций k8s as service.
На часовом вебинаре вы можете послушать о полезных нюансах использования облавного k8s:
🍩 что нужно знать при переезде в облако
🍩 какие нюансы в инфраструктуре и отличия от on-prem
🍩 как устроен managed service for Kubernetes
🍩 безопасность в облаке
И многое другое из первых рук разработчиков Яндекса...
Самое хорошее, что информация актуальна не столько для Яндекс.Облака, сколько концептуально для большинства подобных услуг облачных провайдеров!
Вебинар доступен по ссылке на портал Yandex.Cloud, где так же есть множество подобных материалов. Приятного просмотра! 👇
https://cloud.yandex.ru/events/302
Ни для кого не секрет что наступившая декада в вопросах разработки приложений проходит под эгидой снижения «time-to-market” и максимальной автоматизации всего и вся. Что поделать - DevOps шагает семимильными шагами.
Разработка инфраструктурных решений под эти цели все больше смещается в сторону эфемерных облачных сред даже у нас, не говоря уже о западе.
За последние годы множество облавных провайдеров научились предлагать managed service под различные продукты , призванные упростить и ускорить развертывание инфраструктуры для приложений на базе готовых шаблонов.
Не остался в стороне и отечественный IT гигант - Яндекс. Со своим Yandex.Cloud, предлагающим множество готовых решений, в том числе Managed Service for Kubernetes, призванным облегчить подготовку инфраструктуры для разработки и поставки микросервисных приложений.
Мы же сейчас хотим поделиться полезным вебинаром от Яндекс на тему использования подобных инсталляций k8s as service.
На часовом вебинаре вы можете послушать о полезных нюансах использования облавного k8s:
🍩 что нужно знать при переезде в облако
🍩 какие нюансы в инфраструктуре и отличия от on-prem
🍩 как устроен managed service for Kubernetes
🍩 безопасность в облаке
И многое другое из первых рук разработчиков Яндекса...
Самое хорошее, что информация актуальна не столько для Яндекс.Облака, сколько концептуально для большинства подобных услуг облачных провайдеров!
Вебинар доступен по ссылке на портал Yandex.Cloud, где так же есть множество подобных материалов. Приятного просмотра! 👇
https://cloud.yandex.ru/events/302
cloud.yandex.ru
Безопасность в инфраструктуре, основанной на Kubernetes®
На вебинаре обсудили набор практик, которые минимизируют риски простоя вашего production из-за человеческих ошибок.
Привет!
В инфраструктуре все должно быть прекрасно: и отказоустойчивость, и sizing, и код, и безопасность!
А чтобы это было проще контролировать, ребята анонсировали выход Checkov 2.0!
Немного об основных изменениях:
🍭 Graph based policies, которые позволяют построить «дерево сущностей» и делать к нему запросы для проверки гипотез
🍭 Анализ Dockerfile на соответствие лучшим практикам (COPY вместо ADD, наличие HealtCheck, 22 порт not exposed и т.д.). Согласно заверениям авторов – количество правил будет дополняться. Про лучшие практики написания Dockerfile можно почитать вот тут
🍭 По умолчанию добавлено около 250 новых политик проверки
Подробности можно прочесть по вышеуказанной ссылке. Кстати, там же есть ссылка на Slack-канал, где можно следить за последними новостями ☺️
В инфраструктуре все должно быть прекрасно: и отказоустойчивость, и sizing, и код, и безопасность!
А чтобы это было проще контролировать, ребята анонсировали выход Checkov 2.0!
Немного об основных изменениях:
🍭 Graph based policies, которые позволяют построить «дерево сущностей» и делать к нему запросы для проверки гипотез
🍭 Анализ Dockerfile на соответствие лучшим практикам (COPY вместо ADD, наличие HealtCheck, 22 порт not exposed и т.д.). Согласно заверениям авторов – количество правил будет дополняться. Про лучшие практики написания Dockerfile можно почитать вот тут
🍭 По умолчанию добавлено около 250 новых политик проверки
Подробности можно прочесть по вышеуказанной ссылке. Кстати, там же есть ссылка на Slack-канал, где можно следить за последними новостями ☺️
Bridgecrew
Checkov 2.0: Deeper, broader, and faster IaC scanning - Bridgecrew Blog
Introducing our biggest update to Checkov 2.0 yet including an all-new graph-based framework, 250 new policies, and Dockerfile support.
Привет!
Недавно мы писали про Lens – IDE для Kubernetes. Есть интересный проект от Aqua Security, в котором ребята решили добавить немного безопасности!
Это стало возможно из-за Lens Extensions API, анонсированного в ноябре 2020 года. Команда Aqua воспользовалась этой возможностью и сделала свой Lens extension для Starboard!
Пока что он умеет не очень много:
🍭 Отображать информацию о сканированиях Trivy
🍭 Информацию о результатах работы Kube-bench
🍭 Данные о результатах аудита конфигурации кластера
Для быстрого ознакомления можно посмотреть ролик, доступный в статье по ссылке на preview, в котором наглядно демонстрируются возможности (~ 12 минут).
Проект продолжает активно развиваться. Среди интересных моментов можно выделить «As the next step in our roadmap, we'd like the Lens extension to perform basic remediation actions». Посмотрим, что получится!
P.S. Про Lens вкратце можно почитать вот тут ☺️
Недавно мы писали про Lens – IDE для Kubernetes. Есть интересный проект от Aqua Security, в котором ребята решили добавить немного безопасности!
Это стало возможно из-за Lens Extensions API, анонсированного в ноябре 2020 года. Команда Aqua воспользовалась этой возможностью и сделала свой Lens extension для Starboard!
Пока что он умеет не очень много:
🍭 Отображать информацию о сканированиях Trivy
🍭 Информацию о результатах работы Kube-bench
🍭 Данные о результатах аудита конфигурации кластера
Для быстрого ознакомления можно посмотреть ролик, доступный в статье по ссылке на preview, в котором наглядно демонстрируются возможности (~ 12 минут).
Проект продолжает активно развиваться. Среди интересных моментов можно выделить «As the next step in our roadmap, we'd like the Lens extension to perform basic remediation actions». Посмотрим, что получится!
P.S. Про Lens вкратце можно почитать вот тут ☺️
Aquasec
Discover Security Risks with Starboard Extension for Lens Kubernetes IDE
Starboard creates security reports from various tools & vendors, displayed in Lens Kubernetes IDE, making security information easily accessible & actionable
Всем привет!
Обычно настройка CI/CD процессов начинается с установки CI-сервера, длительной настройки необходимых плагинов, описания всех сторонних связей и компонентов. И уже после всего этого написанию пайплайнов, длительному процессу отладки с ожиданием результата после каждого внесенного изменения в описываемый процесс. Но знали ли вы, что существует и альтернативный подход к разработке пайплайнов для CI/CD? Сегодня коснёмся темы локального запуска jenkinsfile и giltab-ci с выводом результатов непосредственно в консоль.
🍬 Первый инструмент - Jenkinsfile Runner, ознакомиться с проектом можно по ссылке.
Для использования потребуется jenkins.war и нужный набор плагинов. Зачем это нужно? Можно отлаживаться не используя сервер с вашими тестовыми и рабочими процессами, спокойно экспериментировать с фичами не затрагивая существующие процессы и не плодить множество dev-сущностей на "боевом" CI-сервере. Что не мало важно: поддерживаются запуск в контейнерах и конфигурация самого jenkins как "Configuration as a Code" через yaml файлы. На данный момент проект в стадии разработки и для желающих есть целое поле для исследований недокументированных фич и возможностей проекта.
🍬 Второй инструмент - glci, ознакомиться можно по ссылке.
Для использования требуется только установка самого инструмента. Логика простая: инструмент читает файлы проекта .env, .gitlab-сi.yml парсит содержимое и запускает пайплайны в локальном контейнере (ну или не в локальном, если вы хитро настроили переменную DOCKER_HOST). Результаты исполнения отображаются в локальной консоли.
Использование инструментов несколько меняет процесс разработки автоматизации, позволяет сконцентрироваться на написании кода пайплайна или его частей, прежде, чем коммитить любые изменения в дев\тест и даже продуктивные процессы. Попробуйте и возможно альтернативный подход к разработке CI/CD процессов вам понравится!
Обычно настройка CI/CD процессов начинается с установки CI-сервера, длительной настройки необходимых плагинов, описания всех сторонних связей и компонентов. И уже после всего этого написанию пайплайнов, длительному процессу отладки с ожиданием результата после каждого внесенного изменения в описываемый процесс. Но знали ли вы, что существует и альтернативный подход к разработке пайплайнов для CI/CD? Сегодня коснёмся темы локального запуска jenkinsfile и giltab-ci с выводом результатов непосредственно в консоль.
🍬 Первый инструмент - Jenkinsfile Runner, ознакомиться с проектом можно по ссылке.
Для использования потребуется jenkins.war и нужный набор плагинов. Зачем это нужно? Можно отлаживаться не используя сервер с вашими тестовыми и рабочими процессами, спокойно экспериментировать с фичами не затрагивая существующие процессы и не плодить множество dev-сущностей на "боевом" CI-сервере. Что не мало важно: поддерживаются запуск в контейнерах и конфигурация самого jenkins как "Configuration as a Code" через yaml файлы. На данный момент проект в стадии разработки и для желающих есть целое поле для исследований недокументированных фич и возможностей проекта.
🍬 Второй инструмент - glci, ознакомиться можно по ссылке.
Для использования требуется только установка самого инструмента. Логика простая: инструмент читает файлы проекта .env, .gitlab-сi.yml парсит содержимое и запускает пайплайны в локальном контейнере (ну или не в локальном, если вы хитро настроили переменную DOCKER_HOST). Результаты исполнения отображаются в локальной консоли.
Использование инструментов несколько меняет процесс разработки автоматизации, позволяет сконцентрироваться на написании кода пайплайна или его частей, прежде, чем коммитить любые изменения в дев\тест и даже продуктивные процессы. Попробуйте и возможно альтернативный подход к разработке CI/CD процессов вам понравится!
GitHub
GitHub - jenkinsci/jenkinsfile-runner: A command line tool to run Jenkinsfile as a function
A command line tool to run Jenkinsfile as a function - jenkinsci/jenkinsfile-runner
Всем привет!
25 апреля, в 20:00 по Московскому времени (1 pm, ET) состоится двухчасовой workshop на тему Semgrep!
Что будет рассмотрено?
🍭 Как быстро настроить интеграцию с CI
🍭 На что обращать внимание для формирования непрерывного сканирования кода
🍭 Как использовать сканеры для проверки выполнения требований ИБ
🍭 Чем может помочь Semgrep, как его использовать
На workshop будет разобрано большое количество практических задач, приведены реальные примеры.
Все, что нужно – зарегистрироваться, найти время и создать (если у вас его нет) GitHub account!
Надеемся, что вам понравится!
25 апреля, в 20:00 по Московскому времени (1 pm, ET) состоится двухчасовой workshop на тему Semgrep!
Что будет рассмотрено?
🍭 Как быстро настроить интеграцию с CI
🍭 На что обращать внимание для формирования непрерывного сканирования кода
🍭 Как использовать сканеры для проверки выполнения требований ИБ
🍭 Чем может помочь Semgrep, как его использовать
На workshop будет разобрано большое количество практических задач, приведены реальные примеры.
Все, что нужно – зарегистрироваться, найти время и создать (если у вас его нет) GitHub account!
Надеемся, что вам понравится!
Meetup
Login to Meetup | Meetup
Find groups that host online or in person events and meet people in your local community who share your interests.
Привет!
В апреле 2020 года был представлен первый вариант Threat Matrix for Kubernetes.
Прошел год, исследования продолжаются, k8s меняется, появляются новые тактики и техники, а некоторые, ранее определенные, становятся менее актуальными.
В связи с этим команда представила обновленный Threat Matrix for Kubernetes!
➕ Что было добавлено:
🍭 Image from a private registry
🍭 Malicious admission controller
🍭 Access managed identity credential
🍭 Exposed sensitive interfaces
🍭 Sidecar injection
🍭 CoreDNS poisoning
🍭 ARP poisoning and IP spoofing
➖ Что стало deprecated:
🍭 Exposed dashboard
🍭 Access Kubernetes dashboard
🍭 Access tiller endpoint
С подробностями можно ознакомиться в блоге Microsoft!
В апреле 2020 года был представлен первый вариант Threat Matrix for Kubernetes.
Прошел год, исследования продолжаются, k8s меняется, появляются новые тактики и техники, а некоторые, ранее определенные, становятся менее актуальными.
В связи с этим команда представила обновленный Threat Matrix for Kubernetes!
➕ Что было добавлено:
🍭 Image from a private registry
🍭 Malicious admission controller
🍭 Access managed identity credential
🍭 Exposed sensitive interfaces
🍭 Sidecar injection
🍭 CoreDNS poisoning
🍭 ARP poisoning and IP spoofing
➖ Что стало deprecated:
🍭 Exposed dashboard
🍭 Access Kubernetes dashboard
🍭 Access tiller endpoint
С подробностями можно ознакомиться в блоге Microsoft!
Microsoft News
Secure containerized environments with updated threat matrix for Kubernetes
The updated threat matrix for Kubernetes adds new techniques found by Microsoft researchers, as well as techniques that were suggested by the community.
Привет!
Как часто вы это слышали: «Сложно, все непонятно, можно как-нибудь попроще, да за 5 минут!». Возможно, что ребята из SNYK тоже это слышали и решили… Сделать просто, понятно и за 5 минут!
По ссылке доступен короткий ролик, который (помимо отличной музыки в начале!) очень доступно объясняет:
🍭 Что плохого может случиться, если container running as root?
🍭 Варианты митигации: ограничение host path mount, OPA rules, runtime protection или использование securityContext?
🍭 Чем runAsNonRoot отличается от комбинации runAsUser/runAsGroup?
🍭 Почему лучше использовать uid, а не имя в директиве USER Dockerfile’a?
🍭 Как использовать SNYK IaC для идентификации трудностей (да, не обошлось без рекламы, но инструментом можно воспользоваться for free)?
Помимо этого, в ссылках под видео можно найти cheatsheet для k8s, а ребята обещают продолжать снимать подобные ролики «Просто и понятно!»
Как часто вы это слышали: «Сложно, все непонятно, можно как-нибудь попроще, да за 5 минут!». Возможно, что ребята из SNYK тоже это слышали и решили… Сделать просто, понятно и за 5 минут!
По ссылке доступен короткий ролик, который (помимо отличной музыки в начале!) очень доступно объясняет:
🍭 Что плохого может случиться, если container running as root?
🍭 Варианты митигации: ограничение host path mount, OPA rules, runtime protection или использование securityContext?
🍭 Чем runAsNonRoot отличается от комбинации runAsUser/runAsGroup?
🍭 Почему лучше использовать uid, а не имя в директиве USER Dockerfile’a?
🍭 Как использовать SNYK IaC для идентификации трудностей (да, не обошлось без рекламы, но инструментом можно воспользоваться for free)?
Помимо этого, в ссылках под видео можно найти cheatsheet для k8s, а ребята обещают продолжать снимать подобные ролики «Просто и понятно!»
YouTube
Kubernetes Quick Hits: SecurityContext and why not to run as root
In this, the first of our series of our Kubernetes Quick Hits videos, Eric Smalling–Sr. Developer Advocate at Synk–runs through topics 1 and 2 from our recently published cheatsheet, 10 Kubernetes Security Context settings you should understand: https://snyk.io/blog/10…
Привет!
В репозитории доступен набор базовых сетевых политик, которые можно использовать при освоении инструмента Network Policy, например:
🍭 DENY all traffic to an application
🍭 LIMIT traffic to an application
🍭 ALLOW all traffic to an application
🍭 ALLOW all traffic from a namespace
🍭 ALLOW traffic from some pods in another namespace
🍭 DENY all non-whitelisted egress traffic in a namespace и другие
Удобно, что автор не только предоставляет политики, но и наглядно объясняет как и что работает, приводит примеры ДО и ПОСЛЕ применения политик.
Для экспериментов удобно использовать инструмент от Cilium, который позволяет создавать Network Policy в «графическом редакторе» (о нем мы писали ранее)
P.S. Надеемся, что найдутся те, кто будет поддерживать и развивать этот repo!
В репозитории доступен набор базовых сетевых политик, которые можно использовать при освоении инструмента Network Policy, например:
🍭 DENY all traffic to an application
🍭 LIMIT traffic to an application
🍭 ALLOW all traffic to an application
🍭 ALLOW all traffic from a namespace
🍭 ALLOW traffic from some pods in another namespace
🍭 DENY all non-whitelisted egress traffic in a namespace и другие
Удобно, что автор не только предоставляет политики, но и наглядно объясняет как и что работает, приводит примеры ДО и ПОСЛЕ применения политик.
Для экспериментов удобно использовать инструмент от Cilium, который позволяет создавать Network Policy в «графическом редакторе» (о нем мы писали ранее)
P.S. Надеемся, что найдутся те, кто будет поддерживать и развивать этот repo!
GitHub
GitHub - ahmetb/kubernetes-network-policy-recipes: Example recipes for Kubernetes Network Policies that you can just copy paste
Example recipes for Kubernetes Network Policies that you can just copy paste - ahmetb/kubernetes-network-policy-recipes
Привет!
В продолжении темы с Network Policy, есть tutorial в котором отлично объясняется что это такое и как это реализовать!
После небольшой вводной части (Pod, Service, Ingress, Egress, Network Policy и т.д.) будет приведена демонстрация, в которой:
🍭 Создается demo-приложение, состоящее из front и back end
🍭 Создаются и применяются политики «ingress deny by default» для backend – ограничение трафика к backend
🍭Создаются и применяются политики «backend ingress allow frontend» - разрешение трафика к backend со стороны frontend
🍭 Создаются и применяются политики «pods allow everything in a namespace» - разрешение трафика внутри namespace, но не за его пределами
🍭 Создаются и применяются политики «backend ingress allow monitoring namespace» - разрешение трафика из другого namespace от определенного pod
🍭 Создаются и применяются схожие политики, но только для Egress
Все показано с примерами кода, с применением/отменой политик, объяснением "почему это работает так", а также с важными аспектами, на которые стоит обратить внимание (например, что такое Stateful Policy Enforcement).
Tutorial продолжает развиваться, в планах выпустить:
🍭 Part 2: Securing access in and out of your cluster
🍭 Part 3; Special cases: Host-networking, Loadbalancers, Health-checking
🍭 Part 4: How to troubleshoot NetworkPolicy and monitor Compliance
P.S. В самой repo можно найти все необходимые файлы для самостоятельного повтора демонстраций
В продолжении темы с Network Policy, есть tutorial в котором отлично объясняется что это такое и как это реализовать!
После небольшой вводной части (Pod, Service, Ingress, Egress, Network Policy и т.д.) будет приведена демонстрация, в которой:
🍭 Создается demo-приложение, состоящее из front и back end
🍭 Создаются и применяются политики «ingress deny by default» для backend – ограничение трафика к backend
🍭Создаются и применяются политики «backend ingress allow frontend» - разрешение трафика к backend со стороны frontend
🍭 Создаются и применяются политики «pods allow everything in a namespace» - разрешение трафика внутри namespace, но не за его пределами
🍭 Создаются и применяются политики «backend ingress allow monitoring namespace» - разрешение трафика из другого namespace от определенного pod
🍭 Создаются и применяются схожие политики, но только для Egress
Все показано с примерами кода, с применением/отменой политик, объяснением "почему это работает так", а также с важными аспектами, на которые стоит обратить внимание (например, что такое Stateful Policy Enforcement).
Tutorial продолжает развиваться, в планах выпустить:
🍭 Part 2: Securing access in and out of your cluster
🍭 Part 3; Special cases: Host-networking, Loadbalancers, Health-checking
🍭 Part 4: How to troubleshoot NetworkPolicy and monitor Compliance
P.S. В самой repo можно найти все необходимые файлы для самостоятельного повтора демонстраций
GitHub
GitHub - networkpolicy/tutorial: Kubernetes Network Policy Tutorial
Kubernetes Network Policy Tutorial. Contribute to networkpolicy/tutorial development by creating an account on GitHub.
Всем привет!
Мы здесь на канале много говорим про оркестраторы, технологии защиты контейнеров и многие полезные штуки для их работы. Но сегодня мы хотели бы затронуть другой не маловажный аспект: эффективность самих образов контейнеров.
Без лишних слов, встречайте: dive
Простая, но в то же время мощнейшая утилита для анализа эффективности слоёв контейнеров и общей эффективности работы с вашими Dockerfile. Проекту почти 4 года и он достаточно активно развивается как автором, так и сообществом. Умеет из коробки следующее:
🍬 Отображать изменения в каждом слое образа
🍬 Отображать содержимое фс контейнера для каждого слоя
🍬 Рассчитывать потенциальные потери места на фс контейнера
🍬 Отображать файлы с пересекающимися изменениями между слоями
🍬 Считать общую эффективность по размеру образа
Утилита умеет работать не только с docker, но и с podman (libpod), запускаться как консольная команда, работать из контейнера и встраиваться в CI процессы. Добавим ко всему этому возможность с помощью yaml файлов настроить по желанию интерфейс и даже собрать образ контейнера "на лёту" с последующим анализом - получается уникальная программа раскрывающая весь потенциал docker inspect по максимуму.
Мы здесь на канале много говорим про оркестраторы, технологии защиты контейнеров и многие полезные штуки для их работы. Но сегодня мы хотели бы затронуть другой не маловажный аспект: эффективность самих образов контейнеров.
Без лишних слов, встречайте: dive
Простая, но в то же время мощнейшая утилита для анализа эффективности слоёв контейнеров и общей эффективности работы с вашими Dockerfile. Проекту почти 4 года и он достаточно активно развивается как автором, так и сообществом. Умеет из коробки следующее:
🍬 Отображать изменения в каждом слое образа
🍬 Отображать содержимое фс контейнера для каждого слоя
🍬 Рассчитывать потенциальные потери места на фс контейнера
🍬 Отображать файлы с пересекающимися изменениями между слоями
🍬 Считать общую эффективность по размеру образа
Утилита умеет работать не только с docker, но и с podman (libpod), запускаться как консольная команда, работать из контейнера и встраиваться в CI процессы. Добавим ко всему этому возможность с помощью yaml файлов настроить по желанию интерфейс и даже собрать образ контейнера "на лёту" с последующим анализом - получается уникальная программа раскрывающая весь потенциал docker inspect по максимуму.
GitHub
GitHub - wagoodman/dive: A tool for exploring each layer in a docker image
A tool for exploring each layer in a docker image. Contribute to wagoodman/dive development by creating an account on GitHub.
Привет!
r2c подготовили небольшой курс «Intro to Semgrep», в котором любой желающий может ознакомиться с написанием правил и интеграцией в CI. В качестве «подопытного» выбран небезызвестный Juice Shop.
Курс состоит из 4-х частей:
🍭 Getting Set Up – подготовительные работы для запуска Semgrep, интеграция с Slack
🍭 Add Semgrep to CI via GitHub Action – добавление инструмента в CI, первые проверки
🍭 Writing Our First Rule – основы написания правил, добавление в проект своего правила
🍭 Auditing Routes – использование инструмента в notify only mode - еще несколько упражнений по написанию проверок, чуть более сложных, чем на предыдущем этапе
Курс простой, может быть использован для знакомства с Semgrep. Все, что необходимо иметь - собственный account на GitHub. И все! Можно приступать!
P.S. В курсе все объясняется, с небольшими примерами, приведено множество ссылок на полезные материалы (преимущественное документация Semgrep, но это все же чуть проще, чем "погружаться с 0")
r2c подготовили небольшой курс «Intro to Semgrep», в котором любой желающий может ознакомиться с написанием правил и интеграцией в CI. В качестве «подопытного» выбран небезызвестный Juice Shop.
Курс состоит из 4-х частей:
🍭 Getting Set Up – подготовительные работы для запуска Semgrep, интеграция с Slack
🍭 Add Semgrep to CI via GitHub Action – добавление инструмента в CI, первые проверки
🍭 Writing Our First Rule – основы написания правил, добавление в проект своего правила
🍭 Auditing Routes – использование инструмента в notify only mode - еще несколько упражнений по написанию проверок, чуть более сложных, чем на предыдущем этапе
Курс простой, может быть использован для знакомства с Semgrep. Все, что необходимо иметь - собственный account на GitHub. И все! Можно приступать!
P.S. В курсе все объясняется, с небольшими примерами, приведено множество ссылок на полезные материалы (преимущественное документация Semgrep, но это все же чуть проще, чем "погружаться с 0")
Привет!
И сноваседая ночь про безопасность Dockerfile! «Сколько можно, да про это уже все написали, да что там нового!» - можете подумать вы.
В целом – согласны, но есть нюанс. В интернете много статей, которые отлично описывают теорию. Есть статьи, где разбирается использование инструментов для проверки образов… А в этой статье собрано все: теория, практика, примеры (как надо и как НЕ надо), инструменты и их базовое использование.
В первой части «Best practices to write Dockerfiles» описываются лучшие практики ИБ при написании Dockerfile (из официальной документации, опыта community).
Далее автор разбирает инструменты-помощники:
🍭 BuildKit: пример инъекции секретов, SSH-взаимодействия
🍭 Hadolint
🍭 Dockle: с небольшим сравнением альтернативных решений
🍭 DockerSlim: включая AppArmor и SecComp
🍭 dive (о котором мы писали ранее)
🍭 Возможности интеграции плагинов в IDE
🍭 OPA и Conftest: написание проверок анализа конфигурации Dockerfile
Ссылки на все вышеупомянутое можно найти в статье. Материал хорош тем, что теперь не надо хранить 10 вкладок в «Избранном», можно добавить только одну ☺️
И снова
В целом – согласны, но есть нюанс. В интернете много статей, которые отлично описывают теорию. Есть статьи, где разбирается использование инструментов для проверки образов… А в этой статье собрано все: теория, практика, примеры (как надо и как НЕ надо), инструменты и их базовое использование.
В первой части «Best practices to write Dockerfiles» описываются лучшие практики ИБ при написании Dockerfile (из официальной документации, опыта community).
Далее автор разбирает инструменты-помощники:
🍭 BuildKit: пример инъекции секретов, SSH-взаимодействия
🍭 Hadolint
🍭 Dockle: с небольшим сравнением альтернативных решений
🍭 DockerSlim: включая AppArmor и SecComp
🍭 dive (о котором мы писали ранее)
🍭 Возможности интеграции плагинов в IDE
🍭 OPA и Conftest: написание проверок анализа конфигурации Dockerfile
Ссылки на все вышеупомянутое можно найти в статье. Материал хорош тем, что теперь не надо хранить 10 вкладок в «Избранном», можно добавить только одну ☺️
Medium
A practical guide to writing secure Dockerfiles
Tools, techniques, and procedures to write secure Dockerfiles
Всем привет!
В нашем канале мы много говорили про безопасность контейнеров и систем оркестрации, про образы и их качество, про процессы, DevOps, делились best practices и много чего ещё.
Но одну тему мы поднимаем не так часто, и виной тому не лень или скукота темы, а скорее то что в отечественном enterprise сегменте эта тема до сих пор не так востребована и распространена как в остальном мире!
Догадываетесь о чем речь? 😊
«Да как тут угадать?» скажете вы, и будете правы, слишком уж неоднозначная подводка получилась.
Ну не будем томить, сегодня будет длинный пост и речь в нем пойдет про безопасность облаков или Cloud Security Posture!
Не секрет, что облачные провайдеры за последнюю декаду развернулись во всей красе. Сегодня нам доступны как готовые шаблоны виртуальных машин для домашнего использования, так и огромные мощности для SaaS, PaaS, IaaS и прочих -aaS.
Все это расположено в монументальных датацентрах по всей планете и поставляется нам с различными уровнями поддержки и ответственности поставщика.
Но чем больше и эфемерней становится инфраструктура, тем сложнее в ней обеспечить безопасность и уследить за всеми событиями.
Ведь одно дело, если мы создали две виртуальные машины, включили и настроили аудит событий, настроили правила фильтрации сетевого трафика и организовали контроль runtime активностей.
И совсем другое дело, когда огромная инфраструктура с виртуальными хостами, гипервизорами, оркестраторами, контейнерами, базами данных и кучей вспомогательных виртуальных сервисов размазаны по датацентрам на разных континентах, и все это находится на разных уровнях абстракции и доступно при этом толпе пользователей с различными уровнями доступа!
Пласт сложностей настолько огромен, что никаким внедрением навесного средства защиты здесь не справиться!
🍩 Что же делать?!
Для начала «разложить слона на части!»
Определить цели, задачи, риски и угрозы, сгруппировать и осмыслить собственные сервисы и их взаимодействия и после этого приступить в «поеданию слона»!
И вот тут мы рады поделимся методическим материалом!
Компания Palo Alto выпустила руководство для чайников по организации облачной безопасности: Cloud Security and Compliane for dummies
В книге достаточно понятно описываются такие вопросы как например:
🍩 Типы облаков и их различия
🍩 Какие угрозы в них бывают
🍩 Лучшие практики
🍩 Упраление рисками
🍩 Огранизация безопасности как процесса
И многое другое!
⚠️ Нужно заметить что методики и рекомендации не привязаны к вендорам или тулзам и ставят целью помочь разобраться в темном лесу Cloud security и понять какие первые шаги предпринять.
Так как документ ограниченного характера, распространять его в открытом виде не представляется возможным, однако после быстрой , ни к чему не обязывающей регистрации на портале, книга становится доступна любому желающему.
Ссылка ниже, уверяем, вы найдёте что-то полезное для себя! 👇
https://www.paloaltonetworks.com/resources/ebooks/cloud-security-compliance-for-dummies
В нашем канале мы много говорили про безопасность контейнеров и систем оркестрации, про образы и их качество, про процессы, DevOps, делились best practices и много чего ещё.
Но одну тему мы поднимаем не так часто, и виной тому не лень или скукота темы, а скорее то что в отечественном enterprise сегменте эта тема до сих пор не так востребована и распространена как в остальном мире!
Догадываетесь о чем речь? 😊
«Да как тут угадать?» скажете вы, и будете правы, слишком уж неоднозначная подводка получилась.
Ну не будем томить, сегодня будет длинный пост и речь в нем пойдет про безопасность облаков или Cloud Security Posture!
Не секрет, что облачные провайдеры за последнюю декаду развернулись во всей красе. Сегодня нам доступны как готовые шаблоны виртуальных машин для домашнего использования, так и огромные мощности для SaaS, PaaS, IaaS и прочих -aaS.
Все это расположено в монументальных датацентрах по всей планете и поставляется нам с различными уровнями поддержки и ответственности поставщика.
Но чем больше и эфемерней становится инфраструктура, тем сложнее в ней обеспечить безопасность и уследить за всеми событиями.
Ведь одно дело, если мы создали две виртуальные машины, включили и настроили аудит событий, настроили правила фильтрации сетевого трафика и организовали контроль runtime активностей.
И совсем другое дело, когда огромная инфраструктура с виртуальными хостами, гипервизорами, оркестраторами, контейнерами, базами данных и кучей вспомогательных виртуальных сервисов размазаны по датацентрам на разных континентах, и все это находится на разных уровнях абстракции и доступно при этом толпе пользователей с различными уровнями доступа!
Пласт сложностей настолько огромен, что никаким внедрением навесного средства защиты здесь не справиться!
🍩 Что же делать?!
Для начала «разложить слона на части!»
Определить цели, задачи, риски и угрозы, сгруппировать и осмыслить собственные сервисы и их взаимодействия и после этого приступить в «поеданию слона»!
И вот тут мы рады поделимся методическим материалом!
Компания Palo Alto выпустила руководство для чайников по организации облачной безопасности: Cloud Security and Compliane for dummies
В книге достаточно понятно описываются такие вопросы как например:
🍩 Типы облаков и их различия
🍩 Какие угрозы в них бывают
🍩 Лучшие практики
🍩 Упраление рисками
🍩 Огранизация безопасности как процесса
И многое другое!
⚠️ Нужно заметить что методики и рекомендации не привязаны к вендорам или тулзам и ставят целью помочь разобраться в темном лесу Cloud security и понять какие первые шаги предпринять.
Так как документ ограниченного характера, распространять его в открытом виде не представляется возможным, однако после быстрой , ни к чему не обязывающей регистрации на портале, книга становится доступна любому желающему.
Ссылка ниже, уверяем, вы найдёте что-то полезное для себя! 👇
https://www.paloaltonetworks.com/resources/ebooks/cloud-security-compliance-for-dummies
Palo Alto Networks
Cloud Security and Compliance for Dummies Guide
Evaluate your cloud security and compliance options. Read the pivotal step-by-step guide on how to secure your cloud, now and in the future.
Всем привет!
Можно долго ругать (или хвалить) Dependency-Check, но сегодня не об этом ☺️ В статье приведен интересный пример того, как можно визуализировать информацию о зависимостях и сделать аналитику более интерактивной для восприятия!
🍭 Потребуется Neo4J база данных, установленный Dependency-Check
🍭 Сканируем исходный код, получаем данные, загружаем в БД
🍭 …
🍭 Visualize it! При помощи разных запросов
Примеры реализации и запросов, а также ссылка на repo проекта доступна в статье.
P.S. Поздравляем вас с наступающими праздниками, желаем отлично отдохнуть и набраться сил!!! ☺️☺️☺️
Можно долго ругать (или хвалить) Dependency-Check, но сегодня не об этом ☺️ В статье приведен интересный пример того, как можно визуализировать информацию о зависимостях и сделать аналитику более интерактивной для восприятия!
🍭 Потребуется Neo4J база данных, установленный Dependency-Check
🍭 Сканируем исходный код, получаем данные, загружаем в БД
🍭 …
🍭 Visualize it! При помощи разных запросов
Примеры реализации и запросов, а также ссылка на repo проекта доступна в статье.
P.S. Поздравляем вас с наступающими праздниками, желаем отлично отдохнуть и набраться сил!!! ☺️☺️☺️
Medium
How to create a Software Bill of Materials in Neo4J
Graph databases are very useful when we try to represent data in a friendly visual way. One of the best use cases i can think of for a…
Привет!
По ссылке доступен repo, который поможет познакомиться с OPA Gatekeeper и Kyverno. Помимо теории доступны небольшие примеры, которые можно воссоздать, используя Minikube.
Материал кратко раскрывает такие темы, как:
🍭 Что такое OPA и OPA Gatekeeper
🍭 Что такое Kyverno
🍭 Верхнеуровневое сравнение OPA Gatekeeper и Kyverno
🍭 Создание отдельных Minikube инсталляций, установка решений
🍭 Создание простых политик (контроль наличия label) с OPA Gatekeeper и Kyverno
Код всех примеров можно найти в самом repo. Кроме того, в материалах можно найти много полезных ссылок, которые могут быть интересны для ознакомления
По ссылке доступен repo, который поможет познакомиться с OPA Gatekeeper и Kyverno. Помимо теории доступны небольшие примеры, которые можно воссоздать, используя Minikube.
Материал кратко раскрывает такие темы, как:
🍭 Что такое OPA и OPA Gatekeeper
🍭 Что такое Kyverno
🍭 Верхнеуровневое сравнение OPA Gatekeeper и Kyverno
🍭 Создание отдельных Minikube инсталляций, установка решений
🍭 Создание простых политик (контроль наличия label) с OPA Gatekeeper и Kyverno
Код всех примеров можно найти в самом repo. Кроме того, в материалах можно найти много полезных ссылок, которые могут быть интересны для ознакомления
GitHub
GitHub - developer-guy/policy-as-code-war: OPA Gatekeeper vs Kyverno
OPA Gatekeeper vs Kyverno. Contribute to developer-guy/policy-as-code-war development by creating an account on GitHub.
Привет!
По ссылке доступна статья, в которой описывается возможная атака на Vanilla Kubernetes.
Автор предлагает следующее:
🍭 Поиск публично доступных kubelet API
🍭 Использование kubelet API для реализации RCE
🍭 Запуск shell в контейнере, запущенном на node
🍭 Идентификация credentials, получение доступа к API-серверу с cluster-admin привилегиями
🍭 Запуск привилегированного контейнера с последующим escape на node
Некоторые из этапов атаки можно реализовать из-за default настроек, которые могут быть (или уже) «отключены», например, анонимная аутентификация к kubelet при установке через kubeadm. Альтернативный пример – Tiller и Helm v2 (который был deprecated в ноября 2020), но все равно есть те, кто его использует. Поэтому на наш взгляд статья неплохо подойдет в качестве обучающего материала.
Статья подробная, с примерами и ссылками на интересные материалы.
P.S. В статье есть этап поиска публично доступных API с использованием Shodan. Напоминаем, что подобные упражнения (даже с благими целями) могут привести к ответственности, вплоть до уголовной. Поэтому крайне рекомендуем начинать с Minikube-части, тем самым эмулируя ситуацию, когда «мы уже нашли интересующий нас API»
По ссылке доступна статья, в которой описывается возможная атака на Vanilla Kubernetes.
Автор предлагает следующее:
🍭 Поиск публично доступных kubelet API
🍭 Использование kubelet API для реализации RCE
🍭 Запуск shell в контейнере, запущенном на node
🍭 Идентификация credentials, получение доступа к API-серверу с cluster-admin привилегиями
🍭 Запуск привилегированного контейнера с последующим escape на node
Некоторые из этапов атаки можно реализовать из-за default настроек, которые могут быть (или уже) «отключены», например, анонимная аутентификация к kubelet при установке через kubeadm. Альтернативный пример – Tiller и Helm v2 (который был deprecated в ноября 2020), но все равно есть те, кто его использует. Поэтому на наш взгляд статья неплохо подойдет в качестве обучающего материала.
Статья подробная, с примерами и ссылками на интересные материалы.
P.S. В статье есть этап поиска публично доступных API с использованием Shodan. Напоминаем, что подобные упражнения (даже с благими целями) могут привести к ответственности, вплоть до уголовной. Поэтому крайне рекомендуем начинать с Minikube-части, тем самым эмулируя ситуацию, когда «мы уже нашли интересующий нас API»
Medium
Attacking Kubernetes clusters using the Kubelet API
Knock-knockin’ on kubelet’s door. From the doormat to full node access.
Всем привет!
В начале года SNYK запустил серию опросов для подготовки отчета о состоянии ИБ в Cloud Native. В символичную дату, 4 мая (Да прибудет с Вами Сила!) ребята сделали отчет «State of Cloud Native Application Security» доступным и интерактивным!
Некоторые findings:
🍭 99% респондентов считают обеспечение ИБ значимым аспектом их Cloud Native стратегии
🍭 78% workloads представляют из себя контейнеры и serverless
🍭 50% опрошенных практикуют Infrastructure as Code
🍭 56% - были проблемы ИБ, связанные с misconfiguration
🍭 60% - повышение озабоченности об ИБ при переходе в Cloud Native
🍭 72% команд устраняют критичные недостатки за 1 неделю (рассматриваются команды, обладающие значительной автоматизации процессов)
Остальную информацию, выводы и инфографику можно посмотреть в самом отчете ☺️
В начале года SNYK запустил серию опросов для подготовки отчета о состоянии ИБ в Cloud Native. В символичную дату, 4 мая (Да прибудет с Вами Сила!) ребята сделали отчет «State of Cloud Native Application Security» доступным и интерактивным!
Некоторые findings:
🍭 99% респондентов считают обеспечение ИБ значимым аспектом их Cloud Native стратегии
🍭 78% workloads представляют из себя контейнеры и serverless
🍭 50% опрошенных практикуют Infrastructure as Code
🍭 56% - были проблемы ИБ, связанные с misconfiguration
🍭 60% - повышение озабоченности об ИБ при переходе в Cloud Native
🍭 72% команд устраняют критичные недостатки за 1 неделю (рассматриваются команды, обладающие значительной автоматизации процессов)
Остальную информацию, выводы и инфографику можно посмотреть в самом отчете ☺️
Snyk
Cloud Native Application Security Report | Snyk
New research reveals 60% of organizations have increased security concerns since adopting cloud native. Read the full State of Cloud Native Application Security report for all of the latest trends.