В чём преимущества Kubernetes перед виртуализацией при использовании в Edge Computing?

Всем привет!

Продолжаем повествование про Edge Computing! ;)

В последние годы ко многим пришло понимание того как ещё больше удовлетворить критерию SWaP-C. В частности, поняли что необходимо сократить оверхэд, возникающий от виртуализации за счёт перехода к контейнеризации. При этом, за счёт использования Kubernetes, появляются ряд преимуществ над виртуализацией:
🍉 эффективность использования вычислительных ресурсов
🍉 более высокая производительность и снижение задержек (latency)
🍉 быстрое масштабирование и принцип самовосстановления (self-healing)
🍉 лучшая переносимость приложений между разными контейнерными платформами
🍉 высокая скорость разработки и сокращение Time to Market
🍉 высокая безопасность

Более подробно о преимуществах Kubernetes можно узнать из следующих статей:
🍉 https://symphony.rakuten.com/blog/better-telco-with-kubernetes
🍉 https://www.weave.works/solutions/telco/
🍉 https://www.influxdata.com/blog/kubernetes-edge-kubeedge-edge-computing/

Ну что удивлены какая связь данных заметок с DevSecOps?...
В следующей серии расскажем про способы обеспечения безопасности в Edge-кластерах Kubernetes! ;)

А k8s не привнесет overhead? :)

Всем привет!

После поста В чём преимущества Kubernetes перед виртуализацией при использовании в Edge Computing? в комментариях задали вопрос:

круто! правда не понял - хотели избежать overhead и сделали k8s, а k8s не привнесет overhead? :)

Отвечаем! ;)

С одной стороны может показаться что да, действительно controlplane-компоненты Kubernetes потребляют ресурсы. Но с этим готовы мириться за счёт того что сами приложения, которые запускаются в кластере Kubernetes, напрямую взаимодействуют с физическими устройствами сервера, т.к. Edge computing предусматривает в основном запуск приложений непосредственно на физических серверах. За счёт этого значительно снижаются задержки при взаимодействии с физическими устройствами, по сравнению с виртуализацией. Ранее в нашем канале был пост на эту тему.

Обеспечение безопасности в Edge Computing

Всем привет!

Сегодня расскажем про то как можно сделать Edge-кластер Kubernetes более безопасным.
Как было описано ранее, Edge computing подразумевает, что нам необходимо на достаточно ограниченных ресурсах и в ограниченном пространстве реализовать систему, которая к тому же должна удовлетворять требованиям ИБ. Исходя из этого и появляется самое простое решение: чтобы удовлетворить требованиям ИБ необходимо убрать из системы максимальное количество компонентов, которые им не удовлетворяют, например за счёт уменьшения размера операционной системы - оставить только те компоненты, которые обеспечивают работу с драйверами устройств и с контейнерным рантаймом.

Примерами таких сиcтем являются:
🍉 Talos
🍉 KubeEdge

Новый релиз DevSecOps Assessment Framework.

Всем привет!

Спешим поделиться радостной новостью: мы обновили наш фреймворк оценки процессов безопасной разработки (DAF). Он доступен по ссылке!

Список изменений:

🍏 Обновлена Модель технологии — некоторые практики обновлены и перемещены на другие уровни.
🍏 Новый раздел — Маппинг со стандартами. На одном листе собраны все практики DAF с их маппингом на BSIMM. Маппинг на SAMM будет в следующем релизе.
🍏 Кирилламида — на этой пирамиде зрелости группы практик расставлены на 7 уровнях по принципу "чем сложнее практика, тем выше уровень". Кирилламида нужна для понимания, какие процессы и технологии нужно внедрять в первую очередь, а что можно оставить на потом.

Более детальное описание лежит в репозитории.

Пользуйтесь на здоровье! Будем рады вашей обратной связи!

Всем привет!

Поздравляем вас с наступающим Новым Годом! 🥂🥂🥂 Большое вам спасибо за то, что вы с нами: читаете наши посты, поддерживаете лайками, участвуете в опросах! И, надеемся, что материал, публикуемый в канале, вам интересен и полезен! ☃️☃️☃️

Желаем, чтобы в 2024 году сбылись, быть может, не все желания, но точно самые сокровенные! Почему не все? Все просто! Чтобы было к чему стремиться и о чем еще мечтать, ведь как жить без них? Без мечтаний!

Еще раз большое спасибо и до встречи в 2024 году!!! Отдыхаем, набираемся сил и… врываемся с новыми идеями, мыслями и замыслами!!! 🔥🔥🔥

Ваша Редакция DevSecOps Talks

Принцип работы DNS в Kubernetes

Всем привет!

DNS – далеко не новая технология, которая упрощает взаимодействие с целевым сервисом за счет использования «понятного имени», вместо набора цифр, которые можно забыть буквально сразу.

Но как эта технология работает в Kubernetes, где многое эфемерно, а IP-адреса pod’ов могут меняться очень быстро?

Ответ можно найти в статье, описывающий принцип работы DNS в Kubernetes. Она состоит из нескольких частей:
🍭 Общая информация про IP-адресацию в K8S, сложности и пути решения (pods, services, endpoints и т.д.)
🍭 Описание процесса Service Discovery: от «создания» DNS-сервера, до назначения IP-адреса конкретному pod
🍭 Обзор Kubernetes DNS записей: какие типы бывают, их формат
🍭 Пошаговое описание процесса DNS lookup с указанием способов его «переопределения»
🍭 Использованием cache (nodelocaldns) для сокращения трафика к DNS серверу и «ускорения» процесса получения адресов

В завершение статьи Автор приводит дополнительные возможности CoreDNS (caching, frowarding, logging) и предоставляет ссылки на дополнительные материалы, посвященные устройству сети в Kubernetes

Секреты в Kubernetes: разные способы управления

Всем привет!

Задача по обеспечению конфиденциальности секретов для любого ИБ-специалиста является очень понятной и простой. Secrets в Kubernetes – не исключение!

Если Вам хотелось побольше узнать, как можно организовать безопасное хранение этих ресурсов и какие есть средства автоматизации – рекомендуем ознакомиться со статьей. Она является обзорной и рассматривает разные механизмы и способы.

Внутри можно найти информацию о:
🍭 Хранении секретов в системе контроля версий с использованием Sealed Secrets
🍭 Использовании «внешних» систем управления секретами в связке с External Secrets
🍭 Обновлении секретов с использованием Reloader от Stakater

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

Vulnerability Management: практики GitHub

Всем привет!

За один год GitHub «обработал» порядка 150 миллионов ИБ-дефектов, идентифицированных различными анализаторами.

Информацию о том, как (в общих чертах) устроен процесс работы с ИБ-дефектами можно найти в статье. Если кратко, то Команда пришла к выводу о том, что надо создать собственную систему, позволяющую выстроить идентичные flow для большого количества команд разработки.

В качестве основных характеристик были определены:
🍭 Сокращение «шума»: устранение «дублей», что могут получаться при использование нескольких сканеров
🍭 Гибкость: «подключение» и «отключение» новых сканеров должно быть максимально простым и быстрым
🍭 Единый источник правды: система должны быть удобна и информативна, чтобы пользовались ей, а не отдельно взятым сканеров

В итоге получится Security Findings (нет, не open source ☹️). Помимо вышеуказанных характеристик Команда сосредоточилась на том, чтобы создать «персональные экраны» для разных типов уязвимостей, и реализовать возможность настройки их «под себя».

А чтобы быть «ближе к разработке», Security Findings были «интегрированы» с GitHub. В итоге получился достаточно интересный продукт, который используется в Компании. В статье нет детальных how to, но очень много интересных мыслей, которые можно перенять и адаптировать под собственные нужды (особенно, с точки зрения решаемой проблематики).

Cloud Native Application Protection Platform (CNAPP) for Dummies

Всем привет!

В приложении можно скачать электронную книгу (~ 52 страницы) от Wiz, посвященную CNAPP. Она является частью серии «для новичков», основная задача которой – сформировать общее представление о рассматриваемом объекте.

Внутри можно найти разделы:
🍭 What is Cloud Security
🍭 Understanding DevOps and Shared Security Responsibility
🍭 Getting Started with CNAPP
🍭 The Need for CNAPP
🍭 Core CNAPP Capabilities и не только

Книга хорошо раскрывает проблематику и потребность в CNAPP решениях (грубо говоря, это «объединение» нескольких технологий для полноценной защиты облачных технологий и запущенных в них приложениях)

Cluster API (CAPI): что это и зачем?

Всем привет!

Есть много способов создать кластер Kubernetes! Можно воспользоваться kubeadm, можно – системами, которые позволяют создать кластер «по кнопке» или использовать возможности облачных провайдеров. А можно воспользоваться Cluster API!

Если просто – то это проект, который позволяет декларативно управлять кластерами Kubernetes (создание, обновление, взаимодействие).

В статье описываются его ключевые «компоненты»:
🍭 Infrastructure providers
🍭 Bootstrap providers
🍭 Control Plane providers

Примечательно то, что, как и все в Kubernetes, этот перечень не является конечным и Вы можете расширить его самостоятельно. Например, если Вам потребуется автоматически создавать виртуальные машины в среде виртуализации, для которой нет готового provider.

Завершает статью небольшой пример использования CAPI для создания кластера в AWS.

Кстати, именно CAPI используется для управления кластерами в Edge Computing, о чем мы писали тут.

Внедрение SAST в организации: опыт Trail of Bits

Всем привет!

Статья содержит описание 7 шагов, которые использовались в Trail of Bits при внедрении и масштабировании SAST-практики с использованием Semgrep.

Если кратко, то:
🍭 Поймите какие языки надо будет анализировать и выберите SAST // Далее все будет на примере Semgrep
🍭 Запустите Semgrep на небольшом проекте для оценки эффективности
🍭 Повторите предыдущий этап, используя разные наборы правил из Semgrep Registry
🍭 Адаптируйте наборы правил «под себя», чтобы повысить эффективность анализа
🍭 Создайте repo, в котором будете хранить наработки по собственным Semgrep-правилам
🍭 Евангелизм! Расскажите о том, что это такое, зачем это надо и какие были получены результаты всем заинтересованным
🍭 Внедрите Semgrep в CI-pipeline, настройте сканирования кодовой базы по расписанию и т.д.

На первый взгляд может показаться: «Кхм, да это же очевидно!». А разве это плохо? Возможно, у многих был подобный «алгоритм» в голове, но что-то «смущало». Однако, это вполне рабочий сценарий, который подтверждается и командой Trail of Bits.

Рекомендации, полезные советы практически каждому из этапов, ссылки на полезные материалы можно найти в статье. Еще там есть интересный раздел «Things I wish I’d known before I started using Semgrep» 😊

Как заработать 20k $ на BugBounty от GitHub?

Всем привет!

Если Вы хотите стать частью увлекательнейшего путешествия в мир безопасности CI/CD – настойчиво рекомендуем прочесть эту статью.

В ней Автор рассказывает свою историю о том, как он получил доступ к инфраструктуре GitHub (да, именно его, а не к конкретному проекту X, который на нем размещается).

У GitHub есть особенность, связанная с hosted runners при использовании их вместе с public проектами: любой workflow имеет доступ к этому runner. В том числе, если запускать этот самый workflow через PR от fork’a проекта. Так уж вышло, что в репозитории самого GitHub тоже нашелся такой runner.

Но есть нюанс… Как «обойти» потребность в approval на запуск workflow? Стать contributor’ом! Например, «поправив запятую», сделать PR, merge – готово! Теперь не требуется какое-либо согласование.

Все готово для Poisoned Pipeline Execution. Поиск секретов, создание runner внутри runner для получения persistence, выбор оптимального времени для совершения атаки, «чистка следов», получение данных (например, учетные данные от vCenter)… И Автор смог «оставаться внутри» на протяжении 5 дней!!!

Ух, безумно захватывающе, поэтому очень и очень рекомендуем Вам прочесть это самостоятельно. Гарантируем, что Вы не пожалеете 😊 Расписан каждый шаг, приведены screenshot и пояснения для лучшего понимания того, что происходит.

В завершении Автор рассуждает на тему того, чем могла грозить подобная атака, будь она совершена не в «исследовательских целях» и что можно сделать для защиты.

P.S. Кстати, такое можно «провернуть» не только с GitHub – в завершении статьи есть еще пара примеров 😊

Всем привет!

Мы бережно относимся к нашей аудитории и контенту, который вы здесь читаете.

Поэтому спрашиваем ваше мнение: хотите ли вы эпизодически видеть в нашем канале публикации с вакансиями из мира DevSecOps?

Голосуем до 22.01 23:59 (МСК)!

CI/CD Goat: writeup!

Всем привет!

По ссылке можно найти подробный writeup на тему решения задач уровня «Easy» проекта CI/CD Goat.

Автор исследует следующие сценарии:
🍭 White Rabbit. Извлечение конфиденциальной информации через Direct Poisoned Pipeline Execution, D-PPE (с доступом на изменение конфигурационного файла конвейера).
🍭 Mad Hatter. Извлечение конфиденциальной информации через Indirect Poisoned Pipeline Execution, I-PPE (без доступа на изменение конфигурационного файла конвейера, но с доступом к файлам, которые им используются).
🍭 Duchess. Извлечение конфиденциальной информации из-за отсутствия «гигиены безопасности» при удалении информации из Git.

Скриншоты, комментарии, объяснения – все на месте! 😊

P.S. CI/CD Goat – уязвимое приложение, которое может быть использовано в обучающих целях для изучения OWASP Top-10 CI/CD Security. Подробнее про него мы писали вот в этом посте.

Postgres-оператор с возможностью управления postgres extensions на лету.

Всем привет!👋

Сегодня мы хотим затронуть такую интересную тему, как базы данных в кластерах Kubernetes. Существует множество "За" и "Против" такого подхода, однако последнее время все чаще можно встретить статьи и записи докладов, в которых рассказаны реальные кейсы успешного использования баз данных в Kubernetes. Во многом это стало доступным благодаря операторам Kubernetes, которые упрощают процесс создания и управления инстансами БД в кластерах. И сегодня мы поговорим про еще один оператор:

Представляем вам Tembo - Postgres-оператор, написанный на Rust!

В основе оператора лежит другой, давно полюбившийся и считающийся одним из лучших CloudNativePG. Казалось бы, зачем писать еще один оператор, основанный на уже имеющемся?🤔 Но разработчики добавили несколько интересных концепций, которые, как нам кажется, многим будут полезны. А именно:

🎹 Концепция Stacks: заранее сконфигурированные и оптимизированные образы postgres для самых распространенных случаев
🎹 Возможность добавления postgres extensions на лету из репозитория Trunk! Вот уж, пожалуй, одна из самых полезных возможностей оператора! Теперь не нужно каждый раз пересобирать образ, если вдруг потребовалось добавить какое-то расширение!

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

Всем привет!

Рынок DevSecOps в РФ не стоит на месте и стремительно развивается!!!

В связи с этим у нас появился вопрос – «А чего, на Ваш взгляд, сейчас не хватает больше всего?» (если говорить по автоматизацию).

Поэтому мы сделали простой опрос, который просим пройти и сделать repost, чтобы получить более точные данные (насколько это возможно для статистики 😊)

Получение образа из Dockerhub: как оно происходит?

Всем привет!

Еще одна обзорная статья, которая позволяет чуть глубже погрузиться в то, что «происходит под капотом». Допустим, была запущена команда kubectl  run pod –image=myimage.

Что произойдет дальше? Откуда образ появится на узле? Кто это делает? Что, помимо самого образа, хранится в реестре? Как работает layer cache и как определяются слои, которые уже есть?

Если вам интересно найти ответы – они есть в статье, включая удобные диаграммы последовательности между Runtime и Registry.

Завершает статью достаточно забавный разбор, связанный с ErrImagePull: Too Many Requests от Dockerhub. Чтобы такого не допустить, устанавливается Private Proxy Cache Registry. Количество запросов к Dockerhub замеряется снова.

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