Всем привет!

Моделирование угроз в Kubernetes задачка не самая простая, но точно интересная!

В статье ребята рассуждает на тему того, что может пригодиться при ее решении:
🍭 Методика – в качестве нее авторы выбрали известный STRIDE
🍭 Средство автоматизации – Threat Modeler от Microsoft, MS TM (к которому ребята сделали template с «Kubernetes-тематикой»)
🍭 Пример – можно посмотреть наработки для KubeArmor. Примеры для KubeArmor и template для MS TM расположены в repo

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

Всем пятница!

Еще одна REGO-библиотека с правилами для анализа сущностей, запускаемых в среде контейнерной оркестрации.

Еще одна, да не совсем! Ребята из ARMO проделали отличную работу и сделали mapping проверок на MITRE ATT&CK. Практически по всем доменам доступны проверки:
🍭 Initial access
🍭 Execution
🍭 Persistence
🍭 Privilege Escalation
🍭 Defense Evasion
🍭 Credential Access
🍭 Discovery
🍭 Lateral Movement
🍭 Collection
🍭 Impact

Получился достаточно интересный материал ☺️

P.S. Желаем всем отличного вечера пятницы, теплых выходных и не болейте!

Всем привет!

По ссылке доступен базовый tutorial, описывающий установку ArgoCD и ключевые возможности этой системы.

Сперва рассматривается установка ArgoCD и создание первого “Application”: приводятся примеры manifest с кратким описанием наиболее важных параметров.

Далее на небольшом примере рассматриваются ключевые возможности ArgoCD:
🍭 Synchronize с GitHub (можно использовать не только GitHub, просто он приводится в самой статье)
🍭 Изменение manifest приложения, App Diff который покажет, что именно было изменено
🍭 Различные параметры настройки политики синхронизации ArgoCD (sync policy)
🍭 Механизмы History и Rollback

Все это с наглядными примерами, исходным кодом и screenshots итоговых результатов, которые должны получиться 😊

Привет!

Одно из определений Observability заключается в измерении того, насколько хорошо работает система путем анализа ее (системы) выходных данных. Это подводит к нескольким вопросам: Какие именно данные надо собирать? При помощи чего это можно делать?

В статье автор размышляет на тему 3-х основных «столпов», которые можно и нужно исследовать: Metrics, Traces и Logs.

Для примера он использует Prometheus, который, de facto, является стандартом мониторинга сред контейнерной оркестрации.

В статье рассматриваются такие моменты как:
🍭 Общий взгляд на Prometheus и его компоненты, как установить (helm-чарты, операторы и т.д.)
🍭 Получение первичных данных (например, аналитика kube-state-metrics)
🍭 Сбор метрик с использованием Client и Exporters
🍭 Использование PromQL (Prometheus Query Language) для создание собственных запросов

В качестве «подопытного» для рассмотрения описанных выше концептов, используется небольшое приложение, состоящее из 3-х блоков: People Service («забирает» данные из MySQL базы данных), Format Service (обработка данных, полученных от People Service) и Hello Service (предоставление отформатированных данных пользователю).

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

Привет!

Подборка инструментов по анализу исходного кода (SAST), сгруппированная по языкам программирования.

В подборке есть:
🍭 Open Source инструменты
🍭 Enterprise-решения, отмеченные символом ©️

Перечень языков, для которых приведены инструменты анализа достаточно большой: С, С++, С#, DART, Go, Java, JavaScript, PHP, Python и многие другие.

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

Рекомендуем прочитать обозначения в repo. Они показывают Enterprise-версии (о чем писали выше); решения, НЕ рекомендованные community и решения, которые не обновлялись длительное время.

Всем привет!

Представьте что вам необходимо произвести настройку нескольких тысяч единиц оборудования!
Как это сделать? 🤔
На помощь приходит функционал Zero Touch Provisioning
В статье расшифровывается понятие Zero Touch Provisioning и какие преимущества это даёт.
Вкратце:

🍉 Автоматическое разворачивание ПО с типовой конфигурацией на удалённом оборудовании с применением GitOps-практик
🍉 Обновление конфигурации в 2 клика
🍉 Шаблонизация параметров
🍉 Централизованное управление

Всех с пятницей!

Продолжение статьи про Observeability! В предыдущий раз Автор закончил на том, что подготовил Prometheus и начал собирать метрики.

Тема второй статьи – Alerts и их обработка. Задачу, условно, можно разделить на два блока:
🍭 Написание Alert Rules, определяющих, когда необходимо «подать сигнал»
🍭 Настройка Alert Manager, который определяет, что делать с Alert и за то, куда его можно направить

Далее описывается как создать свое собственное правило и про правила, доступные «из коробки» при установке Prometheus. Рассматриваются примеры настройки Alert Manager для группировки аналогичных Alert (чтобы, не «DDoS-ить» команду поддержки) и самое интересное – интеграция со Slack для быстрого и удобного получения уведомлений!

Все материалы, которые использовал Автор, можно найти в repo.

P.S. Всем хорошего отдыха! Не болейте! ☺️

Всем привет!

Ребята из Apiiro Security Research Team обнаружили уязвимость CVE-2022-24348 в ArgoCD. Эксплуатация уязвимости позволяет злоумышленнику получить доступ к чувствительной информации, такой как секреты, пароли и API-ключи.

Attack Flow состоит из нескольких этапов:
🍭 Злоумышленник подготавливает malicious Helm chart
🍭 Через использование parsing confusion уязвимости получает доступ к чувствительной информации. Эта уязвимость связана с особенностями разбора (parsing) Values-файлов
🍭 Извлекает необходимые ему данные, которые он может использовать для последующих атак

Для реализации подобной атаки необходимо обладать правами на создание и/или обновление Applications в ArgoCD.

Чтобы понять, подвержена ли ваша инсталляция этой уязвимости можно использовать, например Kubescape.

Устранение уязвимости осуществляется путем установки обновления, доступного для версий 2.3.0, 2.2.4, 2.1.9.

Всем привет!

Небольшое демо по использованию Cosign – инструмента генерации и проверки электронной подписи для образов контейнеров.

Подобные практики можно использовать для противодействия supply chain атакам – гарантировать, что запускаются только доверенные и подписанные образы.

Демо описывает следующий процесс:
🍭 Установка Cosign
🍭 Генерация ключевой пары – закрытый и открытый ключи
🍭 Подпись образа с использованием закрытого ключа
🍭 Помещение образа вместе с подписью в Container Registry
🍭 Использование открытого ключа для верификации подписи образа

Помимо указанного в демо приводится пример подписи Software Bill of Materials (SBOM). Сама SBOM генерируется при помощи Syft (о нем мы писали ранее) и подписывается при помощи Cosign.

Привет!

Сайт, посвященный RBAC Kubernetes. Все удобно сгруппировано по разделам:
🍭 Официальная документация Kubernetes
🍭 Статьи, посвященные RBAC
🍭 Средства автоматизации

В части автоматизации есть интересное деление – можно выбрать утилиты для проведения аудита настроек RBAC кластера (KubiScan, Krane). Другие утилиты позволяют упростить взаимодействие с Kubernetes для получения информации о возможностях учетных записей и ролей (kubectl-who-can, rakkess). Задача третьих – визуализировать управление доступом (rback-view, rbac).

P.S. А вы знали, что при помощи RBAC можно тренировать дельфинов? ☺️

P.P.S. Preview не работает, поэтому дублируем ссылку: https://rbac.dev/

Привет!

Очень-очень большая статья, посвященная теме управления секретами (~21 минута, если верить Medium). Да, она 2018 года, но все равно многое из того, что в ней написано актуально и по сей день.

В начале статьи приводится проблематика, с которой можно столкнуться: как для «классического ИТ», так и для Cloud и DevOps-окружений.

Отдельно хочется выделить часть статьи, в которой описано с какими сложностями столкнулись компании (Pinterest, Square) и почему они решили разработать собственные инструменты (Knox, Keywhiz).

Далее идет обзор-перечисление open source решений, которые могут быть использованы: Torus, Credstash, Sneaker и другие.

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

Всем привет!

Небольшая статья о том, как Citi сделали Secure Software Factory. В качестве основы они выбрали «Software Supply Chain Best Practices» и «The Secure Software Factory». Оба документа содержат интересные мысли по теме и там есть, что почитать (каждый ~ 20 страниц).

В итоге получился следующий конструктор:
🍭 Подпись с использованием Sigstore Cosign
🍭 Автоматизация Pipeline: Tekton – Pipelines и Chains
🍭 Admission Controller – Kyverno
🍭 Identity Attestation – Spire
🍭 Оркестрация контейнеров – Kubernetes

С деталями и Quick Start Guide можно ознакомиться по ссылке ☺️

Всем привет!

Linux Capabilities – не самая простая, но очень интересная тема. Можно даже немного почувствовать себя исследователем и разобраться какому процессу/файлу какие привилегии (полномочия) нужны.

В цикле статей Автор простыми словами рассказывает про то, что это такое: первая часть теоретическая, а вторая – практическая (много примеров, в том числе про то, как читать и понимать вывод утилит, помогающих идентифицировать capabilities).

В статьях Автор рассматривает такие аспекты, как:
🍭 Типы capabilities: effective, inherited, permit, ambient и bounding; основные отличия между ними
🍭 Как происходит определение итогового перечня capabilities дочернего (нового) процесса. Автор показывает, как это работает на примере ping. Кстати, если Вы не знали, то ping не совсем прост и обладает интересными особенностями ☺️

Если тема интересна, то рекомендуем держать рядом с собой man на capabilities открытым, т.к. Автор к нему часто отсылается.

Управление capabilities, в том числе, может быть использовано для повышения ИБ сред контейнерной оркестрации. Наглядно об этом можно посмотреть в статье и интерактивном уроке от SNYK:
🍭 Container does not drop all default capabilities
🍭 Kubernetes securityContext: Linux capabilities in Kubernetes

P.S. Preview работает только для первой статьи, но мы рекомендуем прочитать обе ☺️

Всем привет!

В статье описывается интересный подход к созданию набора OPA-проверок, которые формируются на основании входных данных.

Суть проста – у нас есть n проверок по различным группам, например, storage, network, compute, security и т.д. Скорее всего, за каждый тип проверок отвечают разные команды и разные люди.

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

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

Это придаст гибкость и повысит управляемость использования OPA-проверок. Небольшой пример описанного концепта приводится в статье ☺️

Привет!

В продолжение темы проверки K8S-манифестов представляем kube-review! Небольшую утилиту, которая используется для трансформации манифеста в… AdmissionReview Request!

Это может быть удобно для локального тестирования манифестов, без необходимости обращения к Kubernetes API.

Можно тестировать:
🍭 Манифесты локально, в том числе с использованием OPA (kube-review... | opa eval...). Есть альтернативный вариант локального использования OPA, о нем мы писали тут
🍭 Манифесты, использованные для запуска сущностей на кластере (kubectl get pod -o yaml | kube-review... | opa eval...)

Таким образом можно сделать небольшой инструмент аудита, в том числе уже запущенных сущностей. Подобный функционал есть и у Gatekeeper/Kyverno, но kube-review может быть попроще для начала (например, потому что не требуется создание и настройка дополнительных сущностей в кластере)

Единственное, что не поддерживается kube-review – это CRD

Привет!

Написание RBAC правил в Kubernetes не самое увлекательное занятие, в котором можно легко запутаться.

Иногда хочется некоторого полиморфизма – «Мне нужна почти такая же роль, только с перламутровыми пуговицами с немного иными привилегиями…».

И все заново – перечисляем ресурсы, права… Можно ли как-то иначе?

Оказывается, можно! С проектом от Red Hat, который называется Dynamic RBAC-operator. Он как раз дает тот самый полиморфизм: мы указываем «родительскую» роль и на базе нее создаем нужную нам, внося небольшие правки и корректировки.

В repo есть отличный пример создания роли «admin-without-users», наследованной от «cluster-admin», но с некоторыми отличиями ☺️

Всех с пятницей!

В приложении свежий материал от NIST (февраль, 2022) – «Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities».

Framework вводит 4 группы практик:
🍭 Prepare The Organization (PO): в Компании должна быть зрелая культура, готовая принять практики безопасной разработки
🍭 Protect the Software (PS): защита всех компонентов ПО от изменений и несанкционированного доступа
🍭 Produce Well-Secured Software (PW): стремление к сокращению уязвимостей в ПО при релизах
🍭 Respond to Vulnerabilities (RV): управление «остаточными» уязвимостями

Далее, как обычно – перечень рекомендаций по группам, примеры реализации и, что особенно круто – готовый mapping на аналогичные контроли в других стандартах.

P.S. Сам по себе документ небольшой, всего 36 страниц. Всем отличного вечера пятницы и выходных!

Привет!

Хорошая обзорная статья про Persistent Volume и как его настроить. Каждый pod, по умолчанию, потеряет данные после того, как будет воссоздан заново.

Для того, чтобы исправить это используются механизмы Volume (грубо говоря – папку на worker node) и Persistent Volume.

Именно о вторых и пойдет речь в статье:
🍭 Что такое Persistent Volume (PV) и принципы его работы
🍭 В чем разница между Storage Class, Persistent Volume и Persistent Volume Claim
🍭 Режимы доступа (Access Modes): ROX, RWO, RWX, RWOP. Приводится краткое описание каждого режима доступа
🍭 Описание процесса выделения дискового пространства pod’у: выбор подходящего Storage Class, определение требуемого объема памяти (Persistent Volume), создание Persistent Volume Claim, чтобы у pod была возможность использования внешнего хранилища данных

В завершении статьи приводится пример того, как это можно реализовать. Как всегда, с кодом, командами и небольшими пояснениями ☺️

Всем привет!

В repo доступна ссылка на Container Security Checklist от Carol Valencia, участницы команды Aqua Security.

Подборка сделана с привязкой к жизненному циклу контейнера и покрывает аспекты ИБ, значимые как при создании образа, так и при последующей его эксплуатации в качестве контейнера (workload).

Подборка структурирована по категориям:
🍭 Secure the Build. Повышение защищенности образов во время сборки, использование Hadolint для проверки Dockerfile, сканирование образов на наличие уязвимостей, подпись образов
🍭 Secure the Container Registry. Использование private registry, управление доступом с использованием RBAC
🍭 Secure the Container Runtime. Настройка runtime в соответствии с лучшими практиками (CIS Benchmark)
🍭 Secure the Infrastructure. Управление уязвимостями и обновлениями для хостов, настройка хостов в соответствии с рекомендациями CIS Benchmark
🍭 Secure the Data. Контроль доступа к файловой системе, корректная инъекция секретов
🍭 Secure the Workloads. Контроль действий контейнеров, применение практик контроля drift prevention для обеспечения неизменяемости (immutable) контейнеров

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

Привет!

Вчера мы писали про лучшие практики по защите контейнеров на разных этапах жизненного цикла. Одной из таких практик, применимой для runtime, является контроль drift prevention.

Есть один занимательный способ, как это можно реализовать при помощи… Admission Controller и инструмента kube-exec-controller!

Идея ребят из Box простая и достаточно элегантная:
🍭 У нас есть Validating Webhook, который срабатывает для [pods/exec, pods/attach]. Он их «пропускает», но событие мы регистрируем
🍭 Чтобы понять, к какому именно pod было «обращение» средствами kube-exec-controller вешается метка (label), в которой содержится информация о времени exec, об инициаторе
🍭 Дальше – интересней! Все pods, обладающие такой «черной меткой» начнут eviction process. Авторы подумали о том, что иногда exec бывает удобен и нужен, например, при debug. По этой причине они добавили Pod Time-To-Life (TTL), который больше для Dev-окружений и крайне мал для Prod-окружений

Чтобы с этим инструментом было проще работать ребята сделали kubectl plugin, получивший имя kubectl pi (сокращенно от pod interaction), который может показывать «меченых» и управлять временем TTL.

Если интересно – то можно почитать статью в официальном блоге Kubernetes, где детализируется этот концепт и есть наглядные схемы ☺️

Всем привет!

В статье рассказывается про то, как можно использовать возможности LinkerD для контроля трафика внутри K8S кластера.

Для этого используется механизм Traffic Policy (не путать с Network Policy), который в отличие от своего «K8S аналога» позволяет в том числе реализовать mTLS.

Статья разбита на несколько частей:
🍭 Принципы работы и способы конфигурации
🍭 Наглядный пример контроля трафика: запрет между namespace, разрешение внутри namespace, исключение из правила для некоторого трафика между namespace (например, health checks, metrics)

В завершении – подробная инструкция, «шаг за шагом», как это можно реализовать с примерами YAML и описанием действий