DevSecOps Talks

Привет! В разговорах про 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 (решение платное, но можно его «попробовать» бесплатно). Да, уроков не супер много, но ими можно пользоваться, чтобы «на пальцах» объяснить проблематику и что необходимо делать, чтобы ее избежать ☺️

Всем привет! Для тестирования настроек безопасности или используемых СЗИ зачастую нужен «подопытный», при помощи которого можно проводить испытания. По ссылке доступен образ 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. Если захотите протестировать – делайте это аккуратно, в тестовом окружении, сперва детально изучив возможности контейнера

Всё, что вы хотели знать о экзамене Certified DevSecOps Professional, но боялись спросить? Подготовка к экзамену представляет собой: 🥕Просмотр материала курса, куда входят вебинары и ссылки на полезные материалы 🥕Выполнение лабораторных работ, доступ к которым предоставляется на 30 дней Курс затрагивает такие темы и работу с инструментами как: 🥕Введение в основы 🥕Введение в инструменты работы 🥕Безопасность SDLC и CI/CD пайплайн 🥕Анализ компонентов программного обеспечения в CI/CD 🥕Статический анализ кода в CI/CD 🥕Динамический анализ кода в CI/CD 🥕Инфраструктура как код и её безопасность 🥕Комплаенс как код 🥕Управление уязвимостями с помощью специальных инструментов Для того, чтобы лучше раскрыть тему, рекомендуем ознакомиться с описанием курса Сам экзамен проходит в виде 12-ти часовой лабораторной работы и детальному заполнению отчёта по проделанным заданиям, на который даётся 24 часа после завершения практической части Критерий успешной сдачи - набрать 80 баллов из 100. 🔥Не забудьте получить дополнительные 10 баллов за выполнение бонусной задачи🔥 P.S. Отличный экзамен для тех, кто хочет не только разобраться в теме DevSecOps, но и получить практические навыки. Не менее важным фактором является то, что команда курса обеспечивает крутую поддержку, оперативно отвечая на вопросы в Slack и реагируя на проблемы

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

Всем привет! Еще одна отличная статья от Snyk, в которой описаны минимальные практики повышения безопасности контейнеров: 🍭 Использование linters 🍭 Запуск linters в качестве commit hooks 🍭 Тестирование образов локально (Docker, Kubernetes) 🍭 Контроль user и linux capabilities (как проверить, как настроить) 🍭 Использование сканеров уязвимостей 🍭 Image slimming практики Статья интересна тем, что в ней приводится много примеров и отсылок на free инструменты, полезные практики! Сами примеры разбираются, как в контексте Docker, так и в контексте Kubernetes ☺️

Всем привет! У Snyk много удобных cheatsheets с советами о том, как сделать элементы разработки безопаснее. Появился еще один – «10 Kubernetes Security Context settings you should understand». В нем собраны рекомендации о том, как повысить безопасность кластера, на что обращать внимание: 🍭 runAsNonRoot 🍭 runAsUser / runAsGroup 🍭 seLinuxOptions 🍭 seccompProfile 🍭 privileged / allowPrivilegeEscalation 🍭capabilities 🍭 readonlyRootFilesystem 🍭 procMount 🍭 fsGroup / fsGroupChangePolicy 🍭 sysctls В статье по ссылке приведены не только сами рекомендации, но еще и объяснения – «Зачем это делать/не делать? Какие последствия могут быть?». Рекомендуем к прочтению!

Всем привет! По ссылке можно скачать 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 и многое другое! Для того, чтобы быстро понять, что к чему, рекомендуем посмотреть ролик, доступный на сайте по ссылке. Всех с пятницей!

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

Всем привет! По ссылке доступна статья из целого цикла статей, которые направлены на подготовку к сдаче экзамена 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, о котором мы писали ранее.

Google kCTF. kCTF – это инфраструктура Kubernetes для проведения соревнований по CTF. kCTF состоит из: 🏷 nsjail для изоляции игроков 🏷 Docker для запуска контейнеров 🏷 Kubernetes для управления. В работе это выглядит следующим образом: 🍏 В кластере есть группа заданий. 🍏 Каждое задание представляет собой Deployment в Kubernetes. 🍏 Внутри каждого Deployment есть группа контейнеров. 🍏 Один контейнер выполняет healthchecks – т.е. проверяет, удалось ли вам запустить эксплойт. 🍏 Другой контейнер запускает задание. Задание использует nsjail и создает новое окружение для каждого TCP соединения. Подробности работы и инструкции для проведения CTF смотрите на https://github.com/google/kctf

Всем привет! Поздравляем всех с пятницей! Сегодня можно сбавить обороты, побаловать себя новыми вкусами из ближайшей кофейни и запланировать дела на следующую неделю. А так как lulz toolz в последнее время у нас было достаточно, сегодня мы хотим поделиться полезной штукой, тест которой можно взять как тему для следующей недели! Итак, сегодня расскажем про Denial of Service Container - Dostainer! 🍩 Маленькая утилита оформленная в контейнере, организующая стресс-тест вашего k8s кластера. 🍩 Контейнер содержит несколько скриптов, аллоцирующих всю доступную оперативную память и дисковое пространство 🍩 Контейнер так же содержит fork-бомбу, генерирующую множество процессов С помощью этой утилиты можно провести нагрузочное тестирование вашего кластера целиком или отдельных его нод, на которые приземлится под с контейнером. Стоит отметить, что утилита призвана искать бреши в ресурсных квотах. Таким образом, если ваш деплой приложений подвергается наложению resource quotas по умолчанию, вам выполнение этого теста не страшно. ⚠️Внимание!⚠️ Однако, если запустить контейнер без limits для ресурсов, он может отправить ноду или весь кластер в отказ! Будьте осторожны и не планируйте стресс-тесты на PROD’е в пятницу 😉 Подробнее на GitHub разработчика 👇 https://github.com/uchi-mata/dostainer

Всем привет! Управление уязвимостями – одновременно простая (много инструментов, чтобы их найти) и сложная (за что браться в первую очередь, реально ли эта уязвимость exploitable и т.д.) задача. Еще одной «проблемой» становится отсутствие «единой точки управления», которая позволит если не управлять сканированиями, то хотя бы агрегировать информацию в себе. Одними из примеров решений, решающих такую задачу являются Defect DOJO (open source), Archery (open source) и ThreadFix (entrerprise). Есть еще один интересный представитель подобного класса решений – Vulcan Cyber! 🍭 Прочитать про него можно на сайте (в самом низу есть набор whitepaper) 🍭 Интеграций много, ознакомиться с ними можно по ссылке 🍭 Есть возможность получения free account (с некоторыми ограничениями, указанными по ссылке) Единственный «нюанс» - решение облачное и подойдет в РФ далеко не всем, но проект достаточно интересный благодаря предлагаемому функционалу

Привет! В феврале 2021 года была анонсирована новость о покупке StackRox Red Hat’ом. Теперь продукт называется Red Hat Advanced Cluster Security for Kubernetes. Многим было интересно, как именно OpenShift будет работать вместе с StackRox. Время пришло! Ребята объявили вебинар, на котором будут рассмотрены вопросы (теория + демонстрация): 🍭 Обеспечение безопасности supply chain – сканирование образов и реестров, интеграция с CI/CD 🍭 Защита инфраструктуры – конфигурация Kubernetes, compliance, security posture management 🍭 Защита run time – управление привилегия, контроль сети, анализ и реагирование на угрозы Вебинар пройдет 24 марта (среда) в 17:00 по Москве. Регистрация доступна по ссылке. Preview не работает, поэтому дублируем ссылку: https://security.stackrox.com/Kube-native-Security-with-OpenShift_Registration.html?Source=Community&LSource=Community

Всем привет! В Windows 10 есть одна интересная возможность, которая отключена by default – WSL2 (Windows Subsystem for Linux). Все достаточно просто – практически полноценный bash для Windows без необходимости установки полноценной *nix виртуальной машины! Устанавливается (активируется, скачивается необходимый "дистрибутив") очень просто, об этом можно почитать тут. Зачем это нужно? Да много зачем 😊 Один из возможных сценариев 🍭 Скачиваем Visual Studio Code (можно добавить YAML-edition функциональность) 🍭 Настраиваем интеграцию с WSL2 (об этом можно почитать тут) 🍭 Устанавливаем Docker for Windows, попутно интегируя с WSL2 (об этом можно почитать тут) 🍭 Устанавливаем Minikube и kubectl Готово! Мы получили небольшой стенд, который можно использовать для тестирования и обучения по контейнерам без необходимости создания отдельной VM (если вы привыкли к Windows и не хотите «городить огород»). Подробнее можно почитать в этой статье. P.S. Единственный нюанс, необходимо прописать alias в ~/.bashrc, чтобы можно было пользовать "kubectl", а не "kubectl.exe", т.к. сам по себе WSL2 этого не делает, аналогично с docker и т.д.

Всем привет! С момента большого взрыва, когда из ничего появилась наша вселенная, вместе с ней начало существовать и само время! Миллиарды лет оно движется стабильно и неумолимо, и всегда только в одном направлении. А это значит, что чтобы мы ни делали, она наступает всегда. Пятница! И сколь неизбежно наступление пятницы, столь неумолимо.... Время забавных постов! Сегодня спешим поделиться чудесной, прелестно-прекрасной, абсолютно бесполезной, и от того не менее изящной утилитой Kubecraft! «Название кажется подозрительно знакомым» - скажете вы «Все верно!» - ответим мы! Визуализация объектов в кластере Kubernetes через стандартный Minecraft клиент! Просто загружаете образ сервера в кластер, выполняете expose приложения наружу, подключаетесь по этому адресу и вуаля! В мир Minecraft с неба падают свиньи, коровы и куры ваших приложений в кластере! Почувствуй себя Kubernetes фермером! Разобраться легко: 🍩 Хрюшки - pods 🍩 Коровки - replicasets 🍩 Курочки - services 🍩 Лошадки - deployments Щас бы подам хвосты накрутить, ух! Но если это нужно, то можно и управлять workload’ами. Например, удалить deployment, забив лошадь... 😱 2021 год, будущее уже здесь! Ссылочка на GitHub проекта ниже! Приятных исследований 😊👇 https://github.com/stevesloka/kubecraft

Всем привет! Kyverno – это инструмент для работы с политиками в Kubernetes, который может использоваться как для сканирования ресурсов кластера на соответствие лучшим практикам, так и для реализации этих практик путем блокировки или изменения API запросов. Важной особенностью является то, что управление политиками осуществляется аналогично управлению ресурсами Kubernetes. Это значит, что а) изучение нового языка (как в случае с OPA используется Rego, например) не требуется и б) управление политиками можно реализовать через стандартные утилиты, такие как kubectl. Что можно делать с Kyverno? 🍡Проверять, изменять или генерировать любые ресурсы (например, генерировать квоты для namespaces при необходимости) 🍡Блокировать ресурсы или генерировать отчеты о нарушении политик 🍡Проверять политики и ресурсы в CI/CD сборке до применения в кластере, используя Kyverno CLI и пр. Как работает Kyverno? 🍡Kyverno запускается в кластере как динамический admission controller, 🍡Посредством webhook получает проверяющие или изменяющие HTTP запросы с kube-apiserver 🍡Применяет соответствующие политики контроля Установить Kyverno можно или напрямую из манифеста, или используя Helm. Более подробная информация находится здесь: https://kyverno.io/docs/ А есть ли примеры? Примеры есть. Один из них представлен ниже. Запрет на использование пользователя с правами root

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root-user
spec:
  validationFailureAction: audit
  rules:
  - name: validate-runAsNonRoot
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Running as root user is not allowed. Set runAsNonRoot to true"
      anyPattern:
      - spec:
          securityContext:
            runAsNonRoot: true
      - spec:
          securityContext:
            runAsUser: ">0"
      - spec:
          containers:
          - securityContext:
              runAsNonRoot: true
      - spec:
          containers:
          - securityContext:
              runAsUser: ">0"

Больше примеров можно найти по ссылке: https://github.com/kyverno/kyverno/blob/main/samples/README.md

Всем привет! Бывают случаи, когда необходимо создать контейнер из другого контейнера (runner в CI, сбор дополнительных метрик). Как это можно сделать? Есть несколько основных «стратегий»: 🍭 Docker in Docker, DinD – официальный образ, который позволяет запускать контейнер внутри контейнера we need to go deeper. Нюанс – ему требуется –privileged 🍭 Docker out of Docker, DooD – реализуется через mount /var/run/docker.sock, что позволяет использовать docker engine хоста для запуска контейнера «по соседству». Нюанс – можно получить информацию о контейнерах на хосте 🍭 Альтернативные runtime – реализуется при помощи «подмены» runtime, например, на sysbox-runc Более подробно про это можно почитать в статье. В целом практика, хоть и существует, не является безопасной и рекомендуемой. А вы используете такие подходы? Если да, то зачем и почему без этого нельзя обойтись?

Привет! Компания Sonatype расширила свое предложение, добавив туда Nexus Container и расширив возможности Lifecycle добавлением Infrastructure as Code Pack. Nexus Container позволяет сканировать образы на наличие уязвимостей и compliance-несоответствий, но, что наиболее интересно на наш взгляд: «Not only do we continuously monitor your containers to identify vulnerabilities and share available fixes once in-production, we’re the only solution that can enforce Data Loss Protection and prevent zero-day malware and network attacks, tunneling, and breaches». Container DLP engine – звучит интересно, что из себя представляет на практике пока не очень понятно (как только протестируем – расскажем!) Infrastructure as Code помогает выбирать наиболее безопасные open-source компоненты для использования в вашей инфраструктуре Немного подробней можно почитать тут: 🍭 Nexus Container: https://www.sonatype.com/nexus/container?topnav=true 🍭 Infrastructure as Code: https://www.sonatype.com/nexus/infrastructure-as-code?topnav=true