Привет!
Недавно мы писали про 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.
import this
- при помощи такой команды можно увидеть «Zen of Python» и на наш взгляд она отлично подходит для описания того, что приведено в статье «Nine Pillars of DevOps Best Practices».
Автор собрал общие практики, про которые важно помнить при развитии DevSecOps и "разбил" их по нескольким категориям
🍭 Leadership Practices for DevOps
Тезисы о том, на что обращать внимание при работе с командой
🍭 Collaborative Culture Practices for DevOps
Тезисы о развитии взаимодействия, обмена опытом и эффективности
🍭 Design-for-DevOps Practices for DevOps
Тезисы об «облике» программного обеспечения
🍭 Continuous Integration Practices for DevOps
Тезисы о сборке программного обеспечения
🍭 Continuous Testing Practices for DevOps
Тезисы о тестах и их использовании
🍭 Elastic Infrastructure Practices for DevOps
Тезисы о создании масштабируемого и поддерживаемого контура разработки
🍭 Continuous Monitoring Practices for DevOps
Тезисы про мониторинг, его автоматизацию
🍭 Continuous Security Practices for DevOps
Тезисы про обеспечения ИБ, ответственность сторон и автоматизацию
🍭 Continuous Delivery Practices for DevOps
Тезисы про оптимизацию и корректное выстраивание процесса deployment
На первый взгляд может показаться, что «это общие слова ни о чем». Но если читать вдумчиво, то из этого может получиться неплохой инструмент оценки того, что реализовано, что можно и нужно реализовать, что важно не забыть. Надеемся, что статья будет вам полезной!
P.S. Поздравляем всех с наступающим праздником 9-го мая!!! С Днем Победы!!!
- при помощи такой команды можно увидеть «Zen of Python» и на наш взгляд она отлично подходит для описания того, что приведено в статье «Nine Pillars of DevOps Best Practices».
Автор собрал общие практики, про которые важно помнить при развитии DevSecOps и "разбил" их по нескольким категориям
🍭 Leadership Practices for DevOps
Тезисы о том, на что обращать внимание при работе с командой
🍭 Collaborative Culture Practices for DevOps
Тезисы о развитии взаимодействия, обмена опытом и эффективности
🍭 Design-for-DevOps Practices for DevOps
Тезисы об «облике» программного обеспечения
🍭 Continuous Integration Practices for DevOps
Тезисы о сборке программного обеспечения
🍭 Continuous Testing Practices for DevOps
Тезисы о тестах и их использовании
🍭 Elastic Infrastructure Practices for DevOps
Тезисы о создании масштабируемого и поддерживаемого контура разработки
🍭 Continuous Monitoring Practices for DevOps
Тезисы про мониторинг, его автоматизацию
🍭 Continuous Security Practices for DevOps
Тезисы про обеспечения ИБ, ответственность сторон и автоматизацию
🍭 Continuous Delivery Practices for DevOps
Тезисы про оптимизацию и корректное выстраивание процесса deployment
На первый взгляд может показаться, что «это общие слова ни о чем». Но если читать вдумчиво, то из этого может получиться неплохой инструмент оценки того, что реализовано, что можно и нужно реализовать, что важно не забыть. Надеемся, что статья будет вам полезной!
P.S. Поздравляем всех с наступающим праздником 9-го мая!!! С Днем Победы!!!
DevOps.com
Best of 2021 – Nine Pillars of DevOps Best Practices
By following the nine pillars of practices in this blog, organizations can achieve the performance potential that DevOps has to offer.
В августе Linux исполнится 30 лет. И если кто ещё не читал книжку Just for fun - крайне рекомендую. Без Линуса Торвальдса не было бы не то что Docker и Kubernetes, даже git. Страшно вспомнить время, когда мы всей командой переходили с CVS на SVN и поглядывали на первые, но уже такие удобные сборки git, а старшие коллеги матерились, что и так все работает, пусть не очень удобно.
Но пост не о том. Сам мастер Торвальдс хоть и говорит все время, что он простой инженер, своими действиями, а не указами и философиями, влияет не только на этот мир. Даже на Марсе самая распространенная ОС - Linux ;) Не хочу вытаскивать отдельные цитаты из интервью, обе части достойны прочтения. Enjoy!
https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git и
https://www.tag1consulting.com/blog/interview-linus-torvalds-open-source-and-beyond-part-2
Но пост не о том. Сам мастер Торвальдс хоть и говорит все время, что он простой инженер, своими действиями, а не указами и философиями, влияет не только на этот мир. Даже на Марсе самая распространенная ОС - Linux ;) Не хочу вытаскивать отдельные цитаты из интервью, обе части достойны прочтения. Enjoy!
https://www.tag1consulting.com/blog/interview-linus-torvalds-linux-and-git и
https://www.tag1consulting.com/blog/interview-linus-torvalds-open-source-and-beyond-part-2
Tag1 Consulting
An Interview With Linus Torvalds: Linux and Git - Part 1 30 Years Of Linux
Thirty years ago, Linus Torvalds was a 21 year old student at the University of Helsinki when he first released the Linux Kernel. His announcement started, “I’m doing a (free) operating system (just a hobby, won't be big and professional…)”. Three decades…
Всем привет!
SNYK «открыли» бесплатный доступ к Snyk Code – SAST, о котором мы писали ранее. Для бесплатного использования дается 100 сканирований в месяц, при этом важно помнить, что решение на 100% облачное, но для собственных тестов может быть интересно.
Поддерживаются следующие языки:
🍭 Java
🍭 JavaScript
🍭 Python
🍭 TypeScript
Доступна интеграция с CI/CD (Jenkins, либо через CLI) и IDE (Visual Studio Code, PyCharm, Intellij IDEA). Из любопытного – очень интересная система рекомендаций о том, «сколько раз был найдена схожая проблема», «как ее решали другие» с примерами исходного кода!
SNYK «открыли» бесплатный доступ к Snyk Code – SAST, о котором мы писали ранее. Для бесплатного использования дается 100 сканирований в месяц, при этом важно помнить, что решение на 100% облачное, но для собственных тестов может быть интересно.
Поддерживаются следующие языки:
🍭 Java
🍭 JavaScript
🍭 Python
🍭 TypeScript
Доступна интеграция с CI/CD (Jenkins, либо через CLI) и IDE (Visual Studio Code, PyCharm, Intellij IDEA). Из любопытного – очень интересная система рекомендаций о том, «сколько раз был найдена схожая проблема», «как ее решали другие» с примерами исходного кода!
Snyk
Snyk Code is now available for free | Snyk
Snyk Code now offers up to 100 vulnerability scans for free. This modern SAST joins Snyk Open Source and Snyk Container in our Free plan.
Всем привет!
Небольшая, но крайне поучительная статья доступна по ссылке. Суть ее очень проста и кроется в названии – «Everyone might be a cluster-admin in your Kubernetes cluster»
На примере реально существующего проекта "Spekt8" (а идея и правда заманчивая - красивая визуализация взаимодействия сущностей внутри кластера) автор показывает, что может произойти, если не задумываясь делать deploy проектов/утилит до их изучения.
Например, предоставление cluster-admin всем pods в default namespace. И да, это требуется согласно инструкции.
Кроме примеров того, как можно развить тему автор подготовил небольшой проект, который наглядно показывает, как эксплуатировать указанную уязвимость. Ознакомиться с ним можно по ссылке.
PS У статьи нет preview, поэтому дублируем ссылку: https://www.jeffgeerling.com/blog/2020/everyone-might-be-cluster-admin-your-kubernetes-cluster
Небольшая, но крайне поучительная статья доступна по ссылке. Суть ее очень проста и кроется в названии – «Everyone might be a cluster-admin in your Kubernetes cluster»
На примере реально существующего проекта "Spekt8" (а идея и правда заманчивая - красивая визуализация взаимодействия сущностей внутри кластера) автор показывает, что может произойти, если не задумываясь делать deploy проектов/утилит до их изучения.
Например, предоставление cluster-admin всем pods в default namespace. И да, это требуется согласно инструкции.
Кроме примеров того, как можно развить тему автор подготовил небольшой проект, который наглядно показывает, как эксплуатировать указанную уязвимость. Ознакомиться с ним можно по ссылке.
PS У статьи нет preview, поэтому дублируем ссылку: https://www.jeffgeerling.com/blog/2020/everyone-might-be-cluster-admin-your-kubernetes-cluster
GitHub
GitHub - geerlingguy/k8s-pod-rbac-breakout: Kubernetes Pod RBAC Breakout
Kubernetes Pod RBAC Breakout. Contribute to geerlingguy/k8s-pod-rbac-breakout development by creating an account on GitHub.
Всем пятница!
Если вы знаете, что общего у Netflix, обезьян и хаоса, то эта статья вам понравится! По ссылке доступна подборка Chaos Engineering Tools, которые можно применять в k8s!
🍭 kube-monkey. Один из первых проектов 2016 года. Суть проста – запускается по расписанию, выбирает deployment-жертвы, у которых в течение дня будут удаляться pods
🍭 chaoskube. Аналогично предыдущему – «убивает» pod в произвольном namespace раз в 10 минут (по умолчанию)
🍭 Chaos Mesh. Более продвинутый инструмент: помимо «убийства» pod может делать cpu/memory burn, сетевые проблемы (delay, packet repeats), нарушать работу IO и не только
🍭 Litmus Chaos. Все по-взрослому, позволяет проводить «эксперименты», обладает полноценной документацией
🍭 Chaos Toolkit. Python-инструменты, обладает набором расширений, один из которых – chaostoolkit-kubernetes. Позволяет управлять контейнерами, сервисами, больше – по ссылке!
🍭 KubeInvaders. А про этот вариант мы уже как-то писали ☺️
Перед использованием указанных выше инструментов НАСТОЙЧИВО РЕКОМЕНДУЕМ ЧИТАТЬ ДОКУМЕНТАЦИЮ, тк последствия могут быть не самые приятные. Всем хорошим выходных! ☺️☺️☺️
Если вы знаете, что общего у Netflix, обезьян и хаоса, то эта статья вам понравится! По ссылке доступна подборка Chaos Engineering Tools, которые можно применять в k8s!
🍭 kube-monkey. Один из первых проектов 2016 года. Суть проста – запускается по расписанию, выбирает deployment-жертвы, у которых в течение дня будут удаляться pods
🍭 chaoskube. Аналогично предыдущему – «убивает» pod в произвольном namespace раз в 10 минут (по умолчанию)
🍭 Chaos Mesh. Более продвинутый инструмент: помимо «убийства» pod может делать cpu/memory burn, сетевые проблемы (delay, packet repeats), нарушать работу IO и не только
🍭 Litmus Chaos. Все по-взрослому, позволяет проводить «эксперименты», обладает полноценной документацией
🍭 Chaos Toolkit. Python-инструменты, обладает набором расширений, один из которых – chaostoolkit-kubernetes. Позволяет управлять контейнерами, сервисами, больше – по ссылке!
🍭 KubeInvaders. А про этот вариант мы уже как-то писали ☺️
Перед использованием указанных выше инструментов НАСТОЙЧИВО РЕКОМЕНДУЕМ ЧИТАТЬ ДОКУМЕНТАЦИЮ, тк последствия могут быть не самые приятные. Всем хорошим выходных! ☺️☺️☺️
Palark
Open Source solutions for chaos engineering in Kubernetes
This article reviews existing tools for implementing chaos engineering in K8s including kube-monkey, chaoskube, Chaos Mesh, Litmus Chaos, Chaos Toolkit, some games, and even more.