DevSecOps Talks
6.55K subscribers
59 photos
71 files
964 links
Рассказываем об актуальном в мире DevSecOps. Канал DevSecOps-команды "Инфосистемы Джет"
Download Telegram
Всем привет!

По ссылке доступна статья из целого цикла статей, которые направлены на подготовку к сдаче экзамена CKS (Certified Kubernetes Specialist).

Статья посвящена Network Policy и тому, как их «готовить».
Задача проста – «Create a default deny NetworkPolicy and then allowlist more traffic», приводится ее решение, состоящее из следующих шагов:

🍭 Создаем namespace
🍭 Добавляем Egress Default Deny
🍭 Разрешаем DNS
🍭 Разрешаем Egress к некоторым Pods
🍭 Игнорируем Ingress трафик

Статья простая, понятная и с примерами. В ней можно найти ссылки на другие статьи, которые могу пригодиться при подготовке к CKS (Immutable Pods, ImagePolicyWebhook, Container Hardening и т.д.). Структура везде одинакова – описание задачи и ее возможное решение.

P.S. В статье можно найти упоминание удобного инструмента для редактирования Network Policy, о котором мы писали ранее.
Всем привет!

Согласитесь, достаточно удобно когда названия ваших веток в git несут смысл, а с коммитом приходит нормальное описание (ещё лучше когда со ссылкой на задачи в Jira). А знаете, что у Gitlab до есть целая группа функций "Push Rules", которые позволяля делать такие полезные вещи:
🍬 запретить удалять тэги при использование git push
🍬 использовать регулярные выражения для проверки email авторов
🍬 запретить пушить секреты в явном виде
🍬 использовать регулярные выражения для проверки сообщения коммита
🍬 запретить пушить определенных расширения файлов
🍬 использовать регулярные выражения для проверки названия новых веток

Почитать подробнее можно по ссылке.

К сожалению с обновления 13.9 и смены ценовой политики компании "Push Rules" распространяются начиная от плана Premium.
Всем привет!

По ссылке можно скачать Lens – open source IDE для Kubernetes! Удобный инструмент для тех, кто все же предпочитает использование GUI вместе с консолью.

Чем может помочь Lens?
🍭 Устанавливается на Windows, Linux, Mac
🍭 Наглядное структурирование nodes, namespaces, services, deployments, statefulsets, pods и т.д.
🍭 Работа с multiple clusters
🍭 Поддержка RBAC Kubernetes
🍭 Возможность получения доступа к pod terminal
🍭 Предоставление метрик использования ресурсов кластера
🍭 Локальное сохранение логов workloads для дальнейшего debug/troubleshooting и многое другое!

Для того, чтобы быстро понять, что к чему, рекомендуем посмотреть ролик, доступный на сайте по ссылке.

Всех с пятницей!
Всем привет!

У Snyk много удобных cheatsheets с советами о том, как сделать элементы разработки безопаснее. Появился еще один – «10 Kubernetes Security Context settings you should understand».

В нем собраны рекомендации о том, как повысить безопасность кластера, на что обращать внимание:
🍭 runAsNonRoot
🍭 runAsUser / runAsGroup
🍭 seLinuxOptions
🍭 seccompProfile
🍭 privileged / allowPrivilegeEscalation
🍭capabilities
🍭 readonlyRootFilesystem
🍭 procMount
🍭 fsGroup / fsGroupChangePolicy
🍭 sysctls

В статье по ссылке приведены не только сами рекомендации, но еще и объяснения«Зачем это делать/не делать? Какие последствия могут быть?». Рекомендуем к прочтению!
Vulnerability Prioritization Through The Eyes Of Hackers.pdf
6.1 MB
Всем привет!

Одна из самых больших сложностей процесса управления дефектами – приоритизация: за что браться в первую очередь, что наиболее важно?

В приложении небольшое исследование WhiteSource, посвященное этой теме применительно к open source. Ребята взяли такие «классические» подходы к приоритизации, как:

🍭 Уровень CVSS
🍭 Уровень критичности приложений
🍭 «Популярность» open source
🍭 Disclosure date
🍭 Простота устранения

На этом они не остановились и сделали корреляцию с данными CYR3CON – компании, специализирующейся на предсказании кибератак, в том числе с использованием данных из Deep/Dark Web. Получился интересный результат! Какой? Советуем прочитать отчет ☺️
Всем привет!

Еще одна отличная статья от Snyk, в которой описаны минимальные практики повышения безопасности контейнеров:

🍭 Использование linters
🍭 Запуск linters в качестве commit hooks
🍭 Тестирование образов локально (Docker, Kubernetes)
🍭 Контроль user и linux capabilities (как проверить, как настроить)
🍭 Использование сканеров уязвимостей
🍭 Image slimming практики

Статья интересна тем, что в ней приводится много примеров и отсылок на free инструменты, полезные практики! Сами примеры разбираются, как в контексте Docker, так и в контексте Kubernetes ☺️
🍩 Контейнеры призваны ускорить time-to-market и это очень полезно!
🍩 Системы контейнерной оркестрации помогают в этом, способствуя автоматизации развертывания и масштабирования контейнерных приложений - это еще лучше!

Но как и у любого инструмента, у k8s тоже есть инструкция. Будем же ее читать, чтобы наши контейнеры помогали решать проблемы, а не добавляли их!
Всё, что вы хотели знать о экзамене Certified DevSecOps Professional, но боялись спросить?

Подготовка к экзамену представляет собой:
🥕Просмотр материала курса, куда входят вебинары и ссылки на полезные материалы
🥕Выполнение лабораторных работ, доступ к которым предоставляется на 30 дней

Курс затрагивает такие темы и работу с инструментами как:
🥕Введение в основы
🥕Введение в инструменты работы
🥕Безопасность SDLC и CI/CD пайплайн
🥕Анализ компонентов программного обеспечения в CI/CD
🥕Статический анализ кода в CI/CD
🥕Динамический анализ кода в CI/CD
🥕Инфраструктура как код и её безопасность
🥕Комплаенс как код
🥕Управление уязвимостями с помощью специальных инструментов

Для того, чтобы лучше раскрыть тему, рекомендуем ознакомиться с описанием курса

Сам экзамен проходит в виде 12-ти часовой лабораторной работы и детальному заполнению отчёта по проделанным заданиям, на который даётся 24 часа после завершения практической части

Критерий успешной сдачи - набрать 80 баллов из 100.
🔥Не забудьте получить дополнительные 10 баллов за выполнение бонусной задачи🔥

P.S. Отличный экзамен для тех, кто хочет не только разобраться в теме DevSecOps, но и получить практические навыки.
Не менее важным фактором является то, что команда курса обеспечивает крутую поддержку, оперативно отвечая на вопросы в Slack и реагируя на проблемы
Всем привет!

Для тестирования настроек безопасности или используемых СЗИ зачастую нужен «подопытный», при помощи которого можно проводить испытания.

По ссылке доступен образ BOtB: Break out of the box! Согласно описанию, BOtB – инструмент для анализа и эксплуатации уязвимостей в контейнерах, подготовленный для использования pentester’ами и инженерами.

Что он умеет? Например (список не полный):
🍭 Container breakout через exposed Docker daemons (docker.sock)
🍭 Container breakout через CVE-2019-5736
🍭 Privileged container breakout через имеющиеся CAPS и SYSCALLS
🍭 Идентификация и попытка использования Kubernetes Service Accounts secrets
🍭 Идентификация и анализ чувствительных данных в ENV и процессов в the ProcFS, например /Proc/{pid}/Environ

Все вышеописанное и не только можно реализовать через аргументы CLI или с использованием YAML config file.

P.S. Если захотите протестировать – делайте это аккуратно, в тестовом окружении, сперва детально изучив возможности контейнера
Привет!

В разговорах про 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 (решение платное, но можно его «попробовать» бесплатно).

Да, уроков не супер много, но ими можно пользоваться, чтобы «на пальцах» объяснить проблематику и что необходимо делать, чтобы ее избежать ☺️
Всем привет!

До чего же круто работать в 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
Всем привет!

Если вы любите и используете 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
Привет!

В инфраструктуре все должно быть прекрасно: и отказоустойчивость, и sizing, и код, и безопасность!
А чтобы это было проще контролировать, ребята анонсировали выход Checkov 2.0!

Немного об основных изменениях:
🍭 Graph based policies, которые позволяют построить «дерево сущностей» и делать к нему запросы для проверки гипотез
🍭 Анализ Dockerfile на соответствие лучшим практикам (COPY вместо ADD, наличие HealtCheck, 22 порт not exposed и т.д.). Согласно заверениям авторов – количество правил будет дополняться. Про лучшие практики написания Dockerfile можно почитать вот тут
🍭 По умолчанию добавлено около 250 новых политик проверки

Подробности можно прочесть по вышеуказанной ссылке. Кстати, там же есть ссылка на Slack-канал, где можно следить за последними новостями ☺️
Привет!

Недавно мы писали про 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 вкратце можно почитать вот тут ☺️
Всем привет!

Обычно настройка 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 процессов вам понравится!
Всем привет!

25 апреля, в 20:00 по Московскому времени (1 pm, ET) состоится двухчасовой workshop на тему Semgrep!

Что будет рассмотрено?
🍭 Как быстро настроить интеграцию с CI
🍭 На что обращать внимание для формирования непрерывного сканирования кода
🍭 Как использовать сканеры для проверки выполнения требований ИБ
🍭 Чем может помочь Semgrep, как его использовать
На workshop будет разобрано большое количество практических задач, приведены реальные примеры.

Все, что нужно – зарегистрироваться, найти время и создать (если у вас его нет) GitHub account!

Надеемся, что вам понравится!
Привет!

В апреле 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!
Привет!

Как часто вы это слышали: «Сложно, все непонятно, можно как-нибудь попроще, да за 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, а ребята обещают продолжать снимать подобные ролики «Просто и понятно!»
Привет!

В репозитории доступен набор базовых сетевых политик, которые можно использовать при освоении инструмента 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!