Всем привет, с вами DevSecOps Talks! 📢

В поисках информации по нашей любимой теме мы пришли к выводу: есть очень много классных каналов, которые посвящены по отдельности Dev, Sec и Ops, но нет канала, который позволит ответить на все вопросы сразу:

❓Что нужно не забыть при конфигурировании Kubernetes?
❓Что лучше - Prisma или Aqua?
❓Что использовать для автоматизации тестов?
❓Сколько нужно кластеров Kubernetes и как автоматизировать их настройку?
❓Как все это сделать безопасным?
❓Как правильно собрать pipeline, объединяющий всех участников сразу: разработку, ИТ и безопасность?

DevSecOps Talks - сообщество профессионалов, объединяющее всех специалистов «триады» - разработка, безопасность и эксплуатация.

Здесь мы будем делиться новостями рынка, интересными технологиями, аналитикой и лучшими практиками!

От коллег старшего поколения регулярно слышу: "Так Docker - это как Solaris Zone?". Да, но нет. Вообще удивительно как долго развивались отдельные технологии, для того, чтобы появились контейнеры, какими мы их знаем.

https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016

Привет! Совсем недавно вышло мажорное обновление Prisma Cloud до версии 20.04, в котором улучшили существующие функции и добавили новые. Мы выписали наиболее значимые изменения:

✏️ Контроль ресурсов с использованием динамического admission-контроллера для Kubernetes
✏️ Расширение списка поддерживаемых реестров (Harbor, виртуальные реестры JFrog Artifactory)
✏️ Изменение ключей в Jenkins-plugin и twistсli (централизация управления политиками; изменение ключей twistcli; потребуется модификация настроек в CI/CD-pipeline)
✏️ Добавлена возможность создания «групп образов» для более гибкого управления политиками
✏️ Расширение ролевой модели: добавлены Vulnerability Manager и DevSecOps User

Полная версия changelog доступна по ссылке. А какое изменение больше всего понравилось вам?

Для тех, кто только начинает знакомиться с бесконечным миром DevSecOps - небольшой гайд по основным понятиям в формате вебинара: https://youtu.be/mfbhISmObHI

В Kubernetes-окружениях административные задачи "второго дня" часто вызывают отдельные затруднения у администраторов и devops'ов. Резервное копирование не исключение. Бэкап контейнеризированных приложений значительно отличается по своей сути от бэкапов традиционных сред, и требует специфичных решений. Вендоры все активнее подключаются к таким задачам. Буквально вчера стало известно о партнерстве Veeam с компанией Kasten, которая изначально занимается резервированием контейнерных сред. Потираем руки, ждём классных зрелых решений

https://www.veeam.com/blog/kasten-partnership-kubernetes-backup.html

А как часто ваши разработчики по уважительной или не очень причине переносят релиз?
Но сегодня не об этом, давайте заглянем внутрь control plane Kubernetes, в самое его сердце - etcd. Статья хоть и на английском, но в качестве первого знакомства более чем. “A Closer Look At Etcd: The Brain Of A Kubernetes Cluster” by Luc Juggery https://link.medium.com/lYkBARzUI6

Привет! Если вы немного путаетесь во всех этих SAST, DAST и IAST, то в этой статье неплохо описаны основы, которые помогут понять в чем концептуальная разница указанных подходов к тестированию безопасности приложений. А еще в статье есть ссылки на описание логики работы пассивного и активного IAST (да-да, даже внутри "одного класса" тоже есть небольшие нюансы :) ) https://hdivsecurity.com/bornsecure/what-is-iast-interactive-application-security-testing/

Подробная инструкция о том, как развернуть Red Hat OpenShift версии 3.11 силами ИБ-шника. Из статьи вы узнаете о компонентах платформы, требованиях к архитектуре и сложностях, с которыми можно столкнуться при установке: https://habr.com/ru/company/jetinfosystems/blog/503618/

Охайо! Тема сегодняшнего номера - встроенные механизмы безопасности Security Context. Предлагаем разобраться с деталями и разложить все по полочкам как для Kubernetes, так и для Red Hat OpenShift.

Security Context нужны для контроля доступа контейнеров к ресурсам хостов кластера. Они контролируют сразу несколько аспектов: запуск привилегированных контейнеров, доступ к функциям ядра linux хоста, использование директорий хоста и не только (об этом подробнее читайте по ссылкам).

Security Context задаются в спецификации пода (раздел spec yaml-файла) и могут распространяться как на под, так и на конкретный контейнер в поде. Security Context могут задаваться с помощью политик. В этом случае под/контейнер запускается с конкретной политикой, которая автоматически прописывает нужные параметры конфигурации в yaml-файл пода. Сами политики создаются на уровне кластера и назначаются пользователям или сервисным учетным записям, которые могут управлять образами и контейнерами.

А теперь про главные отличия между политиками Kubernetes и Red Hat OpenShift:

📍В Red Hat OpenShift - Security Context Constraints
📍В Kubernetes - Pod Security Policy
📍Политики в обоих оркестраторах практически одинаковые, используются разные apiVersion
📍В Kubernetes отсутствуют преднастроенные политики
📍В Red Hat OpenShift присутствует набор предопределенных политик, больше опций настроек и есть приоритеты

Want to know more?
- Про политики в Kubernetes
- Про политики в Red Hat OpenShift

Пятница! Ничего серьезного, только то, о чем мечтал каждый мальчик!
А мечтал он о том, чтобы сделать собственную игру и все это в итоге привело его в ИТ и он стал менеджером, в независимости от ее сложности - это мог быть тетрис, мог быть арканоид, а могла быть MMORPG. Стоп, что?

Да, все так ) А заодно можно поковыряться в недрах Terraform на классных примерах, благодаря творчеству Scott Winkler:

🎮 Видео про разворачивание игры: Terraform & MMORPG
🎮 GitHub Scott'a: Scott's GitHub
🎮 Ссылка на его книгу (она платная): Terraform in Action!

Кстати, а девушки тоже хотели/хотят быть частью GameDev-индустрии? Расскажите об этом в чате, не стесняйтесь! :)

HashiCorp: Infrastructure enables innovation
Deploying a Multi-Cloud MMORPG with Terraform, Nomad, and Consul
See how a multi-cloud container orchestration platform and MMORPG workload can be deployed in 2 steps with Terraform.

Всем привет!

Спасибо, что были с нами на вебинарах! Как говорит мой шеф: "Не надо грустить, что это прошло, надо радоваться, что это было!".
Обещали - делаем! Набор полезных ссылок с сегодняшнего DevSec вебинара:

📎 Лучшие практики по разработке Dockerfile
📎 Trufflehog (ищет секреты в git)
📎 Bandit (SAST для Python)
📎 SNYK (анализ open source компонент)
📎 Prisma Cloud (комплексная защита контейнеров)
📎 Contrast Security ("пассивный" IAST)
📎 DefectDojo (консолидация информации по дефектам)

Надеемся, что наши вебинары были вам интересны и полезны! Если есть идеи, как сделать еще лучше - пишите на dso@jet.su 🙂

До встречи во втором сезоне?

Если у вас есть пожелания, что именно вы хотите увидеть - пишите в чат! Форматы тоже приветствуются! ) Это может быть теория и практика, может быть просто набор команд для поднятия стенда, да все, что угодно! :)

На днях вышел первый релиз Docker Enterprise от Mirantis. В релиз ноутс:
📍K8s on Windows
📍GPU support
📍Istio Ingress
📍A new UCP Installer
📍Upgrade to K8s 1.17

Если кто давно не смотрел Docker Enterprise, то UCP - это Universal Control Plane, а installer - Mirantis Launchpad. Все вместе создает дает функционал, аналогичный Rancher или Advanced Cluster Manager от Red Hat.

https://www.mirantis.com/blog/announcing-docker-enterprise-3-1-general-availability/

Привет!

Бывают случаи, когда конфиденциальная информация попадает в систему контроля версий. git rm secrets.txt не сработает. Почему? Потому что данные останутся в других commits из-за логики работы git. Он должен помнить. Все. Такая вот у него нелегкая задача.

Что же делать в таком случае, как удалить все упоминания файла, как переписать историю?
В этом случае можно воспользоваться механизмом самого git: git filter-branch и указать требуемые параметры. Единственный недостаток (если у вас большой repo) - скорость работы.

Но! И это можно решить! Есть специализированный инструмент, который работает по схожему принципу, но быстрее - BFG repo cleaner (у кого еще возникли Doom/Quake-ассоциации? :))
Просто посмотрите видео, которое приведено по ссылке на инструмент: https://rtyley.github.io/bfg-repo-cleaner/

Не забывайте, что переписывать историю - опасно и сперва обсудите все с командой, чтобы вносимые изменения не оказали на их работу негативного воздействия :)

KubiScan - это open source утилита, разработанная компанией CyberArk. Она собирает информацию о том, где и какие расширенные привилегии используются на уровне кластера Kubernetes, если в основе контроля доступа лежит RBAC. Утилита также работает на Red Hat OpenShift, несмотря на название :) 

KubiScan будет полезен ИТ-администраторам и ИБ-специалистам, чтобы получать полноценную картину о том, что творится с правами на уровне кластеров, особенно в больших инфраструктурах.

KubiScan выявляет потенциально опасные сущности и отображает найденную информацию о них:
📍Роли - Roles\ClusterRoles
📍Привязки ролей к пользователям - RoleBindings\ClusterRoleBindings
📍Пользователи - Subjects (Users, Groups and ServiceAccounts)
📍Поды и контейнеры - Pods\Containers

KubiScan также делает дампы токенов (поды) и выводит список подов, в которые пробрасываются токены через папки на хосте или переменные окружения и др.

Ссылка на утилиту:
https://github.com/cyberark/KubiScan

Ниже представлены примеры выводов экрана.