Kubernetes resources under the hood — Part 2

Всем привет!

Вторая часть серии посвящена Requests и их роли в жизненном цикле pod, которая заключается не только в scheduling.

Прочитав ее, можно узнать:
🍭 Сколько CPU Shares запрашивает Kubernetes, основываясь на данных, указанных пользователем в Requests
🍭 Completely Fair Scheduler (CFS) Linux – распределение CPU requests между процессами, как он работает и зачем нужен
🍭 Влияние threads и QoS на предоставление ресурсов CPU

Просто, наглядно и с примерами!

Kubernetes resources under the hood — Part 3

Всем привет!

Третья часть серии начинается достаточно провокационно – Don’t set your CPU limits! Это сильно противоречит большинству рекомендаций по ИБ (и не только) по корректному написанию манифестов (наличие CPU/RAM requests и limits).

Далее начинается нечто! Автор обосновывает свою точку зрения с учетом:
🍭 Информации из предыдущих статей, особенно с использованием CPU Shares
🍭 Чуть больше раскрывается тема throttling, разница поведений контейнеров при использовании single/multi threading
🍭 Математики (да, ее много для статьи не про нее)
🍭 Рассуждений о том, что будет если 1 контейнер будет сильно потреблять ресурсы – пострадает только он или все его «соседи» по node?
🍭 Эксперимент с последовательным запуском двух pods, значения CPU requests/limits которых (не)устанавливаются в разные «положения» и что при этом происходит с учетом тех QoS, которые они получают от Kubernetes.

И все-таки? Нужны ли CPU Limits? Мнение Автора и примеры их (не)использования в реальном мире можно узнать в разделе «When to use CPU Limits» в конце статьи.

False positive/negative при сканировании образов контейнеров

Всем привет!

Одна из самых частых практик, про которую точно слышали все – сканирование образов контейнеров на наличие уязвимостей. Есть большое количество инструментов (как open source, так и enterprise), которые решают эту задачу. Они развиваются, функционал расширяется, например, создание Software Bill of Materials (SBOM) для образа контейнера. Но все ли они видят? И как обстоят дела с наличием ошибок первого и второго рода?

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

Почему это так?
🍭 Большинство сканеров работают с базой данных пакетных менеджеров (apt, yum, apk и т.д.) и видят только то, что установлено с их использованием
🍭 У некоторых сканеров (например, Snyk) есть «собственные проприетарные практики» обнаружения, например, Node.js, который обычно ставится «напрямую», а не через пакетный менеджер

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

Что делать? Авторы статьи предлагают перенести созданием SBOM на момент сборки и, по возможности, использовать distroless подход с использованием melange и apko (о которых мы писали тут).

Sidecar(less) mTLS от Cilium

Всем привет!

Многие ИБ-специалисты хотят, думают использовать, используют (?) mTLS для повышения безопасности сред контейнерной оркестрации.

Одним из самых популярных подходов является использование sidecar-паттерна, который реализует необходимый функционал. Однако, такой подход может быть избыточным и ребята из Cilium представили свой подход к mTLS, в котором не требуется дополнительных контейнеров.

В статье этот вопрос рассматривается более детально:
🍭 Общее описание того, что такое mTLS и зачем он нужен
🍭 Разница между session based и network based mutual authentication
🍭 Плюсы и минусы описанных выше подходов

Далее поднимается вопрос о том, можно ли совместить 2 подхода (session/network based) и как этого можно достигнуть при помощи Cilium Service Mesh. И, конечно же, тесты на производительность! Куда же без них! Если верить текущим прогнозам, то функционал mutual authentication будет доступен в Cilium v1.13 (текущая версия – 1.12).

Визуализация JSON

Всем привет!

JSON – один из самых часто встречаемых машиночитаемых форматов. В таком формате, например, можно получать результаты работы open source инструментов, обеспечивающих анализ программного обеспечения или защиту сред контейнерных испытаний.

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

Но сперва надо понять, как он «устроен». Это не то, чтобы сложно, но иногда хочется простой визуализации, а не просто «красивой» формы, которые могут давать jq, Notepad++, VSCode и другие системы.

Если Вы согласны, то рекомендуем обратить внимание на проект JSONCrack, которые позволяет построить наглядную диаграмму из JSON-файла. И все это в минималистично-необходимом UI.

JSONCrack доступен как online, так и в качестве контейнеров, которые можно запустить on-premise.

Kubernetes CVE feed

Всем привет!

Небольшая, но интересная новость. У Kubernetes, как и у любого другого программного обеспечения есть уязвимости.

Особенность заключалась в том, что трудно было отслеживать (программно) эти уязвимости из-за отсутствия единого источника.

Команда решила это поправить и запустила «Auto-refreshing Official Kubernetes CVE Feed». Feed будет содержать актуальную информацию по уязвимостям, которую можно извлечь в формате JSON для дальнейшей работы.

Например, можно воспользоваться командой:

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json

Больше про feed и то, что сейчас находится внутри можно посмотреть по ссылке. Приятно, что для каждой CVE указывается ссылка на GitHub Issue и можно посмотреть как (не)идут дела.

Использование Repository Webhook для доступа к CI

Всем привет!

Если задуматься, то Repository Webhook – VIP-персоны, ввиду тех задач, для которых они используются. Сделали commit, хочется, чтобы сборка начиналась автоматически? Webhook! А значит, что они проходят «сквозь», например, межсетевые экраны и иные ограничения ИБ.

А можно ли это как-то использовать для получения доступа к CI? Именно на этот вопрос и попытались ответить Авторы статьи. В целом, все достаточно неплохо – GET-запросы к CI не очень-то и поддерживаются, а при POST-запросах отсутствует возможность контроля тела запроса, да еще и CSRF-токен формируется. Но…

Авторы статьи сделали следующее:
🍭 Создали свой repo и «настроили» webhook на CI-жертву - Jenkins
🍭Подобрали пароли для учетной записи Jenkins с использованием POST-запроса на страницу аутентификации и анализом возвращаемого ответа. Кстати, чтобы этот и дальнейшие опыты сработали был использован GitLab, ввиду его особенности (какой именно - описано в статье)
🍭 Получили доступ к job console output
🍭 Создали reverse-shell для Jenkins instance через эксплуатацию уязвимости платформы (в статье есть отдельное видео, где можно посмотреть пример «в деле»)

Да, для реализации примеров необходимы «входные» данные, например, существующие и актуальные учетные записи, но… это все равно достаточно интересное исследование на наш взгляд, реализуемое через очень своеобразный вектор.

Объяснение sidecar pattern на примере Istio

Всем привет!

По ссылке можно найти подробную статью, в которой объясняется принцип работы sidecar pattern на примере известного Service Mesh – Istio.

Затрагиваются такие темы как:
🍭 Описание sidecar pattern, плюсы такого подхода
🍭 Манипуляции с iptables через sidecar
🍭 Детально разбираются Istio rules с описание того зачем они нужны и что делают
🍭 Рассматриваются вопросы traffic routing (inbound/outbound) и не только

В статье много схем, примеров, диаграмм и описания того, как и что работает. Рекомендуем к изучению!

P.S. Единственное чего не хватает в статье – недостатков sidecar pattern. Об этом можно почитать тут, заодно посмотреть на разные подходы к управлению трафиком в среде контейнерной оркестрации и о достаточно интересной идее Cilium.

Управление доступом к Kubernetes с помощью Paralus

Всем привет!

Paralus – open source решение, которое позволяет управлять доступом к кластерам Kubernetes. «Поставляется» с CLI, UI и API.

При помощи решения можно:
🍭 Управлять правами доступа к кластеру «на лету» с использованием «штатных ролей». Ролевую модель можно расширять
🍭 Объединять пользователей в группы и более гранулярно настраивать права доступа (включая права на конкретные namespace)
🍭 Настраивать SSO с использованием OIDC (решение протестировали с GitHub, GitLab и не только)
🍭 Собирать информацию о «системных изменениях» (кто и что делал в Paralus) и сведения о командах kubectl (например, %username% делал запрос на get secrets)

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

Использование ChaosMesh на примерах

Привет!

В блоге Flant есть отличная статья (и не только эта), посвященная использованию ChaosMesh! Если кто не в курсе, ChaosMesh – инструмент для воссоздания практик Chaos Engineering. Практик, при которых все может (и должно) пойти не так: «отвалился» доступ Клиентов к приложению, «упал» продуктовый сервер, изменилась конфигурация %чего-либо% в промышленном окружении…

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

И, конечно же, самое интересное! Тесты:
🍭 Допустим, перезагрузка node. Почему бы и нет
🍭 Отказы в работе PostgreSQL и RabbitMQ. Можно и такое! Притом разными способами
🍭 Тестирование сети! Да! Задержки, потери пакетов…

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

P.S. Это не первая статья Flant по теме ChaosMesh. Небольшое сравнение open source решений для chaos engineering можно найти по ссылке.

CTF от Snyk!

Всем привет!

Snyk анонсировали свой новый CTF, зарегистрироваться на который можно бесплатно. Само мероприятие пройдет 9-ого ноября. Можно участвовать самостоятельно, но лучше собрать команду до 5-и человек. Время проведения: с 16:00 до 22:00 (по Мск).

Что будет на CTF:
🍭 16 challenges (pwn, web, crypto, forensics)
🍭 Призы (не очень понятно какие, но какая разница! 😊)
🍭 Атмосфера (обычно мероприятия Snyk очень продуманны и интересны)

Если Вы никогда не участвовали в CTF, но очень хочется попробовать, то Snyk организовывает CTF 101 Workshop, который пройдет 2-ого ноября.

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

A Guide to Improving Security Through Infrastructure-as-Code

Всем привет!

По ссылке доступна большая обзорная статья, посвященная обеспечению ИБ при/с использованием подхода *-as-Code.

Статья содержит следующие разделы:
🍭 Что такое Infrastructure-as-Code (IaC)
🍭 Моделирование угроз (STRIDE, MITRE, CIS, материалы производителей средств защиты)
🍭 Управление доступом
🍭 Интеграция проверок в CI/CD (средства анализа конфигураций – Checkov, tfsec, KICS и другие)
🍭 Policy-as-Code (OPA, куда же без нее 😊)
🍭 Управление конфигурациями (средства конфигурирования и проверки реализованных конфигураций)
🍭 Мониторинг и контроль configuration drift
🍭 Зрелость IaC, уровни и их описание

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

Semgrep Supply Chain

Всем привет!

Have you ever gotten a "critical vulnerability in dependency" alert and when you look at it, it's something like “XML parser vulnerability in some buried transitive library that you actually use for parsing JSON and therefore aren’t affected by at all?”

Думаем, что это случалось и случалось не один раз. Одна из проблем анализа уязвимых open source компонентов – насколько они и правда уязвимы в конкретном ПО?

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

Именно для решения этой задачи – «is it reachable?» - и был придуман Semgrep Supply Chain, который позволит расставить приоритеты и подсветить, что реально важно.

На текущий момент поддерживаются следующие языки: (GA) Go, JavaScript/TypeScript, Python, and Ruby, (Beta) Java.

Единственным «недостатком» является то, что решение платное. Однако, чтобы опробовать его «в деле» можно попробовать получить 100 дней trial-использования (но это не точно).

Управление доступом к k8s с использованием Teleport

Привет!

Хорошая обзорная статья, посвященная Teleport и возможности его использования для предоставления доступа разработчикам к кластерам k8s через интеграцию с GitHub. Вполне подойдет, если вы хотите познакомиться с инструментом.

Первая часть статьи посвящена общим вопросам:
🍭 Что такое Teleport, что есть identity-based control
🍭 Возможности Teleport по анализу действий, совершаемых в кластере
🍭 Способы предоставления безопасного доступа, существующие интеграции

Вторая часть – демо! С большим количеством примера, настроек и конфигурации:
🍭 Установка Teleport, создание первого пользователя
🍭 Настройка GitHub SSO
🍭 Настройка доступа пользователя к кластеру k8s
🍭 Просмотр действий, совершенных в кластере пользователем

В целом получился отличный how-to-guide для знакомства с решением. Конечно, больше информации о возможностях Teleport и не только можно получить из документации.

HashiCorp Developer

Всем привет!

Материалы HashiCorp можно назвать одними из лучших. Много документации, видео-уроков, tutorials и лабораторных работ.

И они продолжают радовать и делать материалы удобнее и доступнее для community. В июне 2022 года был запущен (beta) сайт HashiCorp Developer.

Он собрал в себе все необходимые материалы по продуктам HashiCorp:
🍭 Vault
🍭 Terraform
🍭 Nomad
🍭 Vagrant и другие

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

Сравнение Semgrep и CodeQL

Всем привет!

По ссылке можно найти достаточно объемное сравнение популярных инструментов анализа исходного кода для идентификации ИБ-дефектов – Semgrep и CodeQL.

Рассматривались такие критерии сравнения, как:
🍭 Поддержка языков программирования
🍭 «Глубина» анализа, работа lexer/parser
🍭 Pre/post опции сканирования (исключения, фильтрация, отключение проверок и т.д.)
🍭 Правила
🍭 Управление ИБ-дефектами («собственные» возможности, интеграции с ticketing systems и т.д.)
🍭 Время сканирования

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

PCI Compliance for Kubernetes in detail: Part 2 - Authorization

Всем привет!

Обзорная статья от Rory McCune, посвященная анализу требований PCI Compliance for Kubernetes и Authorization в частности.

Рассматриваются:
🍭 Принцип минимальных привилегий
🍭 Корректное использование групп
🍭 Контроль предоставления доступа, проведение периодических аудитов выданных прав

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

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

P.S. С общими рассуждениями Rory про PCI Compliance for Kubernetes и про первую его часть, Authentication, можно познакомиться тут и тут соответственно.

Аутентификация в Kubernetes: основы

Всем привет!

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

В Kubernetes все несколько иначе и выполнение требования «в лоб» может породить больше вопросов, чем ответов.

Чтобы со всем разобраться и понять, что же происходит «под капотом» рекомендуем ознакомиться со статьей, в которой на базовом примере curl https://api-server-address:6443/api/v1/namespaces объясняется что к чему:
🍭 Кто может делать запросы к api-server
🍭 Какие способы аутентификации доступны и что реализовано «из коробки»
🍭 Можно ли изменять «стратегии» аутентификации
🍭 Разрешено ли одновременно использовать несколько способов аутентификации в одном кластере

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

Dependency Confusion

Всем привет!

Dependency Confusion – одна из «популярных» уязвимостей 2021 года. Суть ее достаточно проста. Допустим есть локальная библиотека «libone» версии 1, которая разработана в Компании N. Злоумышленник может сделать свою версию библиотеки с таким же наименованием и разместить ее в публичном репозитории. А версию указать выше, чем у той библиотеки, что есть в локальном репозитории Компании N. Возможны сценарии, когда сборщик будет использовать более старшую версию, а значит ту, что создал злоумышленник.

Для проведения PoC реализации Dependency Confusion ребята из Doyensec создали Confuser – утилиту, которая автоматизирует часть этапов (на примере npm).

Работает она по следующему сценарию:
🍭 Поиск пакетов, которых нет в публичных репозиториях
🍭 Создание payload используя особенности npm и install hooks
🍭 Передача информации обратно в сторону злоумышленника - callbacks

С подробностями, включая сложности поиска и особенности эксплуатации Dependency Confusion, можно ознакомиться в статье (рекомендуем к прочтению), а сам Confuser доступен вот тут.

Если до сих пор не верится, что такое встречается в «реальном мире» - можно прочесть статью «Researcher hacks over 35 tech firms in novel supply chain attack». В ней описано, как Alex Birsan заработал $130,000 на bug-bounty программах, эксплуатируя эту самую уязвимость.

P.S. Напоминаем про то, что это лучше не повторять. Статья исключительно для образовательных целей и лучшего понимания того, как и что может произойти

Kubectl-Ice

Всем привет!

Kubectl-ice – plugin для kubectl, которые может быть полезен для получения информации о контейнерах и поиска ошибок.

Он может:
🍭 Показывает все контейнеры в namespace («обычные», init, ephemeral)
🍭 Может показать перечень всех образов контейнеров, которые используются в namespace
🍭 Отобразить информацию по всем SecurityContext и POSIX cabapilities
🍭 Информацию об используемых ресурсах контейнерами
🍭 Сведения о mount, которые используются контейнерами и не только

Доступна фильтрация данных и отображение в различных форматах. В repo можно найти небольшой demo-ролик, в котором наглядно показано, как можно использовать kubectl-ice.

Trivy vs Trivy-Operator

Всем привет!

На первый взгляд может показаться, что Trivy и Trivy-Operator это одно и тоже. Разница лишь в том, что Trivy-Operator запускается в качестве operator’a в кластере, а Trivy работает локально. Но это не совсем так.

В статье приводится основная разница между этими решениями. Если кратко, то Trivy-Operator использует Trivy в качестве сканера. При большом желании можно «подключить» свой сканер, для этого надо реализовать несколько интерфейсов.

Так в чем же разница?
🍭 Trivy передает результат в терминал, можно делать выгрузку в различных форматах, в т.ч. json. Результаты работы Trivy-Operator представляют из себя Custom Resources Kubernetes
🍭 Разный объем результатов, что отчасти связано с ограничением по умолчанию на запись в etcd в размере 1,5 MB.
🍭 Trivy запускается локально (на рабочей станции, в CI/CD). Trivy-Operator «устанавливается» на кластер и анализирует сущности по мере их создания и на периодической основе.

Таким образом, можно сказать, что Trivy более удобный инструмент для анализа в моменте разработки, а Trivy-Operator – на момент эксплуатации.