DevSecOps Talks

Централизованное управление в Edge Computing

Всем привет!

В предыдущих постах мы затронули архитектуру Edge Computing, находящуюся на стороне Edge и пришли к выводу, что Kubernetes идеально для этого подходит.

❓Но как можно централизованно управлять данными кластерами?.. 🤔

У Kubernetes есть специализированный подпроект для этого - Cluster API (https://cluster-api.sigs.k8s.io/). На сегодняшний день есть несколько зарубежных решений основанных на Cluster API, такие как: Rancher, Redhat ACM. Также есть и отечественное решение, основанное на Cluster API - Штурвал.

Все перечисленные выше решения (в том числе и Штурвал), позволяют централизованно управлять edge-кластерами:
🍉 управлять настройками edge-кластеров (в том числе и на уровне параметров ОС)
🍉 осуществлять мониторинг и сбор логов
🍉 управлять политиками безопасности
🍉 централизованно обновлять программное обеспечение за счёт использования CD-инструментов

Хранение данных в Edge Computing

Всем привет!
Надеемся, что наши читатели отлично отдохнули и готовы к тому чтобы узнать что-то новое и интересное из мира DevSecOps и не только! А мы по-прежнему постараемся делиться с Вами полезной и интересной информацией и в этом году! 🤓

Наши постоянные читатели помнят, что в конце прошедшего года мы начали Вас знакомить с направлением Edge Computing, в частности, подчеркнули важность обеспечения безопасности Edge-кластеров в связи с тем, что они устанавливаются в непосредственной близости для взаимодействия с конечными клиентами.

С тем как можно разместить сами приложения в безопасном отказоустойчивом Edge-кластере мы более-менее разобрались. Но приложениям наверняка может понадобиться хранилище как минимум для временного хранения данных с учётом того, что использование SDS-решений в Edge может быть невозможным в силу ограниченности ресурсов.

❓Как это обеспечить?... 🤔

Существует несколько способов хранения данных в Edge Computing, которые объединяются общим понятием Edge Storage:
🍉 хранение на SD-картах
🍉 использование PCIe SSD
🍉 использование RAID-массивов
🍉 использование HDD
🍉 использование NAS


Более подробно о подходах к хранению данных (Edge Storage) можно узнать в следующих статьях:
🍉 https://massive.io/file-transfer/what-is-edge-storage/
🍉 https://thenewstack.io/storage/an-architects-guide-to-edge-storage/
🍉 https://www.couchbase.com/blog/edge-computing-architecture-introduction/
🍉 https://horizontechnology.com/news/edge-computing-data-storage-guide/

А завтра расскажем о том как можно централизованно управлять Edge-кластерами! 😉

Всем привет!

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

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

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

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

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

Всем привет!

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

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

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

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

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

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

Всем привет!

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

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

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

Всем привет!

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

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

Отвечаем! ;)

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

В чём преимущества 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! ;)

2-нодовый отказоустойчивый кластер Kubernetes!
(нет, это не опечатка)

Всем привет!

В предыдущих постах мы познакомились с понятием Edge Computing и роли Kubernetes в Edge Computing и обещали рассказать о том как можно сократить затраты на кластер Kubernetes в Edge Computing.

Помимо уже разобранных факторов также являются достаточно важными факторами:

🍉 мобильность/компактность
🍉 стоимость решения

Чтобы удовлетворить данным факторам необходимо спроектировать Платформу на базе Kubernetes, которая будет состоять из одной ноды, но тогда теряется отказоустойчивость, или же из классических трёх нод для обеспечения кворума.

И тут встаёт архитектурная диллема: купить один сервер под решение или три, но, при этом, заплатить в три раза больше за обеспечение отказоустойчивости... 🤔

❓А можно как-то сэкономить?..🤔

‼️Да, можно - сделать двухнодовый кластер Kubernetes! 🤓

❓Что нам для этого потребуется?..🤔

Всего лишь найти замену etcd, который требует наличия кворума! И это позволит реализовать 2-нодовый отказоустойчивый кластер Kubernetes! 🤓

На просторах Интернет вы, возможно с трудом, но найдёте готовые решения (1, 2), но такое решение возможно собрать самим, например, из следующих кубиков:

🍉 kine - транслятор запросов etcd в PostgreSQL/MySQL/SQLite(который, кстати, используется в легковесном k3s и он прекрасно подходит для Edge Computing)
🍉 Собственно СУБД PostgreSQL/MySQL в режиме Active/Standby

Роль Kubernetes в Edge Comuting

Всем привет!

В предыдущем посте шла речь про то, что такое Edge Computing и про то, какие факторы являются важными:
🍉 обеспечение отказоустойчивости
🍉 мобильность
🍉 быстрое развёртывание

Платформы на базе Kubernetes идеально сочетают все вышеописанные свойства! В частности Kubernetes позволяет быстро развернуть необходимые прикладные приложения в микродатацентрах и мобильных базовых станциях и оперативно заскейлиться в зависимости от изменения типа трафика.

Тут также на помощь приходят принципы GitOps, которые позволяют из одной центральной точки распространить необходимую версию приложения на все базовые станции с установленным Kubernetes на борту.

Ну что, нравится такой подход?
Тогда читаем более подробно про это:

🍉 https://www.cncf.io/blog/2022/08/18/kubernetes-on-the-edge-getting-started-with-kubeedge-and-kubernetes-for-edge-computing/
🍉 https://thenewstack.io/a-new-kubernetes-edge-architecture/
🍉 https://www.f5.com/company/blog/managing-thousands-of-edge-kubernetes-clusters-with-gitops

В следующей серии расскажем о том как можно сократить затраты на кластер Kubernetes в Edge Computing.

DevSecOps Maturity Model 2023

Всем привет!

Хорошо это или плохо, но мир информационной безопасности любит «меряться». Одной из таких «мер» является уровень зрелости, моделей оценки которых очень много. Сегодня представляем Вашему вниманию еще одну – DevSecOps Maturity Model 2023.

Модель описывает 4 «уровня» (stage) среди 6 основных областей (доменов) компетенций и деятельности. Уровни «классические» - от Beginner до Expert. Для каждого из них модель описывает некоторые качественные характеристики, которые помогут определиться с «местоположением».

Области, в свою очередь, включают в себя:
🍭 People & Culture
🍭 Plan & Develop
🍭 Build & Test
🍭 Release and Deploy
🍭 Operate
🍭 Observe & Respond

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

P.S. А какая Ваша любимая песня Pink Floyd? 😊 Пишите в комментариях!

Edge Computing

Всем привет!

Представьте себе, что вам нужно провести очень крупное событие 🏟, которое подразумевает огромнейшее количество людей в одном месте
🏃🏻‍♀🏃🏃‍♂🏃🏻‍♀🏃🏃‍♂
и, при этом, необходимо обеспечить качественное оказание
📱💻 телекоммуникационных услуг
на данном событии как для зрителей события (для того чтобы они могли без каких-либо задержек обмениваться видео со своими друзьями и стримить видео онлайн), так и
🧑‍💻🎥📽 технического персонала
(для проведения качественной онлайн-трансляции спортивного события).

❓Что для этого необходимо?.. 🤔

Скорее всего для этого понадобится в кратчайшие сроки развернуть
🚐 мобильные микродатацентры
и
🗼мобильные базовые станции
вблизи проведения данного события!

При этом, чтобы была возможность оказать качественные телекоммуникационные услуги, необходимо обеспечить отказоустойчивость таких телекоммуникационных решений, но, при этом, соответствовать оптимальному критерию SWaP-C, то есть сделать так чтобы само решение не было очень громоздким (не занимало много места, чтобы его можно было беспроблемно доставить и развернуть в рамках плотной городской застройки) и не было очень дорогим.

Чтобы всё это реализовать существует архитектура Edge Computing, которая подразумевает что часть полезных вычислений будет выполняться в точке, которая максимально приближена к конечному пользователю. За счёт этого можно частично снять нагрузку с каналов связи для передачи трафика за счёт обработки трафика на стороне Edge, тем самым, снизить задержки передачи обработанного трафика и обеспечить качественное предоставление телекоммуникационных услуг.

Для более подробного знакомства с тем, что такое Edge Computing советуем почитать следующие статьи:

🍉 Computing platform types
🍉 What are Various Types of Edge Computing that Exist Today?
🍉 4 Types of Edge Computing — Broadly Categorized
🍉 Far-edge future

С этого поста мы начинаем небольшой цикл заметок на тему Edge Computing!

В следующей серии расскажем при чём тут 💻 Kubernetes! 😉

Recommended Practices for Managing Open-Source Software and Software Bill of Materials

Всем привет!

В приложении доступен материал от NSA (~ 45 страниц), посвященный безопасности цепочки поставки ПО, а именно – управлению open source и SBOM.

Внутри можно найти:
🍭 Создание собственного безопасного repo для open source
🍭 Управление рисками ИБ при работе с open source компонентами
🍭 Использование электронной подписи для артефактов
🍭 Рекомендации по созданию/управлению SBOM и не только

Материал по большей части теоретический, в нем отсутствуют детальные how to. Однако, много полезной информации для размышления относительно того, «какой может быть целевая картина».

Fuzzing на примере использования libFuzzer

Всем привет!

Fuzzing – интересная, но далеко не самая очевидная тема, особенно «в начале пути». Чтобы чуть упростить погружение предлагаем Вашему вниманию статью. В ней собрана как теоретическая информация, так и пара практических примеров.

Рассматривается следующий «процесс»:
🍭 Инструментация. Грубо говоря – добавление в код или в исполняемый файл средств, которые позволяют понять какие части кода были выполнены в момент тестирования (code coverage)
🍭 Генерация входных данных. Первичные данные, которые будут использованы в дальнейшем – можно генерировать как «руками», так и с использованием средств автоматизации
🍭 Мутация входных данных. Генерация новых тестовых данных за счет изменения существующих
🍭 Тестирование. Применение сгенерированных тестовых данных для анализа программного обеспечения
🍭 Сбор обратной связи. Анализ code coverage, запуск повторных тестов для получения лучшего результата

Для указанного выше «процесса» Автор статьи создает PoC на примере минималистичного приложения, написанного на C++. Второй пример чуть интереснее: в качестве «подопытного» выступает библиотека libxml2. Комментарии, код, описание, результаты – все на месте!

Написание Semgrep-правил: основы

Всем привет!

В статье описываются основы написания собственных правил анализа исходного кода с использованием Semgrep.

Например:
🍭 Поиск patterns
🍭 Адаптация patterns для более точного поиска
🍭 Написание правил для поиска ошибок аутентификации в API Endpoints
🍭 Передача пользовательских данных в качестве параметров в os.system() и не только

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

Minder: защита repos, артефактов и зависимостей

Всем привет!

Minder – open source проект от Stacklok, которые позволяет повысить уровень защищенности Компаний против software supply chain атак. Пока что решение работает только с GitHub, однако в планах есть и такое «In the future, Minder will support other source control and artifact repositories».

Основными функциями являются:
🍭 Управление конфигурациями repo, параметрами его безопасности
🍭 Аттестация артефактов: контроль подписей артефактов, их целостности
🍭 Управление зависимостями: за счет интеграции с Trusty (общая информация по пакету), Minder позволяет реализовать policy-driven подход к управлению зависимостями (например, на основании уровня риска)
🍭 Уведомления: отправка сообщений о нарушениях политик или auto remediation (там, где это возможно)

Представляет из себя cli-утилиту и сервер, обрабатывающий запросы. Сервер может быть облачным (только для public repo), а если надо – можно развернуть его локально. Web-интерфейс отсутствует, только консоль и, конечно же, YAML! (возможно, кто-то сделает видео со Стивом Балмером, где он говорит YAML, YAML, YAML, YAML… 😊)

Процесс работы примерно такой: установка Minder, регистрация repository, создание profiles и rules (с перечнем из коробки можно ознакомиться тут) с последующим применением и анализов результатов. Можно создавать свои правила, подробнее про это написано в статье. И, как всегда, больше подробностей можно найти в документации.

Важно: пока что Minder (кстати, как и Trusty), находится в стадии «experimental»

Git, SVN и все все все

Всем привет!

В последние годы мы все чаще сталкиваемся с необходимостью замены устаревших решений на более современные. Одно из таких решений - Subversion, когда-то бывший(а для кого-то и сейчас являющийся), конкурент Git.

Git стал де-факто индустриальным стандартом, многие разработчики умеют работать только с ним. Возникает вопрос миграции

В статье от разработчиков Git достаточно подробно описывается:
🍭Как мигрировать с Subversion, Mercurial и Perforce в Git
🍭Как перенести коммиты, чтобы разработчики и не заметили
🍭Как автоматизировать эти задачи

Bash Golf

Всем привет!

В современном мире господствующего DevOps'а каждый пишет множество скриптов. Каждый из них, по сути, маленькая программа, как и завещали нам отцы Unix.

В цикле статей автор предлагает свои "маленькие программы" и хитрости на языке Bash для решения различных задач.

🍭 Умеет ли Bash отправлять TCP запросы без дополнительных утилит?
🍭 Есть ли встроенная переменная, со случайным числом?
🍭 Как экспортировать функцию в xargs?

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

Часть 1
Часть 2
Часть 3

DevNetOps

Всем привет!

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

Но мир движется вперед. IaC и GitOps приходят из мира IT и в мир сетей. Профильные издания уже по полной используют термин DevNetOps.


В статье автор попытался разобраться, как можно управлять сетевыми устройствами из пайплайнов, на примере GitlabCI и Arista cEOS.

Советы по Custom Controller для Kubernetes

Всем привет!

«В любой непонятной ситуации – пиши свой operator!». Как и в любой шутке, в этой есть доля правды, ведь Kubernetes Operators крайне сильный инструмент, который позволяет расширить функциональность Kubernetes так, как нужно именно Вам.

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

В ней собраны следующие советы:
🍭 Обработка ресурсов, помеченных для удаления
🍭 Фильтрация событий, влияющих на реконсиляцию
🍭 Binding ресурсов с использованием ownership
🍭 Запись событий
🍭 Проверка того, запускается ли operator в Red Hat OpenShift и не только

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

DevSecOps Pipelines

Всем привет!

Неплохой long read на предстоящие выходные! Если верить «оценке», то потребуется ~ 53 минуты, чтобы прочесть статью.

В ней собраны примеры исходного кода на Python, которые можно использовать для запуска анализаторов и последующей обработки результатов.

Например:
🍭 Создание и анализ проекта с SonarQube (взаимодействие через REST API)
🍭 Анализ кода с использованием Semgrep (взаимодействие через cmd)
🍭 Запуск сканирования web-приложения с использованием ZAP
🍭 Анализ образов контейнеров с использованием Trivy
🍭 Запись и получение секретов из HashiCorp Vault через hvac
🍭 Подпись артефактов и еще много-много-много чего, рекомендуем ознакомиться лично

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

В материале нет ничего революционного: если вы писали собственные jobs с проверками, то увидите знакомые команды. Однако, приятно, когда все «под рукой» и «рядом» 😊