Привет!

Syft – полезная утилита, которая позволяет сгенерировать Software Bill of Materials (SBOM) для образов контейнеров - перечень компонентов, из которых "состоит" ПО и образ.

Реализована поддержка пакетов и библиотек для APK, DEB, RPM, Ruby Bundles, Python Wheel/Egg/requirements.txt, JavaScript NPM/Yarn, Java JAR/EAR/WAR, Jenkins plugins JPI/HPI, Go modules.

Присутствует нативная интеграция с другим продуктом Anchore – Grype (сканер уязвимостей для образов контейнеров).

И, как обычно, поддержка большого количества output форматов: json, text, cyclonedx, spdx, spdx-json, table.

Кстати, недавно (11 октября) прошла конференция, посвященная безопасности Supply Chain – Supply Chain Security Con. Записей докладов пока нет, но можно скачать keynotes для того, чтобы быстро ознакомиться с ключевыми тезисами.

Привет!

Aqua Enterprise получила большое обновление.
Главное в версии 6.5 — фича под названием Advanced malware protection. Она добавляет новые функции встроенному антивирусу, такие как:
🍏 Защита в реальном времени для хостов и контейнеров.
🍏 Обнаружение вредоносов в файлах, буфере обмена и реестре Windows.
🍏 Обнаружение и предотвращение file-less атак.
🍏 Новые виджеты для главного дэшборда :)

Помимо этого, обновление содержит:
🍏 Новые фильтры для журналов аудита.
🍏 Поддержку установки в среде k3s.
🍏 Возможность настройки отдельных Enforcers (ранее настраивать можно было только Enforcer groups).
🍏 Поддержку интеграции с GitHub Container Registry.
🍏 Jenkins плагин теперь поддерживает сканирование с использованием Podman.
🍏 Aqua Starboard теперь по умолчанию деплоится вместе с KubeEnforcer-ами.
🍏 Появились новые команды для API и ряд других нововведений.

Апгрейд на версию 6.5 поддерживается для версий 6.2, 6.0 и 5.3.

Привет!

Отрицательный опыт – тоже опыт! Есть интересные подборки с anti-pattern, в которых описано как делать НЕ стоит и почему это так.

В статье приведены 10 anti-pattern для Kubernetes deployment:
🍭 Размещать конфигурацию внутри образа контейнера
🍭 НЕ использовать Helm или иные templating-решения
🍭 Deploy в определенном порядке (приложения не должны «падать», если их зависимости еще «не готовы»)
🍭 Deploy без указания Lim/Req для CPU и RAM
🍭 Использование образов с тэгом «latest» в продуктивных средах
🍭 Deploy обновлений через «убийство» pod (что влечет image pull, более корректный путь – через модификацию конфигурации, что приведет к обновлению с сохранением управления версионности)
🍭 Использование продуктивных и тестовых сущностей в одном кластере
🍭 НЕ использовать blue/green и/или canary deployment для обновления критичных приложений (rolling updates не всегда достаточны)
🍭 Отсутствие метрик для анализа успешности deployment
🍭 Cloud vendor lock-in: «привязка» к облачным услугам (корректный путь – создание сущностей таким образом, чтобы их можно было легко «переносить» между различными средами)

Почему тот или иной anti-pattern попал в перечень неплохо расписано в самой статье и с примерами (оценка Medium на время чтения статьи ~ 22 минуты)

P.S. Всех с пятницей! Отличных выходных!

Всем привет!

Veracode сделал общедоступными часть своих интерактивных курсов по обучению безопасной разработке!

Доступно несколько базовых направлений:
🍭 Base Terminal
🍭 Juice Shop
🍭 Python AppSec
🍭 React

Если Вас интересует интерактивное обучение, то можно обратить внимание на проекты Kontra (о котором мы писали тут) и Codebashing от Checkmarx (если платная и бесплатная версия).

Также ребята сделали удобное сравнение между платной и бесплатной версией своего продукта (доступно по ссылке). Согласно сравнительной табличке Community Edition является Forever Free 😊

Всем привет!

Еще один cheatsheet на тему Docker security, на этот раз от GitGuardian!

Об этом есть множество аналогичных материалов, подборка от GitGuardian не стала исключением и состоит из знакомого перечня рекомендаций:
🍭 Корректное использование tags
🍭 Назначение default user
🍭 Исключение plain text секретов из ENV
🍭 Контроль доступа к docker daemon
🍭 Управление linux capabilities
🍭 Контроль файловой системы, возможностей на чтение/запись в определенные директории и другое

Что отличает рекомендации GitGuardian и почему стоит на них взглянуть? Крайне удобная схема, где все рекомендации собраны воедино. Можно использовать в качестве шпаргалки, когда надо посмотреть "а не забыл ли я что?" ☺️

Всем привет!

Рано или поздно вам придется столкнуться с CrashLoopBackOff… Иногда понять в чем причина не всегда просто и можно воспользоваться рекомендациями из статьи.

Ребята выделили наиболее частые причины, которые приводят к указанному состоянию:
🍭 Insufficient resource – недостаток ресурсов, из-за которого контейнер не может запуститься
🍭 Locked file – файл был заблокирован другим контейнером
🍭 Locked database – база данных используется (заблокирована) другим контейнером
🍭 Failed reference – что-то внутри контейнера ссылается на скрипты/исполняемые файлы, которые отсутствуют в контейнере
🍭 Setup error – некорректная настройка init-container
🍭 Config loading error – невозможно загрузить требуемую конфигурацию
🍭 Misconfigurations – некорректные настройки системы
🍭 Connection issues – DNS или kube-DNS не может «связаться» со сторонним сервисом
🍭 Deploying failed services – попытка deploy сервиса/приложения, которое уже находится в статусе «failed» (например, из-за невозможности доступа к иным сервисам)

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

Привет!

Статья, посвященная Autoscaling (динамической адаптации вычислительных ресурсов, таких как CPU и RAM в зависимости от потребностей и эффективности работы приложения). Autoscaling может работать как для увеличения ресурсов, так и для их сокращения, чтобы оптимизировать работу кластера.

Рассматривается несколько видов, доступных в Kubernetes:
🍭 Horizontal Pod Autoscaler (HPA): управление количеством pods, например, в replicas, scale out
🍭 Vertical Pod Autoscaler (VPA): управление мощностями существующих сущностей, scale up
🍭 Cluster Autoscaler: управление вычислительными мощностями кластера, если их недостаточно для корректного функционирования нагрузок

Принцип работы Autoscaler достаточно прост: создается Kubernetes API Resource и Controller. Controller взаимодействует с Metrics API Server и принимает решение о необходимости масштабирования, если оно требуется

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

Написано очень доступно, с диаграммами и объяснением каждого концепта «на пальцах». Для Ops-специалистов, скорее всего, не будет ничего нового, а для Sec, которым интересно погрузиться – вполне. Тем более, что ранее мы уже писали об интересном способе использования VPA для формирования Req/Lim для CPU и RAM с использованием Goldilocks.

Всем привет!

Пока мы морально готовимся к «рабочим выходным», миримся с ушедшим бабьим летом и промокаем под постоянными дождями, наступила пятница!
И в этот день судьба решила порадовать нас и подарить чудесный солнечный день!
А мы порадуем вас интересной фичей - от команды хорошо знакомого нам GitHub. GitHub Actions!

Фича, по сути, не совсем новая, но для GitHub это эдакий свой взгляд на реализацию CI/CD. Как бы ни напрашивалось сравнение с GitLab CI, подход к реализации у GitHub получился иной.

🍩 Фича представляет из себя отдельный каталог в репозитории с набором YML манифестов, каждый из которых описывает какое то действие этапа сборки. Например action для test или merge коммита в мастер ветку.
🍩 Для начала работы не требуется никаких настроек или интеграций. Достаточно создать каталог .github/workflows, в котором будут размещены job манифесты
🍩 Actions могут быть особенно полезны в облачных инфраструктурах, так как описание абсолютно всех этапов и триггеров сборок могут быть размещены в одном репозитории, который клонируется, например в CodeCommit
🍩 В целом комплекс очень напоминает большие плейбуки Ansible с кросс ссылками друг на друга. Возможность создания подобных конструкций поможет создавать большие workflow с множеством различных trigger и специфичных jobs для разных event.

Отдельного упоминания заслуживает marketplace вендора, в котором собран набор манифестов часто используемых Actions, а так же возможность писать собственные action’ы и шарить их с комьюнити.

Ссылка как всегда ниже, приятного ознакомления! 👇

https://github.com/features/actions

Всем привет!

В приложении отчет от Canonical – «Kubernetes and cloud native operations report 2021». Он содержит много интересной статистической информации на основе ответов 1200 респондентов.

Например:
🍭 Использование cloud (public, hybrid, private)
🍭 Информация о количестве кластеров
🍭 Использование виртуализации и/или bare metal
🍭 Helm-chart, насколько часто их используют
🍭 Основные опасения при работе с оркестраторами и многое другое!

Много цифр, мало «воды», рекомендуем к ознакомлению! ☺️

Привет!

Отличная статья про написание Custom Scheduler для Kubernetes! В начале статьи описаны концепты Scheduling:
🍭 После запроса о создании pod попадает в Scheduling Queue
🍭 Далее pod надо назначить на node, это делается в 2 этапа: Scheduling и Binding
🍭 Scheduling происходит в несколько этапов. Сперва «отсекаются» nodes, которые не подходят для запуска pod (например, из-за taints). Далее оставшиеся (подходящие) nodes ранжируются (фильтруются) с целью выбор единственной
🍭 Binding – взаимодействие с Kubelet выбранной node, постановка задачи на создание pod

Изменение приоритетов scheduling может быть осуществлено при помощи plugins, которые могут видоизменять процесс на разных этапах (см. картинку в статье). Общий набор plugins, которые используются в процессе scheduling описывается в profile (грубо говоря, описываем, как и что надо делать, на каком этапе).

Вторая часть статьи посвящена созданию собственного plugin’a – “NetworkTraffic”, его настройке и последующему использованию в качестве «основного» механизма scheduling. Принцип простой - выбираем node на основе анализа сетевого трафика!

Много кода, конфигураций и примеров! Очень наглядно и понятно объясняет концепт принятия решения о том, где именно следует запустить pod

Всем привет!

SNYK подготовили собственный набор обучающих курсов по тематике безопасности приложений. На данный момент можно попробовать:

🍭 Java: SQLi, Directory Traversal, XSS
🍭 JavaScript: SQLi, Directory Traversal, XSS, Prototype Pollution
🍭 Kubernetes: Container does not drop all default capabilities

Помимо интерактивных demo приводится много интересной теории, а также объясняет, что именно плохо, почему это так, к чему это может привести и как это можно поправить.

Очень наглядно – схемы, примеры кода и ссылки на полезные ресурсы с информацией! Надеемся, что проект будет развиваться, а количество курсов - увеличиваться 😊

Привет!

Интересный проект, представляющий из себя средство защиты web-трафика, services и API - Curiefence. Поддерживается интеграция с Envoy и Nginx.

Согласно документации, включает в себя такие функции как:
🍭 WAF (включая позитивные и негативные модели)
🍭 Защита от DDoS на прикладном уровне
🍭 Защита API (включая schema enforcement) и не только

"Из коробки" доступны преднастроенные dashboards с использованием Kibana, так же можно анализировать метрики при помощи Grafana.

Общий концепт решения представлен в коротком видео. На Katacoda доступно несколько уроков для ознакомления: Getting Started и API Basics.

P.S. Проект является частью CNCF (CNCF Sandbox project). С документацией можно ознакомиться вот тут.

Всем привет!

Статья, посвященная настройке аутентификации и авторизации в кластере Kubernetes при помощи Dex и LDAP (в статье рассматривается OpenLDAP)!

Целевая картинка, которая должна получиться:
🍭 Пользователь использует LDAP аутентификацию в Dex
🍭 Dex «уточняет» у LDAP валидность учетных данных
🍭 LDAP возвращает информацию о пользователе Dex'у
🍭 Dex предоставляет пользователю инструкцию, в которой описан алгоритм получения доступа к кластеру, а также информацию о группе в которой он состоит

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

Подобный подход удобен для пользователя, а для ИБ – удобный инструмент управления правами доступа (с точки зрения назначения/удаления) с использованием групп LDAP и RBAC K8S (mapping ролей K8S на доменные группы).

P.S. В завершении статьи как раз есть пример предоставления роли Cluster Admin группе «clusterusers». Но так, пожалуй, делать не стоит 😊 Всех с пятницей! Отличного вечера и выходных!

Всем привет!

По ссылке доступен генератор YAML файлов для Deployment, StatefulSet и DaemonSet от Octopus Deploy.

Пользоваться крайне просто, надо лишь указать необходимую информацию о создаваемой сущности:
🍭 Сведения для Metadata
🍭 Deployment Strategy
🍭 Информацию о контейнерах и их характеристиках
🍭 Сведения о tolerations
🍭 Параметры pod security context и т.д.

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

Всем привет!

У нас была отдельная роль для Jenkins, обладающая доступом к SecretID, несколько приложений, которые использовали AppRole (RoleID и SecretID) и обладали своими собственными ролями на чтение секретов…

В статье представлен интересный подход использования AppRole в соответствии со следующей схемой:
🍭 Создаем Role [1] для приложения, используем AuthMethod: AppRole
🍭 Создаем политику [‘read’, ‘list’], применяем к Role приложения [1]
🍭 Получаем RoleID [RiD] приложения
🍭 Создаем Role [2] для Jenkins, используем AuthMethod: Token, генерируем Token [T]
🍭 Создаем политику [‘read’, ‘list’, ‘update’] для SecretID, которую применяем к Role Jenkins [2]
🍭 Настраиваем VAULT_TOKEN [T] и RoleID [RiD] как переменные окружения в Jenkins
🍭 Внутри отдельного build извлекаем SecretID: при помощи VAULT_TOKEN [T] Jenkins аутентифицируется в Vault и «изменяет» SecretID (права у него есть, [2]), записывает его в переменную [SiD]
🍭 Далее – используя RoleID [RiD] и SecretID [SiD] получаем доступ к секретам. Готово!

В рассматриваемом сценарии используется только одна относительно long-lived сущность, а именно – token, который используется Jenkins для аутентификации в Vault. Все остальные сущности – «одноразовые» или могу обладать небольшим сроком жизни (в зависимости от реализованных настроек).

Всем привет!

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

Решение обладает таким функционалом как:
🍭 «Захват» API трафика с использованием ServiceMesh (например, Istio)
🍭 Создание OpenAPI спецификации по результатам анализа API трафика. Альтернатива – загрузка уже существующей спецификации
🍭 Оповещение о расхождении между «доверенной» OpenAPI спецификацией и API-вызовами, которые реализуются в runtime
🍭 Обладает web-интерфейсом для большей наглядности полученной информации

Больше информации можно узнать в документации, а также на web-сайте решения, особенно в разделе Resources, где приведены обзорные статьи. Например, «APIClarity in action»

P.S. Поздравляем всех с наступающими праздниками! Желанием отличного отдыха, множества положительных эмоций и приятного времяпрепровождения! 😊

Всем привет!

Postee – утилита от Aqua Security, предназначенная для сбора и маршрутизации событий в сторонние системы. Утилита получает сообщения в формате JSON через webhook-интерфейс и доставляет их в соответствии с настроенными правилами.
Основное назначение этой утилиты – централизованный сбор событий с продуктов Aqua Security. Например, может интегрироваться с Aqua Enterprise (отправка отчетов о найденных уязвимостях) и open source утилитой Tracee, используемой для защиты и анализа действий runtime на уровне Linux (о ней мы писали тут).

Перечень доступных интеграций:
🍡JIRA,
🍡Email,
🍡Slack,
🍡Microsoft Teams,
🍡ServiceNow,
🍡Splunk
🍡Generic WebHook

Как использовать:
🍡Сначала необходимо настроить Postee config file, который содержит логику отправки сообщений. Правила маршрутизации пишутся на языке REGO
🍡Затем развернуть готовый образ, доступный из репозитория aquasec или собрать его из исходников
🍡Запустить Postee можно как в Docker, так и в Kubernetes с использованием манифестов или HELM-чарта
🍡Для упрощения операций по администрированию Postee имеет веб-интерфейс

Информацию о Postee можно найти по ссылке: https://github.com/aquasecurity/postee
Пример интеграции с Tracee есть в блоге Aqua Security: https://blog.aquasec.com/tracee-runtime-malware-alerts-aqua-postee

Привет!

Статья, посвященная вопросам защиты Kubernetes API - нечто вроде "общего перечня рекомендаций, чтобы не забыть/проверить".

Рассматриваются такие темы, как:
🍭 Практики обеспечения сетевой безопасности при обращении к Kubernetes API //общие настройки TLS, настройки TLS при взаимодействии API Sever с Kubelet и ETCD
🍭 Управление учетными данными //использование IAM-решений, отключение автоматического назначения Service Account Token для всех pod
🍭 Аутентификация //использование внешних решений для аутентификации, НЕ использование static tokens, отключение анонимной аутентификации
🍭 Авторизация //использование RBAC, отдельно рассматриваются примеры с verb [‘escalate’, ‘bind’], запрет на AlwaysAllow, использование Admission Controllers
🍭 Доступ к Kubelet //ограничение прямого доступа, блокировка анонимной аутентификации, настройка авторизации

Статья достаточно объемная, в ней много примеров «как настроить», есть объяснения или ссылки на то, почему так делать (не) стоит и/или на сопроводительные материалы

Привет!

Допустим, что вы нашли RSA Private Key, в публичном repo. Хорошо это или плохо? Можно ли им воспользоваться, если да – то, от чего он? Можно ли использовать его для SSH доступа? Куда? Или с его помощью можно управлять TLS?

Именно эти вопросы задали себе ребята из TruffleSecurity (авторы небезызвестного Trufflehog)! Из этих размышлений получился очень интересный инструмент – Driftwood.

В 2015 году Symantec выпустил Extended Validation для google.com/www.google.com, о чем Google не подозревал. Ошибка была вызвана внутренними процессами Symantec. В будущем это приведет к созданию Certificate Transparency – фактически гигантскому log, в котором содержится информация о всех выпущенных сертификатах. Log доступен для публики и используется для идентификации проблем несанкционированного выпуска сертификатов (как в случае с Google).

При чем тут Driftwood? Все просто!
🍭 При помощи Trufflehog ребята искали RSA Private Key, из которых (при соблюдении некоторых условий) можно извлечь Public Key, но для чего он?
🍭 И вот тут как раз и пригодился Certification Transparency, который стал «базой знаний», у которой можно «спросить». За это уже отвечает Driftwood

Итого – у нас на руках есть Private Key и информация о его Public-составляющей.
Что может пойти не так? Например, можно аутентифицироваться в GitHub и делать push/pull commits на правах легитимного пользователя в зависимость зависимости зависимости, что приводит нас к Supply Chain Attack! И иные не очень хорошие вещи.

А что, если человек добавил passphrase при создании ключевой пары? Ребята подумали и об этом, добавив словарь наиболее часто встречающихся паролей, что позволяет получать информацию.

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

Привет!

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

SNYK представил свой подход к решению этой задачи, через SNYK Score. SNYK Score – абстрактное число от 0 до 1000, чем он выше, тем лучше взяться за устранение в первую очередь.

Рассчитывается он исходя из параметров:
🍭 Severity. Самая «весомая» часть, High/Medium/Low имеют свои значения, вплоть до 500. Чем выше – тем хуже, тем приоритет на устранение выше
🍭 Частота появления. Чем чаще встречается – тем больший вес получает. Принцип – единым махом семерых убиваю
🍭 Hotfiles. Файлы, которые являются наиболее проблемными, соответственно получают «+» к Score. Это помогает сфокусироваться на наиболее проблемных областях
🍭 Наличие примеров устранения. Если у SNYK есть пример хорошего устранения проблемы, то Score увеличивается. Все просто – есть удобный пример, не изобретаем велосипед и устраняем проблему
🍭 Часто исправляется в OSS. Если SNYK видит аналогичную проблему в более чем 100 repo из своего «training set», то Score увеличивается. Логика простая – если это часто встречается в OSS, то вероятность эксплуатации (даже Script Kiddie) повышается и лучше устранить у себя

Подробнее о математике расчета можно почитать в этой статье и в официальной документации SNYK. Не факт, что такой подход можно/нужно реализовывать у вас, но как еще одна точка зрения на вопрос – вполне себе ☺️

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

При управлении секретами есть одна весомая проблема – Secret Zero, т.е. как доставить «первичный секрет», который будет использоваться для доступа к другим секретам внутри хранилища?

Допустим, наш первичный секрет – Token. Иронично, но сам по себе он уже секрет. Наверное, надо сделать секрет, который будет контролировать доступ к нашему Token, получается рекурсия…

Одним из выходов становятся «центры доверия» - например, GitLab и JWT, Kubernetes и ServiceAccount, LDAP и учетные данные. Принцип простой – есть «третья сторона», которой мы доверяем и у которой можем спросить – «Может ли эта сущность запрашивать секреты? Можно ли ее пропустить в хранилище?». А ответ оставляем на рассмотрение третьей стороны.

Но что делать, если такой третьей стороны нет? И вот тут на помощь приходит AppRole (у HashiCorp Vault).

В видео от HashiCorp можно ознакомиться с общими рассуждениями на тему Secret Zero и с тем, как можно использовать AppRole для решения проблемы.

Недавно мы уже писали о похожем подходе для извлечения секретов в CI-pipeline. Однако, в видео Hashi есть ряд существенных отличий:
🍭 Первое заключается в том, что RoleID находится у Runner, а не задается в pipeline.
🍭 Второе – в процессе получения SecretID. В упоминаемом посте Token использовался для получения SecretID сразу, но есть и альтернативный способ!

Вместо SecretID можно вернуть еще один Token (да сколько можно!), назовем его Wrap Token, который предоставляет доступ только в Cubbyhole – некоторую область внутри Vault. Это называется Response Wrapping. Можно настроить количество использований или время жизни Wrap Token, что еще больше минимизирует риск компрометации.

Соответственно, чтобы извлечь SecretID надо реализовать обратную процедуру – Unwrapping.
Unwrapping осуществляется с использованием Wrap Token, который у нас уже есть, в результате мы получаем SecretID.

Готово! У нас есть RoleID и SecretID, ничего не мешает нам извлечь Secret из Vault ☺️