ch
Feedback
DevSecOps Talks

DevSecOps Talks

前往频道在 Telegram

Рассказываем об актуальном в мире DevSecOps. Канал DevSecOps-команды "Инфосистемы Джет"

显示更多
8 005
订阅者
无数据24 小时
+127
+4630
帖子存档
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 с проверками, то увидите знакомые команды. Однако, приятно, когда все «под рукой» и «рядом» 😊

Не Golang'ом единым... Встречайте: Youki (яп. 容器 - контейнер). Новый container runtime, написанный на Rust! "Rust один из лучших языков для реализации oci-runtime спецификаций. Много крутых контейнерных тулзов написано на Go. Однако, container runtime используют SYSCALL'ы, которые не так то легко реализовать на Go (например namespaces(7) и fork(2). На Rust это сделать гораздо проще!" По заверениям авторов, Youki потенциально быстрее и использует меньше памяти, чем runc. Поддерживаются: 🍭Containerd 🍭Docker 🍭Podman Решение полностью совместимо с OCI Runtime Spec. Проект уже собрал 5.5к звезд на Github и имеет внушительное количество контрибьютеров. Учитывая активное развитие языка, ожидаем версию Kubernetes на Rust😁

VulnerableCode: база данных по уязвимостям в пакетах Всем привет! VulnerableCode – проект, цель которого агрегировать информацию по CVE в пакетах из различных источников. Основная идеология проекта заключается в том, что подобная информация должна быть открыта для сообщества и удобна для использования. Помимо «традиционной» базы данных от NIST, VulnerableCode агрегирует данные по Rust, npm, ubuntu, openssl и не только (с полным перечнем можно ознакомиться тут). Также проект предоставляет web-интерфейс и REST API, которые можно использовать для автоматизации процесса управления уязвимостями. Кстати, можно посмотреть, что он из себя представляет по ссылке (можно искать как по пакетам через purl, так и по CVE ID). Важно: проект пока находится в стадии доработки и не вся информация может отображаться «полностью». Больше подробностей, как обычно – либо в документации, либо на GitHub Repo проекта.

Автоматическое создание «snapshot» компрометированного контейнера Всем привет! Эфемерность контейнеров, помимо плюсов, не лишена и минусов. Особенно для информационной безопасности и forensics процессов в частности. Иногда хочется покопаться «внутри» и понять, а что же там такого произошло? Однако, контейнера уже давно нет и трудно что-либо сказать. Для решения подобной задачи можно использовать observability решения, которые могут записывать все, что «происходило внутри». А можно соорудить что-то «из подручных средств». Так и поступили Авторы статьи. Команда собрала следующее решение: 🍭 Falco. При помощи него осуществляется идентификация «вредоносных событий» и дается дальнейшая команда по созданию «snapshot’a» контейнера 🍭 OpenFAAS. Функция, которая получает команду от Falco и взаимодействует с CRIU для «сохранения» контейнера 🍭 CRIU (Checkpoint/Restore in Userspace). Как раз тот самый инструмент, который позволяет создать «snapshot» за счет функционала checkpoint Если захочется поэкспериментировать и воссоздать аналогичный сценарий – в статье все для этого есть. Описаны технические ограничения, установка необходимых компонентов, код функции и пример запуска тестового сценария.

ArgoCD Threat Model Всем привет! В приложении можно найти файл (~ 47 страниц), в котором рассматриваются вопросы обеспечения информационной безопасности использования ArgoCD. Рассматриваются такие аспекты как: 🍭 Data. Конфиденциальная информация, характерная для ArgoCD Deployments (Secrets, ConfigMaps, Credentials и т.д.) 🍭 Threats Actors. Рассматриваются как внутренние, так и внешние нарушители, обладающие различными полномочиями 🍭 Threats. В материале приведено порядка 19 угроз. Например, хранение Initial admin password в качестве Kubernetes Secret или Control plane is deployed in non HA Mode Для каждой угрозы доступно небольшое описание и рекомендации по сокращению вероятности ее реализации. В приложении можно найти детализацию по нарушителям – описание их возможностей/мотивации и примеры Attack Trees

Действительно ли Kubernetes лучше работает на "голом железе", чем на виртуальных машинах? Вы когда-нибудь задумывались над тем, насколько сильно виртуализация влияет на производительность? В этой статье автор решил проверить как работает Kubernetes на bare-metal и в виртуальной среде. Сразу скажем: результаты впечатляют! Тестировались такие показатели, как: 🍭Скорость и утилизация CPU 🍭Задержки в оперативной памяти 🍭Количество транзакций в секунду в дисковой подсистеме 🍭Пропускная способность и задержки в сети Тесты показали, что кластер, развернутый на bare-metal: в 2️⃣ раза производительнее в части CPU, более чем в 2️⃣ раза лучше показал себя при работе с дисковой подсистемой в 3️⃣ раза лучше в части работы с оперативной памятью, более чем в 5️⃣(sic!) раз лучше в производительности сети! Конечно, все тесты отчасти синтетические и реальные показатели в продуктовых средах могут отличаться, но в любом случае, если для ваших приложений нужна максимальная производительность, то стоит всерьёз рассмотреть вариант bare-metal инсталляций!

GitHub Actions Goat Всем привет! По ссылке можно ознакомиться с заведомо-уязвимым проектом для эксплуатации уязвимостей в GitHub Actions. На текущий момент можно реализовать такие сценарии, как: 🍭 Компрометация исходного кода и учетных данных 🍭 Изменение исходного кода или артефактов во время сборки 🍭 Отсутствие корректного журналирования CI/CD конвейера 🍭 Использование «долгоживущих» учетных данных 🍭 Применение недоверенных GitHub Actions от 3rd party Для каждого сценария приводится сопроводительная информация, поясняющая проблематику, ссылки на лучшие практики по защите и примеры того, как можно настроить GitHub Actions более правильно и безопасно.

Software Supply Chain: Awesome Всем привет! Герой сегодняшнего поста – Awesome подборка, посвященная тематике защиты цепочек поставки программного обеспечения. Внутри можно найти: 🍭 Материалы от «организаций» (NIST, OWASP, OpenSSF и т.д.) 🍭 Стандарты, frameworks и прочие best practices Угрозы и атаки на цепочки поставки ПО 🍭 SBOM, VEX, KEV 🍭 Отчеты, статьи, podcast 🍭 Ссылки на полезные GitHub Repo и не только Материалов очень много, на любой вкус и цвет. Уверены, что Вы найдете для себя что-то интересное и полезное.

Лучшие коктейли на Highload++ 2023 только в Jet Secret Club! Внутри вас ждут: 🏆квиз с призами 🍹авторские коктейли 🥷разгово
Лучшие коктейли на Highload++ 2023 только в Jet Secret Club! Внутри вас ждут: 🏆квиз с призами 🍹авторские коктейли 🥷разговоры о важном DevSecOps, инфраструктуре, мониторинге и всем, что связано с ИТ Ищите нас рядом с залом №10 - Кейптаун!

Атака на CI/CD через shared runners Всем привет! Во многих рекомендациях по защите CI/CD упоминается о том, что использовать shared runner не самый безопасный способ. Но что тут, казалось бы, плохого? Ответ можно найти в статье, где как раз рассматривается интересующий сценарий: 🍭 Допустим, что есть 2 сотрудника, обладающих доступом к разным проектам: один – стажер, у которого особо нет полномочий, а второй – может делать deploy в production-окружение 🍭 Допустим, что стажер был компрометирован. В случае использования shared runners он может получить доступ, выходящий далеко за пределы его полномочий Возможность реализации подобного сценария Автор реализует с использованием docker-in-docker runner’a, dind (что тоже не является самый лучшей практикой наряду с shell runner). Начинается все с простого примера poisoned pipeline execution, а далее задача усложняется – «побег из dind» с последующим получением конфиденциальной информации и компрометацией host, на котором запускаются runner’ы. Помимо примеров реализации атаки в статье также присутствует информация о том, как сделать так, чтобы этого не произошло. Или, по крайней мере, стало в разы сложнее

Друзья, мы, редакция DevSecOps Talks, рады пригласить вас на доклад нашего эксперта на Highload++! Во вторник, в 11:00, в зале "Рио" Семён Барышников будет рассказывать о нашем переосмыслении VDI и о том, как мы для мероприятия CyberCamp 2023 предоставили доступ в инфраструктуру участникам киберучений. Будет описано много интересных решений, нестандартных подходов как в области инфраструктуры, так и в области безопасности k8s. Тема рассказа: Высоконагруженная VDI из Open Source для платформы киберучений «CyberCamp» в облачном Kubernetes

Повышение привилегий в Kubernetes Всем привет! Статья, в которой рассматриваются несколько способов, описывающих как и за счет чего можно повысить привилегии в кластере Kubernetes. Автор рассматривает следующие возможности: 🍭 Pod Creation. В целом, в этом нет ничего «опасного», если контролируется манифест создаваемого pod’a и гарантируется, что используется «валидный образ». Однако, если это не так, то можно реализовать несколько сценариев по повышению привилегий 🍭 Read Secrets. Бесконтрольный доступ к секретам никогда не бывает хорошей практикой. В любой системе, в том числе и в Kubernetes 🍭 Bind Roles. Назначение большего количества полномочий, чем требуется 🍭 Escalate Existing Roles. Добавление больших прав к существующей роли 🍭 Impersonate. Возможность отправки запросов к kube-apiserver от более привилегированной роли Для каждой из вышеописанной возможности приводятся некоторые сценарии с примерами как этим можно воспользоваться. Минимально-необходимым уровнем защиты от описанных в статье сценариев является корректная настройка ролевой модели Kubernetes и использование Admission Controller с необходимыми политиками контроля

Устройство и логика работы Kubelet Всем привет! Очень часто можно найти статьи, посвященные логике работы Kubernetes и его “control plane” компонентов. Реже встречаются статьи, посвященные тому, как работает Kubelet. Исправляем это недоразумение! В статье описывается архитектура Kubelet, включающая в себя такие компоненты, как: 🍭 Pod Lifecycle Event Generator (PLEG) 🍭 PodWorkers, PodManager 🍭 PodAdmitHandlers 🍭 PluginManager и не только Для каждого ключевого компонента описывается его назначение. В завершении статье Автор делает небольшой анализ исходного кода Kubelet (нет, не по информационной безопасности) на предмет того, что происходит «под капотом» и как указанные выше компоненты работают между собой.

CVE Half-Day Watcher Всем привет! Новый инструмент от Aqua Security, который позволять получать максимально (ну почти) раннюю информацию о наличии CVE в анализируемых проектах (еще до того, как для них официально вышел патч). Работает относительно просто: сопоставляет данные, получаемые из NVD API о недавно опубликованных CVE с их GitHub Reference. Название свое проект получил, т.к. он находится где-то посередине между 0-day (когда maintainer не знает об уязвимости) и 1-day (когда maintainer узнал по уязвимости). Пример того, как это работает и зачем это нужно – можно найти в статье от Aqua, в которой рассматривается timeline истории Log4Shell. На текущий момент проект все еще находится на стадии «proof of concept», но будет развиваться и «обрастать» новым функционалом и возможностями.

Descheduler в Kubernetes Всем привет! Descheduler – полезный механизм, который позволяет реализовать rescheduling запущенных на кластере нагрузок (интересно, почему его не назвали Rescheduler). Это может быть полезно, например, при добавлении узлов кластера, чтобы не ждать перезапуска приложений, а оптимизировать нагрузку на вычислительные ресурсы для уже запущенных нагрузок. В статье Автор описывает основные концепты механизма: 🍭 Назначение, примеры использования, возможности установки 🍭 Архитектура, ключевые компоненты и сущности (Evictor, Strategy) 🍭 Логика работы и то, на основании чего Descheduler принимает решение о том, что нагрузку надо перенести и условия, которые этому предшествуют В завершении статьи Автор приводит небольшой пример: Descheduler настраивается с использованием Strategy RemovePodsHavingTooManyRestarts со значением равным 5. После – запускаем «нестабильный» pod и наблюдаем за работой Descheduler «вживую». Отдельно ознакомиться со всеми доступными Strategy и нюансами их использования можно в документации.

REGO: логические операторы и сообщения Всем привет! Продолжение материалов от SNYK, посвященных использованию REGO (про первую часть мы писали тут). На этот раз Авторы знакомят с такими концептами, как: 🍭 Multiple queries: объединение различных rules для оценки данных 🍭 Настройка и использование значений по умолчанию 🍭 Добавление сообщений к результатам работы правил Вторая часть, как и первая богата на примеры, пояснения и исходный код для самостоятельного повторения (которое также можно реализовать локально или с использованием REGO Playground)

Обход Admission Controller через ephemeral containers Всем привет! В статье Автор предлагает рассмотреть возможный способ обхода Admission Controller (на примере OPA/Gatekeeper) с использованием Ephemeral Containers. Алгоритм весьма простой: 🍭 Создание политик, которые запрещают устанавливать privileged: true для containers и initContainers, создание pod 🍭 Попытки модификации спецификации созданного pod для добавления ephemeralContainer. Безуспешные patch, edit, т.к. большинство спецификации pod является неизменяемым 🍭 Однако, kubectl debug сработает, а при более детальном рассмотрении окажется, что он использует тот же самый patch 🍭 Формирование запроса определенного вида и реализовать его с использованием curl. К pod будет добавлен ephemeralContainer, обладающий флагом privileged: true (при работающих политиках) В чем же разница? Ответ прост – иной api endpoint, который как раз и позволит модифицировать спецификацию контейнера через curl запрос. В завершении статьи Автор рассказывает, что необходимо добавить в политике Gatekeeper, чтобы вышеописанное не получилось.

🧨22-23 ноября в Москве состоится большая конференция про сети и инфру IT Elements 🔎Мы нашли для вас интересные доклады по тематике DevOps от вендоров и представителей крупных компаний: 22.11 🔹DevNetOps. Автоматизация процесса эксплуатации и внедрения сети. Дискуссия 23.11 🔹Open Source Software в больших компаниях — Александр Краснов, технический директор платформы Штурвал, Лаборатория Числитель 🔹Эволюция инструментов автоматизации — Алексей Крылов, DevOps Competence Lead 🔹Deckhouse Kubernetes Platform: надежная инфраструктура Enterprise-уровня для ускорения бизнеса — Аксенов Константин, директор департамента разработки платформы Deckhouse, Флант 🔹Переход к platform engineering для инфраструктурных команд — Карапет Манасян, глава платформы разработки, MOEX Group 🔹Инфраструктурные платформы: взгляд бизнеса. Круглый стол 🔹Сквозь облака: Как инфраструктура становится кодом, а DevOps-платформа мостом к новым горизонтам — Александр Подмосковный, руководитель центра компетенций технологий взаимодействия с клиентом 🔹Infra as a Code: как мечтать, чтобы всё сбылось — Андрей Пономарев, эксперт, МойОфис ✅Участие бесплатное, но надо успеть зарегистрироваться до 20 ноября. Подробная программа, спикеры и регистрация на сайте конференции.