KubeArmor: k8s runtime security

Всем привет!

KubeArmor – runtime security решение, которое позволяет контролировать что происходит с контейнером и/или хостом на котором он расположен. В качестве «основного движка» используется AppArmor, SELinux и BPF-LSM.

Решение позволяет:
🍭 Реализовать hardening
🍭 Управлять процессами, сетевыми соединениями и контролировать доступ к чувствительным данным
🍭 Генерировать k8s network policy
🍭 Профилировать контейнеры для создания поведенческих моделей

Проект активно развивается (можно посмотреть в Version Releases Blog), есть документация, описывающая ключевые возможности KubeArmor и примеры его использования.

Sveltos: централизация управления кластерами k8s

Всем привет!

Целью проекта Sveltos является упрощение работы с большим количеством кластеров. Концептуально схему можно описать так: есть управляющий кластер, подчиненный кластера и профили кластеров, которые содержат требуемые данные. Обращаясь к кластеру управления можно вносить изменения в подчиненные кластеры.

Sveltos умеет:
🍭 Создать ресурсы в кластерах
🍭 Следить за configuration drift, возвращая все в «исходное состояние» (указанное в кластере управления)
🍭 Создавать ресурсы в dry-run режиме
🍭 Направлять alert в случае идентификации проблем с состоянием кластера
🍭 Управлять кластерами на основании labels (например, применять что-то на production и не применять на test) и не только

Полное описание функционала и компонентов проекта (какие есть operators, какие CRD и что они делают) можно найти в документации. Отдельно рекомендуем заглянуть в раздел «Blogs and Videos». В нем можно найти много ссылок на материалы по теме.

Как быстро обновляются Secrets и ConfigMaps в k8s?

Всем привет!

Все началось с простого опроса, в котором большинство ( ~ 41%) выбрало ответ «почти мгновенно», однако это не совсем так.

В статье Автор разбирает внутренние механизмы, отвечающие за процесс обновления Secrets и ConfigMaps в Pod.

У Kubelet есть параметр configMapAndSecretChangeDetectionStrategy, который может принимать 3 значения:
🍭 Get: получение объектов от API server
🍭 Cache: использованием TTL Cache
🍭 Watch (Default): наблюдение за интересующим объектом

Получается, что у Kubelet есть вся необходимая информация, однако обновления (мгновенного) не происходит. Оказалось, что у Kubernetes отсутствуют механизмы, запускающие реконсиляцию при обновлении ресурса (в нашем случае это Secret и ConfigMap).

На деле обновление происходит при вызове syncPod функции:
🍭 В случае изменения Pod (Pod event update, изменение параметров Pod) – что происходит не часто
🍭 Периодически: где-то раз в минуту

Именно по этой причине, по умолчанию, Secret и ConfigMap не синхронизируются мгновенно. Если хочется проверить, то есть repo с PoC. Если интересно как можно это ускорить – ответ есть в статье.

Open source threat modelling tools

Всем привет!

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

Рассматриваются такие инструменты, как:
🍭 Cairis
🍭 OWASP pytm
🍭 OWASP Threat Dragon
🍭 Threagile
🍭 ThreatSpec
🍭 Microsoft Threat Modeling Tool
🍭 Threats Manager Suite

Для каждого их них есть небольшой описание и ссылки на сайты/repo. В завершении статьи (раздел References) можно найти дополнительные материалы по теме.

Open-appsec: Web-protection и API Security

Всем привет!

Open-appsec – open source продукт, разрабатываемый командой Checkpoint. Представляет из себя add-on, который можно установить на Kubernetes Ingress Controller, Nginx и Kong API Gateway.

Обладает следующим функционалом:
🍭 API Security
🍭 Bot prevention
🍭 Intrusion Prevention (IPS Engine с поддержкой Snort 3.0 Signatures, аналитика от Checkpoint)
🍭 Защита от OWASP Top-10 и не только

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

Функционала и возможностей достаточно много, поэтому рекомендуем ознакомиться с документацией и роликами, которые демонстрируют работу open-appsec.

Service Mesh Comparison

Всем привет!

На сайте можно найти небольшое сравнение Service Mesh технологий. Рассматриваются все «основные» участники: Nginx, Istio, Kuma, Cilium, LinkerD и т.д.

В качестве критериев представлены:
🍭 Auto Proxy Injection
🍭 gRPC
🍭 Prometheus Integration
🍭 Tracing Integration
🍭 SPIFFE и не только

Кстати, на самом сайте можно найти интересную timeline-диаграмму, в которой отображены даты появления участников «на рынке».

DevSecOps в Chime

Всем привет!

По ссылке ребята из компании Chime делятся своим подходом к построению практик безопасной разработки и не только.

Соотношение разработчиков к ИБ было ~ 60/1, в результате чего надо было как-то оптимизировать затраты и выстроить рабочий процесс.

Если ничего не подходит – сделай свое! Так поступили ИБ-специалисты Chime и написали собственное приложение – Monocle.

При помощи него можно:
🍭 Получать сводную информацию о состоянии ИБ команды – что реализовано, степень соответствия требованиям
🍭 Оповещать команды в случае, если их «рейтинг» упал ниже порогового значения. При этом приложение позволяет указать, что именно надо поправить
🍭 «Сквозной рейтинг» всех команд – элемент геймификации
🍭 Получать сводную информацию о проекте команды и не только

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

Анализ PR на соответствие ИБ-требованиям

Всем привет!

Продолжение истории Chime! В статье они делятся опытом анализа pull request’ов при помощи их разработки – Monocle!

Команда определила следующие требования:
🍭 PR должен иметь хотя бы 1 review
🍭 PR не должен содержать dependency confusion
🍭 Repo должны содержать только те базовые образы, что были одобрены ИБ
🍭 «Новый код» не должен содержать уязвимостей уровня Critical и High

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

Если интересно, что внутри и как это работает (дада, там OPA) – в статье есть общая архитектура и описание ключевых принципов. Рекомендуем к прочтению!

Мини-лабораторные по анализу кода от GitHub

Всем привет!

По ссылке доступно 5 небольших лабораторных работ по анализу кода от команды GitHub.

Материал включает в себя:
🍭 Level-1: Black Friday
🍭 Level-2: Matrix
🍭 Level-3: Social Network
🍭 Level-4: Data Bank
🍭 Level-5: Locanda

Все лабораторные представляют из себя небольшие python-проекты. Чтобы «пройти» испытание, необходимо получить «passed» от hack.py (уязвимости больше нет) и test.py (при этом код все еще работает). Сложность возрастает от Level-1 до Level-5.

Можно попробовать как в Codespaces (при этом время использование будет тратиться) или установить локально.

Gartner Market Guide for Cloud Native Application Protection Platform

Всем привет!

В приложении можно скачать отчет Gartner, посвященный безопасности Cloud Native приложений. Пусть название Вас не смущает: помимо анализа рынка в отчете много полезной теоретической информации.

Например:
🍭 Общий взгляд на Risk Surface Area
🍭 «Дополнительные» задачи, которые появляются в Cloud Native для разработчиков
🍭 Описание функционала Cloud Native Application Protection Platform
🍭 Основные вызовы, с которыми можно столкнуться и не только

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

State of Secrets in AppSec

Всем привет!

Команда GitGuardian опросила 507 представителей отрасли для того, чтобы собрать информацию о вопросах ИБ, связанных с управлением секретами. В результате получился прилагаемый отчет.

Внутри можно найти:
🍭 Статистику об управлении секретами (сколько % находили hardcode, кто озадачился вопросами управления секретами, используемые практики и т.д.)
🍭 Самооценка уровней зрелости Компаний по вопросам управления секретами
🍭 Подходы к идентификации секретов в репозиториях исходного кода и не только

Получился простой, наглядный и информативный отчет, рекомендуем!

Managed Kubernetes Auditing Toolkit

Всем привет!

Еще один отличный материал от DataDog – Managed Kubernetes Auditing Toolkit (MKAT). Он позволяет идентифицировать ИБ-дефекты в облачных инсталляциях Kubernetes. На текущий момент поддерживается только AWS. Поддержка GCP GKE есть в roadmap.

При помощи него можно:
🍭 Идентифицировать взаимосвязь между k8s SA и AWS IAM Roles
🍭 Искать hardcoded учетные данные AWS в ресурсах k8s (Pods, CM, Secrets)
🍭 Идентифицировать возможность доступа pod’ов к AWS Instance Metadata Service

Кроме этого, MKAT позволяет визуализировать взаимосвязь сущностей через --output dot. В repo есть ссылки на другие решения по анализу конфигураций и описание их отличия от MKAT.

Копирование Secrets в Kubernetes

Всем привет!

Казалось бы, зачем «изобретать еще один велосипед» при управлении секретами в k8s? Есть же HashiCorp Vault с его sidecar/operator, SealedSecrets, External Secrets и не только. Однако, бывают такие случаи 😊

В статье описывается «путь» Lonto. Началось все с того, что командам нужен был сертификат не только для домена вида *.dev.example.com, но и для его sub-domains. Самым очевидным решением стало копирование секретов. Очевидным, но трудно поддерживаемым на большом объеме, особенно в условиях динамического предоставления сервисов (namespace’ов k8s) разработчикам. Второй задачей стала синхронизация секретов во всех кластерха и namespace’ах.

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

В соответствии с потребностями определили следующие требования:
🍭 Поддержка регулярных выражений для указания namespaces, куда должны быть скопированы секреты
🍭 Наблюдение за создаваемыми namespaces для добавления в них секреты (если такое требуется)
🍭 При удалении CR все порожденные им Secrets должны так же удаляться
🍭 Controller должен быть расширяемым. Например, для интеграции с HashiCorp Vault

Результатом работы стал SecretMirror, который доступен на GitHub. И если у вас аналогичные задачи, то может быть именно он сможет вам помочь. Описание архитектуры, логики работы и примеры использования (в том числе работа с HashiCorp Vault) можно найти в статье.

Вебинар «Первичная настройка платформы "Штурвал". Конфигурация провайдеров»

24 мая компании «Лаборатория Числитель» и «Инфосистемы Джет» приглашают вас присоединиться к второму практическому вебинару, посвященному работе с платформой управления контейнерами «Штурвал».

В программе:
▪️Конфигурация провайдера oVirt
▪️Конфигурация провайдера vSphere
▪️Подготовка шаблонов узлов

Демонстрацию решения проведут:
▪️Александр Краснов, технический директор «Лаборатории Числитель»
▪️Дмитрий Горохов, директор департамента виртуализации и контейнеризации «Инфосистемы Джет»

Вебинар будет интересен DevOps-инженерам и DevOps-администраторам.

✅ Регистрация

Вредоносные расширения VSCode

Всем привет!

По ссылке можно ознакомиться с результатами исследования Checkpoint, посвященного анализу расширений (extensions) для VSCode.

Даже с учетом того, что Microsoft старается гарантировать защищенность того, что доступно на marketplace, все равно нашлись вредоносные расширения.

В статье приводятся примеры таких extensions:
🍭 Prettiest Java // попытка кражи чувствительных данных
🍭 Theme Darcula dark // передача данных об окружении на внешний ресурс
🍭 Python-vscode // установка shell injector

Некоторые из них скачивались более 45 000 раз. Из названий видно, что многие расширения «мимикрировали» под существующие безвредные аналоги. Получился такой вот аналог typo squatting.

А контролируете ли Вы устанавливаемые расширения в VSCode? И если да, то как?

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, но вместо него может выступать любая другая система анализа событий.