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

Всем привет!

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

🍭 Первая статья рассказывает про namespaces (pid, mnt, utc, ipc, user, net). Что это такое, зачем оно нужно и какое отношение имеет к контейнерной сети.
🍭 Вторая раскрывает тему Pause Container. Если вы не знаете, что это такое и в чем суть его существования – очень рекомендуем прочесть, ответ достаточно интересный. Простой контейнер с одним бинарным файлом.
🍭 Третья уже вплотную подбирается к Kubernetes. Описывается как взаимодействуют компоненты между собой (на одной node, на разных node), что такое cbr0, примеры маршрутизации трафика.

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

CyberCamp 2022!!!

Всем привет!

Материал не совсем по тематике канала (хотя, spoiler: в программе есть отличный доклад Сергея Канибора из Luntry!), но не поделиться им мы не можем!!!

Встречайте, CyberCamp 2022 !!!

Присоединяйтесь 14-16 сентября к онлайн-конференции! Практики по кибербезопасности расскажут, как обнаруживать, расследовать и отражать кибератаки.

Что будет?
🔹20 докладов и мастер-классов от пентестеров, специалистов по мониторингу и расследованию инцидентов из Group-IB, «Лаборатории Касперского», «Инфосистемы Джет», Positive Technologies, Luntry, Синклит и Yandex Cloud
🔹Задания для отработки практических навыков в формате игрового обучения

Забронируйте три дня на полезный контент:
🔹Поиск низко висящих фруктов в ИТ-инфраструктуре
🔹Раскладываем атаки по MITRE
🔹Эффективный харденинг ИТ-инфраструктуры
🔹Типовые сценарии Windows Persistence и их обнаружение
🔹Инструменты пентестеров для BlueTeam
🔹Автоматизация работы с инцидентами
🔹Форензика и криминалистические артефакты
🔹Безопасность АСУ ТП: угрозы, подходы, практики
🔹Обогащение в SIEM: как забирать данные из AD, GeoIP, TI

Регистрация на сайте CyberCamp 2022!

Kubernetes OWASP Top-10: примеры

Привет!

Проект Kubernetes OWASP Top 10 продолжает развиваться. Ранее пустые разделы постепенно наполняются описанием и примерами! Появляются статьи, которые разбирают описанные в нем риски.

Одна из таких статей разбирает первый и самый «популярный» - Insecure Workload Configurations. Автор описывает Security Context и что они могут/для чего они нужны.

Он разбирает не все, лишь самые интересные на его взгляд:
🍭 Privileged
🍭 Действия с Capabilities
🍭 runAsUser/Group
🍭 runAsNonRoot
🍭 readOnlyFileSystem

Приведены примеры, что это и зачем, почему это (не) стоит применять. А если Вы не успели ознакомиться с полной версией Kubernetes OWASP Top 10, то он доступен по ссылке.

Контроль доступа к REST-endpoints в k8s

Всем привет!

Допустим, что есть приложение с опубликованным REST-endpoint в Kubernetes. Как предотвратить несанкционированный доступ к такому Endpoint?
У приложения могут быть собственные механизмы аутентификации. А что, если их нет? Или они по какой-то причине недоступны?

В статье Автор разбирает возможные сценарии решения задачи:
🍭 Ingress, поддерживающий аутентификацию. Один из наиболее частых способов, реализуемый, например, с Nginx Ingress Controller
🍭 Reverse-proxy. Использование sidecar-контейнера, например, с Nginx
🍭 Использование RBAC k8s. Да, можно и так!

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

Security Small Talk

Всем привет!

Вышел новый выпуск Security Small Talk об управлении секретами.
В нём детально объясняется следующее:
• Что такое секреты и в чем отличие «human-to-machine» и «machine-to-machine» секретов
• Управление секретами на всех этапах жизненного цикла
• Как можно защищать секреты, какие практики и средства автоматизации можно использовать

Trivy, Cosign и Kyverno: анализ даты последнего сканирования образа контейнера

Всем привет!

Если соединить Trivy, Cosign и Kyverno, то можно реализовать достаточно интересный сценарий. Его демонстрация с примерами всех настроек приведена в статье. Да, там используется GitHub Actions, но сам подход можно реализовать на любой удобной Вам платформе.

Происходит следующее:
🍭 Образ сканируется при помощи Trivy, в результате получаем отчет по уязвимостям
🍭 Результат сканирования проходит аттестацию при помощи Cosign. Про аттестацию (in-toto attestation) можно прочитать тут и тут. «Спецификация» аттестации, генерируемая Cosign описана тут.
🍭 Создается политика Kyverno, которая может «читать» аттестацию и анализировать ее поля. Например, можно проверить, что со времени последнего сканирования прошло не более X дней.

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

Это только небольшой пример возможностей Kyverno по взаимодействию с Cosign, рекомендуем ознакомиться с документацией, чтобы узнать больше!

Elixir Secure Coding Training

Всем привет!

В repo представлен набор Secure Coding Training, включающий в себя такие разделы как:
🍭 OWASP
🍭 Secure SDLC
🍭 GraphQL, Elixir Security
🍭 Cookie Security
🍭 Security Anti-patterns
🍭 CI/CD Tooling

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

Ephemeral Containers

Всем привет!

По ссылке доступна ознакомительная статья, которая позволит понять, что такое ephemeral containers и зачем они нужны.

Вкратце, ephemeral container – «рыба-прилипала», которая «присоединяется» к целевому контейнеру и позволяет с ним взаимодействовать. Это может быть нужно, например, для debug.

Представим, что у вас есть distroless образ и вы думаете, что есть проблемы с сетевой связностью. Но как проверить? wget, curl – их не будет в таком образе. Как раз вот тут и пригодятся ephemeral containers и это далеко не единственный случай.

Такое возможно благодаря тому, что ephemeral container «разделяет» namespaces (mnt, utc, ipc, user, net и т.д.) с «целевым». Кстати, с pid все несколько иначе.

Детали, команды и их результаты представлены в статье. А в конце – пример использования mirrord с Job или через ephemeral containers.

Securing the Software Supply Chain: Recommended Practices for Developers

Всем привет!

Недавно вышли новые рекомендации от NSA, посвященные безопасности Software Supply Chain.

В 64-х страничном документе разобраны такие темы, как:
🍭 Develop Secure Code
🍭 Verify Third-Party Components
🍭 Harden the Build Environment
🍭 Deliver Code

Документ описывает проблематику для каждого «блока» и рекомендации о том, как сделать лучше и безопаснее. Каждая рекомендация описывается достаточно подробно, но без детальных how-to (все-таки это документ, содержащий общие практики). В целом получилось достаточно интересно, на наш взгляд.

Risk8s Business: Risk Analysis of Kubernetes Clusters

Всем привет!

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

Guide состоит из нескольких разделов:
🍭 Introduction. Обзор Kubernetes, рассуждения на тему «что такое безопасный кластер»
🍭 Understanding Your Environment. Как получить необходимую информацию о кластере для последующей «работы» с ним по ИБ
🍭 Understanding Your Risk. Простенький анализ рисков с учетом всей информации, полученной на предыдущих этапах
🍭 Wrapping Up. Заключение, в котором делается обзор всего пути и ключевые выводы

Есть примеры, инструменты, их использование и много всего интересного. Рекомендуем открывать на PC, потому что с телефона отображение информации или навигация могут быть искажены.

Kubernetes resources under the hood — Part 1

Привет!

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

Автор рассматривает такие вопросы, как:
🍭 Linux namespaces, их назначение и как (для чего) они используются контейнерами
🍭 Можно узнать, сколько pod по умолчанию Kubernetes может разместить на одной node. Да, есть и такое
🍭 Что такое Requests и Limits, как они связаны с cgroups, при чем тут «сompressible» и «incompressible», что такое throttling и от чего он возникает
🍭 Какие есть QoS у Kubernetes и от чего они зависят. И тут есть много своих нюансов. Если кому хочется узнать особенности поведения Guaranteed с использованием целого количества ядер, а не millicores, как обычно, то можно прочитать про Topology Manager

Статья читается просто, дает большее понимание, как и что работает внутри и, как обычно, много-много-много ссылок для более глубокого изучения!

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 можно найти по ссылке.