SR-IOV Network metrics exporter

Если вдруг так сложилось, что вы используете K8s на bare-metal, да и еще в полной мере пользуетесь функциональностью SR-IOV на сетевых картах, то возникает вопрос, как же все мониторить?

Kubernetes Network Plumbing Working Group, разработчики SR-IOV Network Operator и Multus MetaCNI недавно выложили в сеть экспортер метрик, позволяющий полноценно снимать метрики с VF интерфейсов.

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

https://github.com/k8snetworkplumbingwg/sriov-network-metrics-exporter

Приглашаем вас 18 июля в 16:00 присоединиться к online-митапу наших партнеров: Зачем «Марлин» повстречал «Штурвал»?

Две российские компании-разработчики — «Лаборатория Числитель» и «Высокие цифровые технологии» — решили объединить усилия и представить на рынок надежное решение для ускорения процесса разработки приложений и сокращения Time to Market для бизнеса.

📈 Платформенное решение «Марлин», построенное на микросервисной архитектуре, позволяет снизить стоимость разработки на 40%, структурировать и автоматизировать все необходимые процессы, высвобождая ресурсы разработчика непосредственно для написания кода. А контейнерная платформа «Штурвал» выступает в роли надежного звена по управлению контейнерами, обеспечивая высокий уровень доступности и информационной безопасности.

🔗 В связке «Марлин» и «Штурвал» — это решение, готовое выполнить задачи быстрой и безопасной разработки и эксплуатации контейнеризированных приложений на всем жизненном цикле. Поэтому на мероприятии спикеры продемонстрируют «Марлин» и «Штурвал» в действии и на примере реальной производственной задачи в компании ВСК.

На online Meetup поговорят:
▪️ о безопасной разработке и эксплуатации приложений средствами «Марлин» и «Штурвал»;
▪️ бесшовной миграции без потери функционала;
▪️ стандартах деплоя, готовом конвейере разработки;
▪️ совместной поддержке решения.

✅ Регистрация

Krossboard: k8s resource usage analysis

Всем привет!

Krossboard – средство аналитики и визуализации, которое позволяет получать информации о потреблении ресурсов множеством кластеров Kubernetes централизованно.

При помощи решения можно:
🍭 Сбор данных с кластеров. Информация о container, pod, node с каждого кластера собирается раз в 5 минут
🍭 Аналитика. Удобные dashboards, которые предоставляют информацию о потреблении ресурсов по namespace, cluster и globally
🍭 Отчетность. Krossboard обладает REST API, при помощи которого можно скачивать отчеты в CSV или JSON

Устанавливается и настраивается очень просто. Правда, в качестве Secret ему необходим Kubeconfig для доступа к целевым кластерам. Инструкцию о том, как сделать Kubeconfig с минимальными правами и перечень этих самых прав можно найти в repo проекта.

Webhook: проверка электронной подписи

Всем привет!

Webhook – интеграционный механизм, который повсеместно используется в разработке и DevSecOps. Это удобно, просто и быстро.

Но как убедиться в том, что данные пришли от доверенного источника? Что никто не пытается его «взломать», например, передав не те данные. Ответ – электронная подпись.

В статье Авторы от SNYK проводят простую демонстрацию:
🍭 Создают небольшой webhook-receiver на базе Node.js
🍭 Направляют запрос при помощи Postman. Контроля подписи нет, запрос выполняется
🍭 Настраивают webhook в GitHub
🍭 Изменяют логику работы приложения, добавляя анализ электронной подписи webhook
🍭 Повторяют аналогичный тест. На этот раз выполняется только «разрешенный» запрос, для всех остальных – 401

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

Arbitrary Code Execution в R/O filesystems

Всем привет!

Рекомендацию по использованию readOnlyRootFileSystem: true можно встретить практически во всех рекомендациях и лучшим ИБ-практиках по защите контейнеров. Но достаточно ли ее для того, чтобы полностью избежать манипуляций с файловой системой контейнера?

Размышления на эту тему можно найти в статье. Автор рассматривает 3 сценария:
🍭 Nginx и использование /dev/tcp
🍭 Alpine и использование возможностей «встроенного» busybox (wget)
🍭 Alpine и использование dynamic linker/loader libraries

В каждом из сценариев Автору удалось добавить файлы в файловую систему и установить reverse shell. При этом контейнеры запускались с readOnlyRootFileSystem: true и из-под непривилегированных пользователей.

Примеры реализации (команды, код, детализация подходов), а также меры для идентификации подобных сценариев можно найти в самой статье.

PyLoose: fileless-атака с Python

Всем привет!

Команда Wiz идентифицировала новое вредоносное ПО, которое получило название PyLoose. Оно позволяет запустить crypto miner в оперативной памяти с использованием memfd.

Для эксплуатации необходим Jupyter Notebook, возможность запуска Python-скриптов с доступом к системным командам (os, subprocess). Жертве передается нужный noscript, происходит его запуск и установка XMrig miner.

Примечательно, что noscript состоит всего из 9(!) строк кода на Python. «Построчный разбор», подробности атаки (включая условия «успешности»), а также способы ее идентификации можно найти в статье от Wiz.

SNYK Top 10

Всем привет!

В приложении доступен отчет по OWASP Top 10 по 10 наиболее распространенным уязвимостям по версии SNYK для языков: JavaScript, Java, Python, Go, PHP, Ruby, and C#.

Отчет формировался на основании данных, анализируемых специалистами компании и представляет их видение происходящего.

Список получился таким:
🍭 Denial of Service
🍭 Remote Code Execution
🍭 Deserealization of Untrusted Data
🍭 SQL Injection
🍭 Prototype Pollution
🍭 Insecure Temporary File
🍭 Directory/Path Traversal
🍭 Privilege Escalation
🍭 Regular Expression Denial of Service
🍭 NULL Pointer Dereference

Помимо информации об уязвимостях в отчете можно найти ссылки на cheatsheet по языкам и полезные материалы по теме.

Labeling в Kubernetes

Всем привет!

Простой пост понедельника, посвященный Labels. Механизм повсеместно используется в Kubernetes. При этом есть как «системные» Labels (нужны для работы Kubernetes), так и «пользовательские» (упрощают понимание контекста).

В статье приведены рекомендации о том, как именно их стоит указывать. За основу взят материал из официальной документации k8s, который рекомендует указывать:
🍭 Name
🍭 Instance
🍭 Version
🍭 Component
🍭 Part-of
🍭 Managed-by

Рассматриваются примеры реализации, в том числе на базе существующих и популярных решений мира контейнеризации. Помимо этого, можно найти рекомендации об использовании Labels в multitenant-инсталляциях.

Нюансы проверки подписи в Kubernetes

Всем привет!

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

Но все ли так просто, неужели нет «подводных камней»? Ответ можно найти в статье от Chainguard, в которой Автор описывает несколько нюансов, связанных с проверкой подписи.

В их число входят:
🍭 Resource Type. Важно учитывать, что «местоположение» контейнера в манифесте будет разным, например, для Pod, Deployment или CronJob
🍭 Scale. Потенциальный rate limit для container registries, связанный с большим количеством запросов при проверке подписи, важность использования cache
🍭 Tags and digest. Особенности, связанные с «конвертацией» tag – digest
🍭 Attestations and additional data. Больше данных – больше проверок, что может увеличить время анализа и быть заметно на масштабе
🍭 Key Rotation. Управление ключами, используемыми для подписи образов

Все очень структурированно и доступно описано. Что делать с описанными выше нюансами? У Chainguard есть мнение и на этот счет! В завершении статьи можно найти ссылку на их проект – Chainguard Enforce (увы, не open source).

25 Methods for Pipeline Attacks

Всем привет!

В статье собраны примеры того, как можно что-то «получить» или сделать «плохо» при неправильной конфигурации pipeline.

Например:
🍭 Добавление unauthorized user в качестве approver
🍭 Извлечение секретов и переменных окружения
🍭 Изменение конфигурационных файлов приложения и другие

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

CodeQL: From zero to hero, Part 2

Всем привет!

Вторая статья серии, посвященной CodeQL (о первой мы писали тут). На этот раз речь пройдет не про общие концепты статического анализа, а непосредственно про сам CodeQL.

Статья содержит информацию:
🍭 Общий принцип работы CodeQL
🍭 «Первое сканирование» с использованием GitHub Actions
🍭 База данных CodeQL: создание, переиспользование
🍭 Написание собственных CodeQL Query: основы, Predicates, Classes и т.д.

В статье очень много примеров, каждый из которых разбирается практически «line-by-line» и отлично помогает разобраться в основах CodeQL. Однозначно рекомендуем к прочтению, как и первую статью серии! ☺️

Самая бесполезная docker-команда

Всем привет!

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

Собственно, вот она:

docker run -ti 
    --privileged 
    --net=host --pid=host --ipc=host 
    --volume /:/host 
    busybox 
    chroot /host

А почему? А потому что можно! А зачем? Кто его знает 😊

P.S. Хотя, бывают случаи, что это и правда нужно для debug в определенных условиях (например, в Fedora CoreOS). Но и тут есть специализированные инструменты, о которых мы писали ранее

Semgrep Assistant

Всем привет!

Наверное, каждый задумывался о том, чем ему могут быть полезны нейронные сети. ИБ-специалисты не исключение. Возможно, вы задавались вопросами: «А может ли сеть анализировать результаты на наличие false-positive? Делать triage?» или нечто другое.

Команда Semgrep не исключение. Последние месяцы они проводили тестирование Semgrep Assistant. Его задача – помогать идентифицировать false-positive и писать правила для анализа.

Каков результат? По мнению команды тестирования – с анализом false-positive "полет нормальный" и им вполне можно пользоваться. А вот с написанием правил ситуация иная – он сможет помочь в написании базовых правил, сложные пока ему не даются.

Подробнее про путь Команды и про дальнейшие планы можно прочесть в статье. Есть еще одна хорошая новость! Сейчас Assistant доступен всем желающим (для GitHub) и можно «включить» эту опцию, если захотите попробовать самостоятельно.

GitLab: Hardening

Всем привет!

В статье приводится минималистичный перечень рекомендаций, который позволяет повысить уровень безопасности GitLab.

В нем указаны:
🍭 Реализовать многофакторную аутентификацию
🍭Настроить дополнительные sign-up checks
🍭Ограничить видимость проектов и групп
🍭 Реализовать hardening SSH
🍭 Настроить ограничения (лимиты) для учетных записей
🍭 Обезопасить секреты в CI
🍭 Настроить защиту веток для CI

«Хм, очевидно же!» - можете подумать вы. Все так! Но самое интересное в завершении статьи. Ссылка на официальную документацию GitLab, где можно найти расширенный перечень рекомендаций по безопасности GitLab и материалы по его hardening.

Kraken: P2P Docker Registry

Всем привет!

Герой сегодняшнего поста – Kraken – разработка Uber, которая представляет из себя P2P Docker Registry. Во главу угла поставлена масштабируемость и доступность.

Концептуально представляет из себя набор хостов, которые являются seeder’ами, агенты, которые устанавливаются на узлы кластера и набор дополнительных компонентов, которые управляют работой всей сети.

Может подойди, если у вас в инфраструктуре есть большое количество узлов и потребность в распространении образов. В repo можно найти benchmark, в которого указано время загрузки 3G Docker image на 2600 узлов, при этом загрузка осуществлялась параллельно.

Подробнее прочитать про Kraken и его возможности можно в документации из repo проекта.

State of Open Source Security

Всем привет!

В приложении можно найти легкое пятничное чтиво. Отчет, посвященный open source от Snyk.

Внутри можно найти:
🍭 Статистику по сканирования приложений
🍭 Данные об использовании средств защиты цепочки поставки ПО
🍭 Способы проверки open source компонентов
🍭 Сведения о том, как часто Компании сталкиваются с проблемами при использовании open source и не только

Отчет небольшой (~ 19 страниц), много инфографики и выводов.

Устройство сети Kubernetes

Всем привет!

Весьма объемная статья (~ 36 минут), в которой очень детально описано устройство сети Kubernetes. Начиная с простого создания pod sandbox, создания правил маршрутизации при помощи kube-proxy и разрешения имен с использованием CoreDNS, Автор все глубже погружает читателя в то, что происходит «под капотом».

А что может быть лучше для таких целей, чем самим побыть в роли Kubernetes и реализовать то, что он реализует самостоятельно (ну почти)? Ни-че-го!

Автор реализует следующие шаги:
🍭 Создание сетевых пространств имен Client и Server
🍭 Настройка сетевой связности между этими пространствами имен с использованием bridge
🍭 Реализация аналогичных активностей, но теперь Client и Server находятся на разных хостах. Использованием eth0
🍭 После этого Автор возвращается к сущностям Kubernetes и объясняет устройство сети уже с их использованием

И, что самое классное – все команды есть в статье! А также много-много-много схем, которые позволяют улучшить понимание того, что происходит.

Testing Handbook

Всем привет!

Команда Trail Of Bits (если кто не знает, то именно эта контора делала один из аудитов ИБ Kubernetes, в 2019) анонсировала Testing Handbook!

Со слов Авторов, это «shortest path for developers and security professionals to derive maximum value from the static and dynamic analysis tools». Материал создан на основе опыта Trail Of Bits, полученного при анализе проектов.

Пока что доступна только первая глава, посвященная Semgrep. В ней можно найти:
🍭 Установка и первые шаги
🍭 Advanced usage
🍭 Интеграция в CI
🍭 Ссылки на дополнительные ресурсы

Надеемся, что ребята не забросят этот проект и Handbook будет только наполняться информацией. А мы, в свою очередь, будем держать вас в курсе ☺️

Supply Chain Security для Golang

Всем привет!

По ссылкам доступен набор статей от Google, посвященный безопасности supply chain при использовании Golang.

В них рассматривается:
🍭 Управление уязвимостями в Golang. Использование OSV и govulncheck, который не только идентифицирует уязвимости в используемых компонентах, но и показывает «что реально используется»
🍭 Существующие атаки на зависимости и что Golang может предложить. Например, Go Checksum Database, в которой содержится информация о SHA-256 hash для всех публично доступных Golang модулей, что позволяет контролировать целостность
🍭 Shift Left (куда без него 😊). VS Code Extensions и FUZZ тестирование

В статьях много интересных ссылок на дополнительные источники информации. А все упомянутые проекты – open source, можно брать и смотреть!