Run containers as non-root: работает ли?

Всем привет!

Одна из самых базовых рекомендаций, что можно встретить при знакомстве с безопасностью контейнеров и Kubernetes – «не запускайте контейнеры из-под root».

Логично. Но много ли кто реализовал это на самом деле? Именно таким вопросом задаются Greg Castle и Vinayak Goyal в своем докладе. Согласно статистике – нет. Но как быть? Да, можно понять как работает образ, сделать необходимые chown, chmod, настроить права, вписать USER и т.д. Но это затратно по ресурсам, особенно на большом объеме контейнеров.

Как быть в такой ситуации? Команда определила следующий подход:
🍭 Все попытки запуска новых root контейнеров блокируются
🍭 У существующих контейнеров «отнимали» права root
🍭 Те, что остались работать – не требовали вмешательства
🍭 Если контейнер «сломался» - команда обращалась к владельцу для решения проблем

С точки зрения контроля было принято решение анализировать как Dockerfile (при наличии), так и модифицировать манифесты (добавлять runAsUser, runAsGroup, privileged: false и т.д.).

Особенно интересно, что в своем докладе ребята рассказали про сложности, с которыми им пришлось столкнуться. Например, особенности работы fsMount и hostPath, интересное использование supplementalGroups или нюансы, связанные с управлением capabilities.

Завершает рассказ упоминание Linux User Namespaces, которые недавно появились в Kubernetes (1.25, но пока Alpha) и как их (потенциально) можно будет использовать для решения задачи с root. Получился отличный, простой и очень полезный доклад, рекомендуем к просмотру!

Kubernetes Scheduler «на пальцах»

Всем привет!

Статья от learnk8s, посвященная принципам работы Kubernetes Scheduler. Как и все материалы от этих ребят – просто, понятно и крайне информативно.

Допустим мы сделали kubectl apply -f smth, будущий ресурс сохранился в etcd и теперь надо его создать. Кто это делает? Нет, не Scheduler, ControllerManager 😊 То самое состояние pending.

Далее уже Scheduler берется за дело. Определяет на каком узле кластера надо разместить ресурс и записывает эту информацию в etcd.

Самое интересное в том, что происходит при выборе узла:
🍭 Фильтрация узлов. Есть целых 13 predicates, которые использует Kubernetes (например, CheckNodeCondition, PodMatchNodeSelector, CheckNodeDiskPressure и т.д.)
🍭 Scoring. Расстановка приоритетов размещения ресурса среди узлов, прошедших фильтрацию. И тут есть собственные predicates (например, NodeAffinityPriority, TaintTolerationPriority, LeastRequestedPriority)

Помимо этого, в статье приводятся способы влияния на решение Scheduler - те самые Affinity, Taints & Tolerations, NodeSelectors и другие! Весь материал подается с примерами и иллюстрациями для лучшего понимания ☺️ Самое «то» для пятницы!

Определение Request и Limits с Kube-Reqsizer

Всем привет!

Установка параметров Requests и Limits является не только хорошей практикой, но и содержится практически во всех рекомендациях по ИБ. Однако, не всегда может быть понятно какие значения поставить.

Может помочь герой сегодняшнего поста – Kube-Reqsizer. С его помощью можно автоматически управлять параметрами Requests и Limits для нагрузок кластера. Не путать с VPA (Vertical Pod Autoscaler), т.к. есть различия в работе 😊

Kube-Reqsizer представляет из себя controller, обладающий функционалом:
🍭 Определяет количество CPU/RAM, потребляемых pod. Для этого используется metrics-server и API-группа apis/metrics.k8s.io/v1beta1
🍭 Анализирует pod, идентифицирует его «прародителей»
🍭 После этого изменяет параметры Requests и Limits в «прародителе»

Kube-Reqsizer можно минималистично настраивать. Например, (не) разрешить ему увеличивать или уменьшать показатели, ограничивать CPU и RAM, которые он может поставить для pod и не только.

Ранее мы уже писали про управление Requests и Limits и возможные способы автоматизации тут и тут. Все они построены «поверх» VPA 😊

Kubernetes Purple Teaming Lab

Всем привет!

В статье описывается опыт Sumo Logic по созданию лаборатории для тестирования различных практик эксплуатации уязвимостей в средах контейнерной оркестрации и способов их идентификации.

Команда собрала следующий инструментарий:
🍭 Рабочая станция под управлением Linux. Настроенный Auditd и Laurel для сбора телеметрии. В качестве настроек Auditd использовался готовый набор правил
🍭 Minikube – в качестве «подопытного»
🍭 Vectr – для отслеживания Red и Blue активностей

После создания инфраструктуры ребята приступили к тестированию тактик, описанных в MITRE: T1610 – deploy container, T1609 – Container administration command, T1613 - Container and resource discovery, T1496 - Resource hijacking.

Все проведенные активности записывались в Vectr для отслеживания и визуализации. Такой подход еще раз наглядно демонстрирует важность сбора и анализа логов на всех уровнях – инфраструктура, Kubernetes и логи ПО, запущенного на кластере.

P.S. Да, многое вращается «вокруг» Sumo Logic, но вместо него может выступать любая другая система анализа событий.

Nauticus: управление Spaces в Kubernetes

Всем привет!

Все так, ошибки нет 😊 Именно Spaces, а не Namespaces И ими можно управлять при помощи open source утилиты – Nauticus.

Он представляет из себя controller (да-да, в любой непонятной ситуации пишите свой operator 😊), управляющий CR – Space.

Space включает в себя:
🍭 Уникальный namespace
🍭 ResourceQuotas и LimitRanges
🍭 RoleBinding
🍭 NetworkPolicy и не только

Таким образом задача управления разными namespaces значительно упрощается за счет «преднастройки». Например, при создании Space можно указать enableDefaultStrictMode, что ограничит внешний трафик из других namespaces.

Если интересно прочитать про примеры использования Nauticus, то можно обратиться к этой статье.

Software Licenses in Plain English

Всем привет!

Мы все очень тесно связаны с миром Opensource и Свободного ПО, но большинство не сильно вникает в суть лицензирования.

tl;drLegal - Неплохой способ разобраться в сути лицензий, не имея юридического образования 👨🏻‍🎓.

📄 Более 140 лицензий, с описанием и полными текстами, для изучения.

🇬🇧 Понятный язык, без специфичных для Английского права понятий.

🔍 Поиск по названию и тегам, описывающих суть лицензии.

А если хотите выбрать лицензию для своего проекта - это один из понятных способов разобраться!🧑🏼‍💻

Vim для DevOps

Всем привет!
Многие инженеры пользуюся VSCode для работы. А если сервер доступен только по ssh и файлы хочется редактировать прямо на нем? Или же рабочая станция не самая новая?
Использовать редактор Vim конечно же! Ведь он есть под все современный платформы, даже для Winodws Такое мы не одобряем 😊, а конфиг - везде одинковый, что повышает портируемость. И да, в большинстве случаев он уже установлен в вашей системе.

Функциональность Vim можно расширять бесконечно. Существует множество модулей и плагинов, которые не просто дают новые возможности, а превращают его в полноценную IDE.

Вот минимальный набор, который будет полезно иметь:

🍭 NERDTree - Позволяет удобно выбирать файлы для редактирования в боковом меню

🍭 nerdtree-git-plugin - Позволяет просматривать статус файлов и строк с системах контроля версий на основе git.

🍭 coc.vim - Conquer of Completion. Плагин для расширений, на базе Nodejs. Поддерживаются языковые сервера для большинства языков программирования и разметки, но нас интересует Bash, Python, Golang, JSON, YAML, Markdown, ASCIIDoc и даже для Dockerfile!
В случае YAML, так же можно включить поддержку синтаксиса ресурсов kubernetes. В итоге вы получите автодополнение!

🍭 vim-terraform - Позволит управлять Terraform не выходя из редактора

🍭 markdown-preview - Дает возможность предпросмотра для Markdown файлов, что очень удобно для написания документации. Мы же все любим это делать, да?😊

А если вам нужно что-то, что не указано здесь - на сайте VimAwesome собран огромный список плагинов с их описанием и возможностью поиска и сортировки. Ведь Vim - конструктор, который каждый собирает под себя👨‍🏭

Infrastructure as Code: риски и способы защиты

Привет!

По ссылке доступна обзорная статья, посвященная вопросам защиты при использовании Infrastructure as Code подхода к управлению ИТ-инфраструктурой.

Сперва Автор рассматривает наиболее «популярные» риски: Misconfiguration, Unauthorized access, Outdated dependencies, Malicious code injections, Inadequate audit and monitoring, Cloud resources we forgot to turn off.

Далее для каждого из рисков приводится верхнеуровневое описание того, как его можно идентифицировать. В том числе с использованием различных утилит. Например, checkov, tfsec, OPA и т.д.

Статья минималистичная, но дающая общий взгляд на вопросы ИБ Infrastructure as Code и подойдет «для начала».

P.S. В самой статье есть много отсылок на другие интересные материалы по теме.

Software Supply Chain Security вместе с GUAC

Всем привет!

В конце мая 2023 года Google выпустила проект GUAC в beta! GUAC – Graph for Understanding Artifact Composition – инструмент, позволяющий анализировать open source на наличие уязвимостей.

Нет, это не еще один «генератор SBOM». Скорее наоборот. GUAC агрегирует информацию из различных источников и соединяет ее «воедино». Это позволяет обогатить информацию из SBOM добавив в нее данные от SLSA, SSF ScoreCard и т.д.

«Под капотом» находится следующий состав сервисов:
🍭 GraphQL Server. Сервис, позволяющий делать запросы к полученной структуре данных
🍭 Collector. Сервис, отвечающий за сбор информации
🍭 Ingestor. Сервис, который занимается разбором структур данных в формат GUAC. Поддерживается разбор SPDX, CycloneDX и SLSA
Assembler. Получает данные от Ingestor и создает записи в БД

Подробнее с GUAC можно познакомиться в документации. Например, можно прочитать про сценарии использования и структуру данных GUAC.

Bytesafe: proxy для пакетных индексов

Всем привет!

На самом деле не совсем так. Bytesafe – решение, которое комбинирует функции firewall для зависимостей и возможности средства композиционного анализа (SCA).

Оно платное, но у него есть community-версия. Ограничений несколько – отсутствуют dashboard’ы, функционал SCA, а количество пакетных индексов (интеграций) ограничивается числом 10.

Работает следующим образом:
🍭 «Подключается» registry. На текущий момент поддерживается: npm, Maven, Nuget и PyPi
🍭 Настраивается конфигурация registry. Например, чтобы запрос шел на Bytesafe, а не к «оригинальному источнику»
🍭 Настраиваются правила. Например, можно разрешить только определенные пакеты, пакеты без уязвимостей выше определенного уровня, запрет на обновление из downstream registries и т.д.

Поставляется это все в виде контейнеров. Есть compose, есть инструкции по установке на k8s. Из-за ограничений это вряд ли подойдет средним и крупным компаниям. Но, быть может, будет интересно хотя бы ознакомиться с функционалом. А если нужны подробности, то можно обратиться к документации.

Kubesec: анализ рисков ИБ для ресурсов k8s

Всем привет!

Kubesec позволяет анализировать ресурсы k8s на соответствие требованиям лучших практик. Да, может показаться, что это «еще один» Kyverno или Gatekeeper. Только не такой «мощный».

В целом так и есть. Не является Admission Controller’ом, а просто анализирует манифесты. Может быть удобно для локального тестирования, когда хочется быстро проанализировать подготовленную конфигурацию на соответствие основным требованиям по ИБ. Кроме того, можно запустить как http-сервер, к которому можно обращаться за анализом.

На текущий момент Kubesec содержит порядка 20 контролей, среди которых:
🍭 Наличие linux capability SYS_ADMIN
Privileged контейнеры
🍭 Отсутствие контроля CPU/RAM
🍭 Наличие hostPID, IPC, Network и другие

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

CI/CD Security

Всем привет!

По ссылке доступна большая статья (27 минут, если верить описанию), посвященная вопросам безопасности CI/CD Security.

Сперва Автор разбирает OWASP Top 10 CI/CD Security Risks, попутно описывая «почему это плохо» и «как это было проэксплуатировано» (примеры есть не везде).

Далее рассматриваются техники защиты – все, начиная от использования сканеров (SCA, SAST и т.д.) до безопасной настройкой самого конвейера и периодического аудита.

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

State of API Security

Всем привет!

В приложении доступен отчет от Salt Labs, посвященный вопросам информационной безопасности API.
Материал небольшой (~ 22 страницы), но весьма емкий.

Внутри можно найти:
🍭 Наиболее часто встречающиеся атаки на API
🍭 ИБ-проблемы, связанные с API
🍭 Использование средств защиты и их эффективность
🍭 Документирование API и его особенности

В завершение отчета можно найти примеры случаев из жизни (found in the wild), в которых описаны проблемы безопасности API. И, как обычно, на последней странице ссылки на полезные материалы по теме.

API Security: Awesome

Всем привет!

В продолжение темы вчерашнего поста, предлагаем ознакомиться с API Security Awesome – подборкой материалов с ресурсами по тематике.

Внутри можно найти:
🍭 Книги
🍭 Всевозможные cheatsheets
🍭 Наборы требований/проверок (checklist)
🍭 Заведомо уязвимые приложения с небезопасным API
🍭 Перечень средств автоматизации и многое другое

Подборка включает в себя как бесплатные / open source ресурсы, так и платные материалы. Точно можно подобрать то, что можно начать изучать в ближайшие выходные 😊

A developer’s guide to supply chain security

Всем привет!
В приложении материал от Red Hat, посвященный software supply chain security. Авторы старались подойти к вопросу с точки зрения разработчиков. Поэтому в первой части документа много информации о том, «почему это надо делать».

Помимо этого, внутри можно найти рекомендации:
🍭 Управление доверенными образами контейнеров и библиотеками
🍭 Защита registry, контроль размещения в нем компонентов
🍭 Защита исходного кода
🍭 Усиление защиты сборочного конвейера и не только

Материал небольшой (~ 21 страница), но содержит неплохой обзор практик обеспечения безопасности software supply chain и может быть использован совместно с материалами SLSA и CNCF.

Parlay: SBOM Enrichment

Всем привет!

Еще один интересный проект от Snyk – Parlay. Его задача заключается в том, что добавить (обогатить) в Software Bill Of Materials (SBOM) как можно больше информации.

Для «обогащения» используются такие ресурсы, как ecosyste.ms, Snyk и OpenSSF Scorecard. Работает крайне просто – даем SBOM «на вход» и «на выходе» получаем расширенную версию.

Например, можно добавить информацию о Supplier, Licenses, ссылки на внешние ресурсы, имеющие отношение к рассматриваемому компоненту.

Если интересует информация от OpenSSF, то на текущий момент Parlay позволяет добавить только саму ссылку, без ее «содержания». С другой стороны, это уже неплохо – при помощи ссылки и Scorecard API можно получить желаемые данные.

Посмотреть проект можно по ссылке на GitHub.

PASSWORD STORE

Pass - консольный парольный менеджер, который следует философии Unix и предоставляет возможность хранения паролей в виде обычных файлов, зашифрованных c помощью GPG.

Из плюсов хочется отметить:
🍭 Портируемость - Имеется поддержка большинства современных браузеров, ОС и мобильных платформ. Так же присутствует несколько графических утилит.
🍭 Легковесность - В установленном виде программа занимает чуть более 46 килобайт.
🍭 Простота установки - Вам всего лишь нужно сгенерировать пару ключей используя утилиту GNUPG и инициализировать password store.
🍭 Свобода - исходные коды проекта распространяются под лицензией GNU GPLv2+.

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

Так же, Pass можно использовать для хранения секретов в CI фреймворке Buildbot.

Kubernetes Operator: Step by Step Guide

Всем привет!

В статье приведена детальная пошаговая инструкция о том, как создать собственный Kubernetes Operator с использованием Operator SDK. Задача создаваемого оператора простая – он будет хранить информацию о pod, которые не пересоздавались/обновлялись в течение заданного времени.

Статья начинается с краткого описания того, что такое Operator и зачем он нужен, что он делает и из каких «компонентов» состоит.

Дальше – интересней:
🍭 Перечень необходимых «зависимостей» (начиная от Golang и заканчивая «подопытным» кластером k8s)
🍭 Инициализация проекта с Operator SDK
Создание Custom Controller
🍭 Написание логики ключевого процесса Operator’a – реконсиляции
🍭 Сборка созданного Operator и его тестирование

Статья и правда step by step. Каждый шаг описывается Автором, приводится листинг (частичный) кода, который может быть полезен при самостоятельном воспроизведении материала. А для наглядности есть схема, в которой описан процесс работы Operator’a.

Repo Jacking

Всем привет!

В статье описывается принципы работы одной из software supply chain attack – Repo Jacking. Эта атака может привести к значительным последствиям.

При этом реализуется она относительно просто:
🍭 Допустим, что в коде есть зависимость на https://github.com/username/project
🍭 Представим, что username был изменен владельцем. Пока что все нормально
🍭 Но! Освободившийся username можно зарегистрировать «еще раз» и создать такой же «project», но уже с нужным вам содержанием.
В этом случае зависимость, указанная в коде, будет ссылаться не на исходный проект, а на созданный потенциальным злоумышленником.

Помимо описания самой атаки в статье можно найти информацию об условиях, когда она может быть реализована, а также результаты анализа GitHub Repo, потенциально уязвимых к Repo Jacking.

Кстати, подход к идентификации уязвимых Repo доступно описан в статье и весьма интересен -от сбора данных, до поиска unregistered user names!

Что делать и как быть? Все это можно найти внутри 😊 (не использовать прямые ссылки, делать version pinning и использовать lock files, скачивать зависимости и использовать их локально (vendoring)).

P.S. Сама статья от 2020 года. Если интересно что изменилось с тех пор – можно обратиться к этому материалу от 2023.

Callisto: binary analysis

Всем привет!

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

В своей работе Автор объединил следующее:
🍭 Декомпиляция binary файла с использованием Ghidra
🍭 Анализ полученных результатов – Semgrep
🍭 Валидация результатов при помощи GPT-3.5-Turbo

Пример того, как работает Callisto можно найти в repo проекта. Так же там присутствует информация о необходимых prerequisites для запуска утилиты и ключах, которые можно использовать.