Salus: SBOM Tool от Microsoft

Всем привет!

Тематика анализа и контроля состава ПО становится все актуальнее. И вот недавно Microsoft сделали проект Salus «открытым».

Этот инструмент используется для генерации SPDX 2.2 SBOM, которая содержит характерную информацию:
🍭 Document creation information. Общая информация – кто и когда создал, наименование ПО и т.д.
🍭 File section. Перечень файлов, из которых «состоит ПО», включая SHA-1/256 hash-значения
🍭 Package section. Перечень пакетов, используемых при создании ПО. Для каждого пакета указывается версия, «поставщик» (supplier), SHA-1/256 значение и т.д.
🍭 Relationship section. Описание взаимосвязи компонентов: например, Package и File

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

TripleCross: Linux eBPF offensive rootkit

Всем привет!

TripleCross – rootkit, который демонстрирует offensive возможности eBPF. Проект появился на свет в качестве работы h3xduck для защиты степени бакалавра в университете Мадрида.

Доступны следующие «модули»:
🍭 Library injection
🍭 Execution hijacking
🍭 Local privilege escalation
🍭 Backdoor with C2 capabilities
🍭 Rootkit client that allows an attacker to establish 3 different types of shell-like connections
🍭 Persistence
🍭 Stealth

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

P.S. Напоминаем, что подобные инструменты надо использовать строго в образовательных целях. И не использовать в production.

Trousseau: использование KMS provider для шифрования данных в Kubernetes

Всем привет!

Для шифрования данных в ETCD можно использовать штатные механизмы Kubernetes. Однако, есть нюанс, что ключи шифрования надо поместить на nodes, иначе возможны сбои. Альтернативный вариант – использование функционала KMS provider: третьей стороны, которая будет отвечать за шифрование, в том числе управлять ключами. При этом в ETCD будут попадать уже зашифрованные сущности.

Для упрощения подобной схемы ребята из Ondat сделали Trousseau – посредника между Kubernetes и KMS (например, HashiCorp Vault).

Схема получается следующая:
🍭 Пользователь создает сущность (например, Secret)
🍭 Kube-apiserver перенаправляет запрос в Trousseau
🍭 Он, в свою очередь просит зашифровать данные у HashiCorp Vault
🍭 Далее шифрованные данные направляются на хранение в ETCD

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

Если хочется «потрогать» руками, то есть удобная интерактивная лабораторная работа. В ней сперва настраивается encryption method, происходит конфигурация Transit Secret Engine в Vault, а затем демонстрируются зашифрованные секреты в ETCD.

Debug CoreOS и Silverblue

Привет!

В некоторых операционных системах достаточно сложно искать ошибки из-за банального отсутствия «встроенного инструментария» и запрета на его установку. Например, это характерно для Fedora CoreOS и Fedora Silverblue.

Как быть в таком случае? Есть один инструмент, который поможет с решением задачи – toolbox. По сути он представляет из себя контейнер, в который можно установить все необходимое.

Далее – запускаем его на требуемом сервере и устанавливаем необходимое ПО для debug с помощью dnf install. Всё содержимое корневой папки хоста будет доступно здесь: /run/host/. Это позволит использовать функционал утилит без необходимости установки их на хосте.

Подробнее об утилите и сценариях использования можно прочесть на сайте и в repo. Общее описание поиска ошибок с toolbox для Fedora CoreOS можно прочесть тут.

Сеть в Kubernetes: основы

Всем привет!

В статье просто и доступно описаны основы того, как устроена сеть в Kubernetes. В начале приводятся общие сведения: все nodes могут взаимодействовать между собой, каждому pod назначается свой IP, все pod могут взаимодействовать между собой без использования NAT.

Далее Автор углубляется и описывает такие сущности как:
🍭 Service. Что он делает, зачем он нужен и почему «привычное» управление через IP не применимо для Kubernetes, что такое Endpoint.
🍭 Типы Service. ClusterIP, NodePort, LoadBalancer и какая между ними разница.
🍭 Что такое CoreDNS и для чего он используется
🍭 Назначение Kube-proxy. Что он делает, почему IP адреса pod и service такие разные и т.д.

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

Всем привет!

Permission-manager - это open source утилита от итальянской компании SIGHUP, предназначенная для управления Kubernetes RBAC.

Утилита имеет интуитивно понятный графический веб-интерфейс, в котором можно выполнять следующие действия:
🍡Создавать пользователей
🍡Назначать им права доступа на namespaces/кластер
🍡Автоматически генерировать Kubeconfig YAML

Как это работает:
Permission-manager разворачивается в Kubernetes. Для управления правами доступа используются шаблоны (по факту это cluster roles): одни для организации доступа к определенным ресурсам (namespaces), а вторые - для доступа к кластеру. По умолчанию создается 4 таких шаблона с фиксированным набором прав (например, template-namespaced-resources___developer), которые сразу доступны из веб-интерфейса и могут быть назначены пользователям:
🍡Developer (namespace)
🍡Operator (namespace)
🍡Read-only (cluster)
🍡Read-write (он же admin, cluster)

Из коробки шаблонов достаточно мало, поэтому собственные точно придется создавать, как минимум, для доступа к конкретным namespaces. Это можно сделать следующим образом: создать cluster role с необходимыми правами и с названием template-namespaced-resources___Х, где Х - название роли. После деплоя новая роль автоматически появится в веб-интерфейсе вместе с описанием прав доступа для нее.

Несмотря на то, что утилита очень простая и удобная, есть определенные минусы, которые надо иметь в виду:
🍡Нет интеграции с IdP (пользователи создаются в web UI)
🍡Нельзя просмотреть текущих пользователей и их права доступа
🍡Нельзя в веб-интерфейсе менять права (только через templates)

Больше информации можно найти по ссылке: https://github.com/sighupio/permission-manager

Аналитика базовых образов

Всем привет!

Ребята из ChainGuard подготовили небольшое исследование на тему наиболее популярных базовых образов. В список попали Alpine, Ubuntu, Golang, OpenJDK и не только.

В отчете можно найти сводную информацию по:
🍭 Уязвимостям в этих образах (с использованием разных сканеров)
🍭Количество уязвимостей с разбивкой по годам (что подтверждает тезис Авторов о росте технического долга)

Супер-нового в отчете нет, но он хорошо помогает структурировать скорее всего известную информацию.

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

Курс: GitOps For Reliable Kubernetes

Всем привет!

Ребята из Traefik подготовили бесплатный курс, посвященный GitOps. Согласно описанию, это двухчасовой курс, который описывает концепт GitOps, а также включает в себя лабораторные работы по конфигурированию Kubernetes-окружения с использованием Git и Flux.

Курс содержит следующие разделы:
🍭 GitOps is Configuration Management
🍭 Templating Manifests With Kustomize
🍭 How Flux Operates
🍭 Managing Flux
🍭 Deploy the Application
🍭 Secure the Application и другие

Зарегистрироваться можно по ссылке в описании. P.S. Есть еще аналогичный курс по ArgoCD, про который мы писали ранее.

Infra: управление доступом к Kubernetes и не только

Всем привет!

Основная задача проекта Infra – управление доступом. Пока что только к Kubernetes.

Решение предоставляет набор стандартных ролей: cluster admin, admin, edit, view, logs, exec, port-forward, которые могут назначаться пользователям. При этом можно не только предоставлять права, но и отзывать их. А если набор стандартных ролей вам не подходит – можно добавить собственные.

Поддерживается интеграция с Okta, AzureAD, OIDC, Google в качестве identity provider. В планах добавить поддержку GitHub/Lab.

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

Особенно советуем уделить внимание страницам с “Coming Soon” и “Roadmap” – согласно им, у разработчиков весьма амбициозные планы. Например, доработка для управления доступом к PostgreSQL, MongoDB, SSH, RDP и т.д

Distroless Images: подход ChainGuard

Всем привет!

Distroless очень интересный концепт, который может быть полезен как для ИТ, так и для ИБ. Началось все с вопроса: «Насколько маленьким может быть образ?». И дело даже не в его размере, а в том, чтобы оставить только нужное и исключить ненужное.

Например, зачем в запущенном контейнере пакетные менеджеры и bash? (опустим вопросы debug). Именно в этом (если упростить) и заключается концепция distroless – в образ контейнера помещается только ПО и те зависимости, на которые оно «опирается» при работе.

Одними из первопроходцев был Google. Ребята от ChainGuard, в свою очередь, предлагают альтернативный подход к построению таких образов:
🍭 Google предлагает использовать multistage build
🍭 ChainGuard предлагают использовать apko и mélange

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

Развитие SAST-программы в Razorpay

Всем привет!

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

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

Далее – как обычно: как они настраивали, когда сканировали, как работали с командами. Схемы, графики, описания. Особенно хочется отметить, что в их случае top-down подход не сработал, а bottom-up дал первые результаты.

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

В итоге, за год ребята прошли путь от 0 «подключенных» приложений до 200!!!

KubeEye: обнаружение и аудит ресурсов k8s

Всем привет!

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

При помощи KubeEye можно:
🍭 Проводить аудит на соответствие лучшим практикам
🍭Идентифицировать проблемы в Control Plane компонентах
🍭Анализировать состояние nodes и идентифицировать, например, disk pressure

«Из коробки» доступно порядка 30 правил, например: PrivilegeEscalationAllowed, CanModifyWorkloads, ImageTagIsLatest, NodeStatus, KubeletStatus и другие. Также использование инструмента подразумевает возможность создания собственных проверок.

Прочитать про установку, конфигурацию и ознакомиться с планами дальнейшего развития (roadmap) можно в repo проекта.

iftree: визуализация сетевых интерфейсов

Привет!

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

С этим может помочь iftree – утилита, которая позволяет визуализировать veth/bridge и предоставлять данные в разных форматах:
🍭 Диаграмма (предоставляются данные для генерации в Graphviz)
🍭 Текст
🍭 Таблица

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

Istio Handbook

Всем привет!

Очень неплохой материал, посвященный Istio – статьей его язык не поворачивается назвать, т.к. материала очень много, но это и не полноценная книга.

В материале содержится информация о:
🍭 What Does Istio Do?
🍭 Introduction to Istio
🍭 Istio’s Architecture
🍭 How to Use Istio in Practice
🍭 How to Run the Services on the Mesh
🍭 Ingress Gateway – How to Admit Traffic into the Mesh
🍭 Observability
🍭 Traffic Management – Canary Deployments
🍭 Istio Security

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

The Path to GitOps от Red Hat Developer

Привет!

В приложении можно скачать книжку о том, что такое GitOps, зачем он нужен и как его можно реализовать.

Содержание книги:
🍭 What is GitOps
🍭 Tools of the Trade
🍭 Templating
🍭 Git Workflows
🍭 Repository and Directory Structures
🍭 CI/CD with GitOps
🍭 Handling Secrets

В книге ~ 45 страниц, все достаточно хорошо структурировано и много ссылок на полезные источники по каждой из рассматриваемых глав.

Создание plugins для ArgoCD

Всем привет!

В статье приводится пример создания plugin для ArgoCD. Автор захотел использовать kbld (утилита, которая «транслирует» tag в digest образа) с меньшим количеством действий.

Есть несколько способов создания plugin:
🍭 Добавление конфигурации в «основной» ConfigMap ArgoCD. Подходит для простых доработок, в несколько строк кода
🍭 Добавление plugin в качестве sidecar для repo-server pod. Подходит для «продвинутых» plugin

Т.к. kbld достаточно простая утилита, Автор выбрал первый вариант и решил его реализовать. Как он это делал, что куда добавлял и как модифицировал kind: Application ArgoCD – все это описано в статье. В итоге получился лаконичный механизм использования инструмента.

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

The Kubernetes Network Model

Всем привет!

По ссылке доступен ресурс, посвященный тематике сети в Kubernetes. Материал состоит из следующих разделов:
🍭 Network Model
🍭 CNI
🍭 Services
🍭 In(En)gress
🍭 Network Policies
🍭 IPv6
🍭 DNS

Каждый раздел, в свою очередь «раскрывается» еще на несколько областей. Например, Services -> Headless, ClusterIP, NodePort, LoadBalancer, ServiceMeshes и Optimisations. И да! Есть лабораторные работы, которые можно поделать, попутно изучая материал.

P.S. Увы, некоторые разделы не заполнены (например, Network Policies) и Автору требуется помощь. Возможно, это будете Вы ☺️

Обеспечение безопасности Deployments k8s

Всем привет!

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

Рассматриваются следующие области:
🍭 Использование Service Account, запрет automountServiceAccountToken
🍭 Использование Security Context, описание наиболее значимых из доступного множества
🍭 Использование Distroless и Container-Optimized Images, сканирование образов на наличие уязвимостей и мисконфигураций
🍭 Использование Pod Security Admission (или любого другого Policy Engine наподобие OPA/Gatekeeper или Kyverno)
🍭 Корректное использование Secrets

Из материалов статьи можно составить неплохой check list для последующего анализа Deployments и формирования планов по устранению ИБ-дефектов.

Pixie: network visibility and observability

Всем привет!

Pixie – инструмент, созданный с использованием все больше и больше набирающей популярность технологии eBPF. Является «Sandbox Project» CNCF.

При помощи Pixie можно:
🍭 Получить информацию о traffic flow внутри кластера, отследить DNS-request
🍭 Собрать данные об использовании ресурсов кластера (CPU, Sent/Received Traffic и т.д.)
🍭 Изучить Service Performance: HTTP requests, HTTP Errors, HTTP Latency и т.д.
🍭 Request Tracing (предоставление информации о full-body requests) и многое другое

Решение обладает web-интерфейсом и документацией, в которой описано как установить/настроить и использовать Pixie. Из приятного – разработчики отдельно приложили Software Bill of Materials, правда только со сведениями о лицензиях.

Если хочется чуть больше – можно ознакомиться со статьей, в которой Автор использует Pixie для анализа сети.

Kubernetes Hardening при помощи Policy Engine

Всем привет!

Существует много разных подборок с политиками ИБ (и не только), которые можно реализовать при помощи Policy Engine. С одной стороны, это очень хорошо, т.к. есть где «подсмотреть» и что переиспользовать. С другой – не очень, т.к. не всегда понятно, что из этого реально полезно, а что решает локальной задачи в Компании N.

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

Например:
🍭 block-endpoint-edit-default-role
🍭 disallowanonymous
🍭 read-only-root-filesystem
🍭 block-nodeport-services и другие

Пример реализации политик осуществлен с помощью Gatekeeper. Однако, ничего не мешает использовать наиболее удобный Вам инструмент: Kyverno, Datree, Kubewarden и т.д.

STRIDE и ASVS

Всем привет!

Для моделирования угроз можно использовать разные методологии и практики. Одним из часто встречающихся инструментов является STRIDE.

Его использование позволяет обобщенно взглянуть на то, какие угрозы могут быть актуальны для приложения. Дальше – надо выбрать mitigations (контроли, меры защиты, контрмеры и т.д. – наименования не так важны).

Чтобы упростить процесс Автор repo сделал собственный mapping между STRIDE и Application Security Verification Standard (ASVS).

Процесс выглядит примерно так:
🍭 Моделирование угроз с использованием STRIDE и Rapid Threat Modelling (личное предпочтение Автора, можно выбрать наиболее интересную Вам)
🍭 Использование таблицы-mapping STRIDE и ASVS, чтобы понять, где и какие контроли искать
🍭 Адаптация требований под проект

Больше деталей по процессу, также как и сами материалы (включая небольшую книгу про Rapid Threat Modelling) можно найти в repo.

P.S. Проект только в начале своего пути ☺️