Разбор Kubernetes Security Context

Всем привет!

По ссылке доступен long read, в котором Автор на примерах разбирает различные Security Context и пользу от их использования. Для демонстрации заготовлено минималистичное flask-приложение и его различные модификации.

Рассматривается:
🍭 runAsUser / runAsGroup // пример с SSRF
🍭 privileged и allowPrivelegeEscalation // пример с SUID и возможным повышением привилегий
🍭 readOnlyRootFilesystem // пример с созданием файла внутри контейнера
🍭 drop capabilities // пример с drop: ALL и bind на 80-ый порт (Сработало! Почему? Ответ есть в статье) и последующей настройкой исключений
🍭 apparmor // пример с попыткой чтения /etc/passwd

Автор максимально детально описывает все действия, которые он реализует, а также описывает «зачем» он это делает. Примеры из статьи можно реализовать самостоятельно – все исходные коды, ссылки на используемые материалы и дополнительные ресурсы присутствуют.

P.S. Для некоторых Security Context Автор приводит дополнительные комментарии, которые не всегда просто найти / есть в официальной документации.

Проблематика и автоматизация создания Network Policy

Всем привет!

Зачастую рассказывают про положительные стороны чего-либо. Однако, знать про отрицательные тоже важно, чтобы получить полную и общую картину.

В статье Автор рассуждает о том, почему Network Policy не самый удобный инструмент / уровень абстракции для сегментирования сети k8s, особенно с точки зрения разработчика.

Критикуешь – предлагай! Да, есть и такое! В завершение статьи описывается как можно проще/лучше управлять трафиком с использованием Intents (определение есть в статье). И не только описание – не найдя ничего подходящего, ребята создали свой собственный operator - Otterize Intents Operator.

Он «повышает» уровень абстракции и позволяет контролировать создание/наличие сетевых политик. Грубо говоря, все, что надо указать – с кем «общается» целевой сервис и как. Все. Operator создаст необходимую политику (только Ingress) и проставит требуемые labels на участников взаимодействия.

Подробнее про Otterize Intents Operator можно прочесть в документации. Важно (!): есть как коммерческая, так и open source версия продукта.

Vulnhub: Vulnerable Docker Environments

Всем привет!

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

Проект Vulnhub может в этом помочь. В нем собрано большое количество «заранее уязвимых» окружений для различных технологий (python, wordpress, elasticsearch, flask, java и многое другое).

Для каждого окружения в repo можно найти CVE, которые в них «заложены» и readme.md, описывающий как можно ее проэксплуатировать. Есть небольшой нюанс – английский язык доступен не везде, много информации на китайском ☺️

Важно(!): указанные окружения не рекомендуется использовать в production, а лишь для целей тестирования и изучения.

Ресторан «Kubernetes»

Привет!

Легкий пятничный пост 😊 Наверное, когда-нибудь вас просили объяснить – «Что такое Kubernetes? Но только просто, чтобы было понятно и сразу!»
Было уже много разных аналогий и вот еще одна. Автор сравнивает k8s с рестораном! Как раз для пятницы!

Получается следующее:
🍭 Master Node: главный повар, управляет всем
🍭 Kube-apiserver: система обработки заказов посетителей ресторана
🍭 Kube-controller-manager: управляющий по кухне
🍭 Kube-scheduler: временное табло, помогающее кухне справляться с заказами и т.д.

В целом все неплохо «ложится» на Kubernetes 😊 А как Вы «просто и понятно» объясняете, что такое Kubernetes интересующимся?

Безопасность build pipeline: все ли так плохо?

Всем привет!

По ссылке доступна статья, в которой Автор пытается посмотреть на проблему безопасности build-pipelines максимально критично. Ее задача понять – все ли на самом деле так плохо? Или проэксплуатировать уязвимость сложнее, чем написано во многих статьях?

В качестве возможных сценариев рассматриваются:
🍭 Модификация исходного кода
🍭 «Добавление» зависимостей
🍭 Воздействие на runner

Для каждого сценария описаны «сложности», с которыми скорее всего придется столкнуться атакующими. С точки зрения Автора все не так уж и плохо, особенно если соблюдать «гигиену» - защищать ветки (branch protection), проверять подпись «внешних» компонентов и т.д. А что Вы думаете по этому поводу?

Kube-apiserver в роли port scanner

Всем привет!

Еще одна потрясающая статья от Rory McCune, посвященная «своеобразному» использованию возможностей Kubernetes. Нет, это не уязвимость, это не bug, это не ошибка.

Kubernetes устроен таким образом, что он может осуществлять сетевые запросы на внешние адреса в некоторых ситуациях. Например, в случае с Validating Webhooks. Таким образом можно реализовать некий аналог SSRF и превратить Kubernetes в «сканер портов».

Rory проделал следующее:
🍭 Создается namespace
🍭 Регистрируется webhook. Никакой сервер, обрабатывающий запрос не регистрируется. Вместо этого указывается потенциальная «жертва»
🍭 Создается pod в указанном namespace. Готово! В сообщении об ошибки получаем всю необходимую информацию

PoC того, что описано выше можно найти в repo. Если интересно посмотреть небольшую демонстрацию, ее можно найти в блоге Rory.

P.S. Лучше не проверять этот, пусть и крайне базовый PoC на каких-либо настоящих сервисах и/или в production-окружениях.

Network isolation для 1,500 сервисов

Всем привет!

В статье описан опыт Monzo по управлению сетевым трафиком в средах контейнерной оркестрации. На очень больших масштабах.

Ребята проделали колоссальную работу, которую можно разделить на несколько основных этапов:
🍭 Выбор сервиса для «пилотирования». Им стал service.ledger, который взаимодействует с множеством других
🍭 Понимание того, с кем service.ledger общается. Для этого команда написала собственный инструмент – rpcmap, который анализирует Go-код и пытается найти возможные точки взаимодействия. Работало не очень, но в качестве «первых шагов» - вполне
🍭 Подготовка Native Network Policy, определение подходов к labeling. Политика хранилась вместе с конфигурацией ledger и, если необходимо добавить новый «приемник», то делался соответствующий MR
🍭 Трудности, порождаемые таким подходом. Отсутствие тестирование, нюансы с roll back и т.д. Поиск нового решения, которым стал Calico
🍭 Создание сетевых политик Calico, обладающих большим order для журналирования действий Network Policy для поиска ошибок. Дада, Вам не показалось 😊 Анализ Network Policy при помощи другой Network Policy
🍭 Очередное переосмысление labeling с учетом опыта, полученного на предыдущих шагах

И многое-многое-многое! Читается на одном дыхании, рекомендуем! 😊

Выбор компонентов платформы контейнерной оркестрации.

Всем привет!

Ни для кого не секрет что любая платформа контейнерной оркестрации состоит из множества компонентов, таких как:
🍉 Подсистема мониторинга
🍉 Подсистема журналирования
🍉 Подсистема аутентификации/авторизации
🍉 и множество других компонентов

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

🍉 Выбор подсистемы оповещений и алертов
🍉 Особенности проектирования cli-утилиты для управления кластером
🍉 Подходы к тестированию платформы
🍉 Разбор разных методов хранения конфигураций
🍉 и многое другое

Network Mapper: кто с кем общается в k8s

Всем привет!

Продолжаем тему анализа сетевого трафика k8s и упрощения создания сетевых политик для его контроля.

Не всегда понятно какой сервис с каким общается, что затрудняет создание (и автоматизацию этого процесса) сетевых политик. Для решения этой задачи можно обратить внимание на Otterize Network Mapper.

Решение работает по следующей схеме: записывает DNS-трафик, анализирует активные соединения, получает IP-адреса и идентифицирует «источник».

Чтобы попробовать Network Mapper в действии достаточно:
🍭 Установить сам Network Mapper (есть Helm Chart)
🍭 Установить cli-утилиту для общения с «основной системой»
🍭 Готово! Можно получить информацию о том какие сервисы общаются между собой как в stdout, так и в JSON для дальнейшей работы

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

Авторизация Kubelet в Kube-apiserver

Всем привет!

Kubelet крайне важная часть Kubernetes. Он взаимодействует с runtime для создания контейнеров и не только, общается с kube-apiserver. Логично предположить, что он, как и все остальные сущности, обращающиеся к kube-apiserver должен проходить процедуру авторизации.

И это так, однако не все так просто, как может показаться. Например, если сделать kubectl --kubeconfig=%yourkubelet.conf% auth can-i –list, то описания его прав на, например, pod вы не увидите. Хотя с этим же самым kubeconfig можно запросить перечень pods в каком-нибудь namespace и получить результат.

Если присмотреться, то в ответе вышеуказанной команды есть интересная строчка: the list may be incomplete: node authorizer does not support user rule resolution Resources.

Именно этой «особенности» посвящена очередная прекрасная статья от Rory McCune. Почему так происходит и как работает авторизация Kubelet «под капотом», ссылки на исходный код Kubernetes - все есть в статье. Рекомендуем!

Kubernetes Goat: новый сценарий

Всем привет!

Kubernetes Goat – проект Madhu Akula, который представляет из себя заведомо-уязвимый кластер Kubernetes.

Сейчас доступно порядка 20 сценариев, которые можно реализовать. Например:
🍭 Attacking private registries
🍭 Secure Network Boundaries using Network Policy
🍭 Kubernetes namespaces bypass и другие

Недавно был добавлен еще один – «Cilium Tetragon - eBPF-based Security Observability and Runtime Enforcement». В нем предлагается использовать Tetragon для осуществления runtime security monitoring и идентификации проблем ИБ. Как и во всех остальных сценариях доступна постановка задачи, подсказки (hints) или полное решение (если вдруг не получится самостоятельно).

Chainloop: supply chain control plane

Всем привет!

Chainloop – open source проект, при помощи которого можно централизованно управлять аттестацией артефактов (про то, что понимается под «аттестацией» мы писали тут).

Логически состоит из двух основных компонентов – contract (описывает то, что должно быть в аттестации) и attestation (грубо говоря набор сведений об артефакте, которые нам требуются). Аттестация используется для того, чтобы подписать не только сам артефакт, но и дополнительную информацию про него.

Пример того, что можно добавить в аттестацию:
🍭 Образ контейнера
🍭 Dockerfile (optional)
🍭 SHA commit’a
🍭 Software Bill Of Materials in CycloneDX format и не только

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

Больше информации про Chainloop (установка, настройка, интеграционные возможности) можно прочесть в документации на проект.

CyberCamp MeetUp: DevSecOps!!!

Всем привет!

По ссылке Вы можете зарегистрироваться на MeetUp, посвященный DevSecOps!

Мероприятие пройдет 20 апреля c 11:00 МСК.

Программа получилась очень насыщенной:

🍭 Путь самурая: фреймворк безопасной разработки
Кирилл Бочкарев, "Инфосистемы Джет"

🍭 Мифы и факты о цепочке поставки программного обеспечения
Леша Смирнов, CodeScoring

🍭 Актуальные уязвимости в мобильных приложениях в 2022 году
Юра Шабалин, "Стингрей Технолоджиз"

🍭 Введение во взлом веб-приложений. Как создать безопасное ПО
Данил Кокорин, "Инфосистемы Джет"

🍭 Классификация и систематизация средств безопасности для Kubernetes
Дима Евдокимов, Luntry

🍭 Опыт построения AppSec-процессов в крупных корпорациях
Алина Князева, VK

Приходите сами, зовите друзей! Скучно точно не будет!!! ☺️☺️☺️

БеКон: вкусно и полезно!

Всем привет!

При чем тут бекон? Быть может это отличный завтрак DevOps-специалиста, а быть может – первая в России конференция, посвященная тематике БЕзопасности сред КОНтейнерной оркестрации!

И то и то правда (ставьте «лайк», если любите кушать бекон 😊)! Команда Luntry сделала собственную конференцию, где будет 10 докладов.

Уже объявлены такие темы как:
🍭 OPA с shared Docker executor // Павел Сорокин, OZON
🍭 Не такой очевидный RBAC Kubernetes // Дмитрий Евдокимов, Luntry
🍭 Distroless своими руками // Антон Мокин, Тинькофф
🍭 K8s в PCI DSS // Александр Маркелов, Райффайзен Банк
🍭 Как правильно готовить Kyverno и работать с его алертами // Алексей Миртов, Яндекс Облако
🍭 Kubernetes, ответь мне, кто я для тебя // Константин Аксенов, Флант

Остальные доклады будут объявлены в ближайшем будущем. Мероприятие пройдет 7-ого июня, в Москве. Важно(!): только offline и без трансляции.

Deps: API

Всем привет!

Deps.dev – проект от Google, который представляет из себя feed, содержащий информацию об уязвимостях пакетов языков программирования (Rust, Go, Java, Python, Node.js).

Недавно стало доступно API, которое позволит автоматизировать взаимодействие с сервисом.
Можно получить следующую информацию о пакетах, зависимостях, advisory и не только. Сервис «возвращает» большое количество информации, которое может быть полезно в рамках процесса управления уязвимостями.

Описание API можно найти в документации, а примеры использования (запрос через hash, получение dependency graph, анализ лицензий) доступны в repo.

Secure Software Factory

Всем привет!

В приложении доступен whitepaper от CNCF, посвященный созданию Secure Software Factory (SSF). Материал небольшой (~ 22 страницы), однако, описывает интересные концепты.

Внутри можно найти:
🍭 Концептуальная схема SSF
🍭 Описание ключевых (core) компонентов SSF
🍭 Краткое описание участников взаимодействия (люди, технологии)
🍭 Перечень того, на что стоит обратить внимание на разных этапах жизненного цикла ПО
🍭 Немного best practice в завершении

Кстати, в самом начале документа можно найти отсылку к еще одному документу CNCF, посвященному Supply Chain Security. Его мы приложим в следующем посте.

Software Supply Chain Best Practices

Тот самый материал от CNCF (~ 45 страниц). Содержит набор практик и рекомендаций для повышения безопасности Software Supply Chain.

Материал «разбит» на части:
🍭 Securing Source Code
🍭 Securing Materials
🍭 Securing Build Pipelines
🍭 Securing Artifacts
🍭 Securing Deployments

Для каждого раздела приводится набор рекомендаций, разбитый на группы: Verification, Automation, Authorization in Controlled Environments и Secure Authentication.

Написание правил для CodeQL и Semgrep

Привет!

CodeQL и Semgrep – пожалуй самые популярные и мощные open source инструменты, которые используются для анализа исходного кода.

В статье Автор рассматривает эти инструменты: принципы их работы, преимущества и недостатки.

Например:
🍭 Написание правил (простота, потребность в дополнительных знаниях)
🍭 Поддержка разных видов анализа (рассматриваются oss/paid версии каждого из продуктов)
🍭 Рассуждения на тему различий Abstract Syntax Tree, Data Flow Graph, Control Flow Graph и как они влияют на возможности анализатора, простоту «расширения» поддерживаемых языков
🍭 Расширения для IDE и их возможности
Помощь в написании правил (полнота документации, наличие playgrounds, материалов по теме)

Статья не является исчерпывающей, но может помочь сформировать первое впечатление об инструментах. Это может быть полезно, если Вы стоите перед выбором – «А с чего лучше начать?»

CodeQL: From zero to hero, Part 1

Всем привет!

Немного обманчивая статья 😊 В ней, по крайней мере в первой ее части, разбирается не сам CodeQL, а основы статического анализа. Какие способы бывают, чем они отличаются, для чего используются и почему всеми любимого grep не хватает.

Статья погружает читателя в тематику постепенно:
🍭 Описание общей задачи поиска уязвимостей в исходном коде
🍭 Идентификация sources и sinks (что это – описано в статье 😊)
🍭 Lexical analysis и зачем он используется
🍭 Syntactic pattern matching, abstract syntax tree и control flow graph
Data flow analysis и taint tracking

Автор отлично описывает разные способы анализа, зачем они нужны, их плюсы и минусы. Материала достаточно много, есть примеры, самое «то» для начала!

Прочитав статью можно сделать еще один вывод. Анализ кода строится на понимании механик и того, что происходит при работе ПО. Слепо полагаться на автоматизацию, которая «сама все найдет» не стоит, она лишь сможет помочь. Да и то, если ей объяснят, что надо делать. Однако, без автоматизации тоже плохо – ведь анализировать код «глазами» задача выполнимая, но крайне ресурсоемкая.
Важно помнить, что результаты, получаемые при таком подходе, скорее всего будут не актуальны. За время, потраченное на такой анализ приложение уже успеет «измениться».

P.S. В завершении статьи можно найти несколько challenges.

Certified GitOps Associate (CGOA)

Всем привет!

KubeCon идет во всю, о самых интересных докладах по ИБ (на наш взгляд) напишем позже. А пока – новая сертификация от CNCF: Certified GitOps Associate (CGOA).

Увы, пока в статусе «coming soon», но уже известно «что внутри»:
🍭 GitOps Terminology (20%)
🍭 GitOps Principles (30%)
🍭 Related Practices (16%)
🍭 GitOps Patterns (20%)
🍭 Tooling (14%)

Тест на 90 минут, который, судя по описанию, подойдет всем DevOps инженерам. Уровень знаний: beginner.