Всем привет!

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 ☺️

Привет!

У Peirates вышло обновление (v1.1.8), в котором добавили интересную функцию:

🍭 Сбор секретов из файловой системы node // harvest secrets from the node filesystem

Если же вы не слышали про Peirates, то его можно описать как инструмент, использующийся при анализе защищенности кластеров Kubernetes. Краткое описание приведено тут.

Кроме инструментария на сайте Inguardians (авторов проекта) можно найти много интересных материалов – статьи в блоге, вебинары и ссылки на полезные материалы при изучении Kubernetes и его безопасности ☺️

Привет!

CNCF, знаменитая своей landscape-картинкой, иногда выпускает Radar – «точку зрения» по различным решениям. Информация группируется по категориям:
🍭 Adopt. Инструменты, «признанные community», которые используются и приносят пользу
🍭 Trial. Community использует решение, к ним можно «присмотреться»
🍭 Assess. «Зарекомендовавшие себя» технологии, у которых есть большой потенциал

В сентябре 2021 года вышел CNCF Radar, посвященный DevSecOps, распределение получилось следующим:
🍭 Adopt. Istio, SonarQube, Artifactory, HashiCorp Vault, Calico/Tigera, Terraform, ArgoCD, OPA
🍭 Trial. XRay
🍭 Assess. Cilium, Harness, Sonatype Nexus, HashiCorp Sentinel, GitHub Actions, Linkerd, Trivy

В самом Radar явно сказано, что перечень ДАЛЕКО не полный. И, отчасти, это своего рода проблема – существует множество решений, которые решают локальные задачи и «угнаться за всеми» просто не всегда получается.

Если хочется больше информации – можно посмотреть webinar от CNCF, в котором приводятся рассуждения на вышеуказанную тему.

Привет!

Потрясающий Learning Path от Ivan Velichko на тему контейнеров. Наверное, как у большинства, путь Ivan начался с «хм, легковесная виртуальная машина, в которую можно добавить python-приложение». Все оказалось несколько иначе!

Ivan структурировал свой path следующим образом:
🍭 Linux Containers – low-level детали, рассуждения на тему почему Containers не являются Virtual Machines, а скорее Isolation (namespaces) и Restriction (cgroups, Linux Caps, seccomp)
🍭 Container Images – что это такое и зачем они нужны, какие задачи решают (да, контейнер можно запустить без образа, а вот создать (build) образ без контейнера – не получится)
🍭 Container Managers – чем и как помог Docker в свое время
🍭 Container Orchestrators – Kubernetes и Ко
🍭 Non-Linux Containers – да, есть и альтернативы!

В статье приведено множество информации, описывающей принципы работы (при этом не поверхностно, а достаточно детально) и множество интересных мыслей автора! Приводятся ссылки на его статьи по теме, а также материал, который пригодится для указанного Learning Path. Крайне рекомендуем к прочтению или, хотя бы, добавлению к «закладки» 😊

P.S. Сайт Ivan Velichko доступен по ссылке. Там есть много-много-много всего интересного! Помимо сайта у Ivan есть свой канал в Telegram!

Привет!

Недавно CNCF анонсировала новую сертификацию – Kubernetes and Cloud Native Associate (KCNA). Сертификация будет подтверждать понимание базовых основ Kubernetes и Cloud Native. Экзамен будет представлять из себя тест с множественным выбором ответов.

Ключевые темы, которые надо знать:
🍭 Kubernetes Fundamentals (46%). Ресурсы, архитектура, API, контейнеры, планировщик (scheduler)
🍭 Container Orchestration (22%). Основы оркестрации, runtime, безопасность, сеть, Service Mesh и хранилище (storage)
🍭 Cloud Native Architecture (16%). Основы Cloud Native архитектура, autoscaling, serverless, community и governance, стандарты
🍭 Cloud Native Observability (8%). Телеметрия и observability, Prometheus и управление затратами
🍭 Cloud Native Application Delivery (8%). Основы application delivery, GitOps и CI/CD

Точный срок запуска KCNA пока что неизвестен, планируемое время – конец 2021 года. Экзамен может стать отличной отправной точкой для изучения сред контейнерной оркестрации и дальнейшего получения сертификаций: CKA, CKAD и CKS 😊

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

Pod-reaper – название говорит само за себя! Утилита (контейнер) для «убийства» pod в соответствии с заданными правилами!

Конфигурация Pod-reaper осуществляется с использованием переменных окружения. Вариативность неплоха, например: NAMESPACE – где искать «жертв»; EVICT – не убиваем, а выселяем (eviction); MAX_PODS – ограничиваем максимальное количество «жертв» и многие другие!

Но самое интересное – это правила! Доступен следующий набор:
🍭 Chaos Chance – убийство «случайной жертвы». Скорее всего отсылка к Chaos Engineering
🍭 Container Status – убиваем pod с определенным статусом, например, CrashLoopBackOff, ErrImagePull и т.д.
🍭 Duration – если жертва работает (run) больше положенного срока – она становится кандидатом на убийство!
🍭 Unready – похоже на предыдущее, только призывом к убийству является срок «неготовности» (unready)

Жертва будет убита, только если она соответствует всем настроенным правилам. Логический «OR» сделать тоже можно – запустив несколько Pod-reaper на кластере.

Помимо этого можно настроить уровень логирования. Доступны: Debug, Info, Warning, Error, Fatal and Panic.

С точки зрения возможностей решению требуется [‘list’, ‘delete’] на [‘pods’] и все это в качестве ClusterRoleBinding или для конкретного Namespace.

P.S. Всем прекрасного вечера и отличных выходных! 😊

Привет!

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

Устанавливается просто – через deployment, конфигурация которого приведена в repo. Можно запускать утилиту с определенной Service Account. В repo приведен пример манифеста, в котором можно посмотреть на полномочия, которые требуются для Kubernetes Pod Inspector:

rules:
- apiGroups: [""] # 
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "watch", "list"]

У утилиты есть графический интерфейс, который показывает необходимую информацию:
🍭 Перечень pods, с дополнительной информацией (status, age, CPU, memory, IP и т.д.)
🍭 Отображение файлов и папок внутри pod/container
🍭 Перечень процессов, которые запущены внутри pod/container

Кроме просмотра можно, например, скачать какой-нибудь файл из pod/container 😊

Всем привет!

Процесс поиска ошибок в deployments может быть трудоемким, особенно если не знаешь куда посмотреть...

Для решения этой проблемы ребята из learnk8s подготовили отличную блок схему, которая может помочь разобраться или подскажет "куда смотреть"!

Возможно, что вы ее уже видели раньше, но есть хорошие новости - она обновляется, по ссылке доступна версия от ноября 2021 года! А если не видели - рекомендуем обратить на нее внимание 😊 Схему можно скачать в PDF и/или PNG формате!

Привет!

Часто, когда говорят про OPA и K8S вместе, на ум приходит Gatekeeper и его возможности по управлению запуском сущностей на основе REGO-правил!

А что, если использовать OPA чуть раньше, например, в CI-процессе (shift left security)? Это вполне возможно, ведь OPA и Gatekeeper это не одно и тоже: Open Policy Agent дает нам возможность писать правила и проверять «что-то» на соответствие этим правилам (a software component that allows users or other systems to query policies for decisions).

В статье приводится простой и наглядный пример использования OPA в GitHub Actions:
🍭 Создаем политику, которая анализирует Kind на «пустоту», «строку» и запрещает «:latest»
🍭 Тестируем это локально, используя OPA eval
🍭 Переносим это в CI (да, в статье это GitHub Actions, но такой подход можно реализовать где угодно)

На выходе получаем еще одну точку анализа манифестов на соответствие политикам информационной безопасности, еще до их deploy (пусть даже и в тестовой среде). В сочетании с Gatekeeper можно добиться интересной синергии 😊

Привет!

- Хэй, чтобы обезвредить бомбу тебе надо ввести ЛЮБУЮ корректную tar-команду. 10 секунд… Гуглить нельзя!
- Извини. Мы обречены…

Комикс из repo отлично иллюстрирует знакомую многим ситуацию: вроде помнишь, как пишется команда, но то ключ забудешь, то какие параметры нужны…

Если у вас не так, то вы – молодец! А если узнали себя – не переживайте, вы не одиноки! Ведь не зря появился проект Cheat (с 8,4к «звезд» на GitHub). Суть его проста – напоминать об основных Linux-командах.

Например, cheat curl выдаст нам:
// To download and rename a file:

curl <url> -o <outfile>

// To download multiple files:

curl -O <url> -O <url>

// To download all sequentially numbered files (1-24):

curl http://example.com/pic[1-24].jpg

// To download a file and pass HTTP authentication:

curl -u <username>:<password> <url>

// To download a file with a proxy:

curl -x <proxy-host>:<port> <url>

Сам по себе Cheat не будет работать, ему нужны cheatsheets, которых огромное количество, и вы точно найдете нужное! Можно настроить под собственные нужды и пользоваться. Подробнее о том, как это сделать показано в repo.

И все же ) А вы ошибаетесь/забываете пусть даже и любимые команды? Пишите в комментариях!

Привет!

Vault-CRD – custom resource definition для Kubernetes, который позволяет упростить управление секретами с использованием HashiCorp Vault. CRD работает с Docker Pull Secret (Docker CFG), Ingress Certificates и JKS Key Store/

Возможные сценарии:
🍭 Создание секрета
1. Vault-CRD получает события для новых Vault-ресурсов
2. Vault-CRD запрашивает секрет из HashiCorp Vault
3. Vault-CRD создает Secret
🍭 Обновление секрета
1. У Vault-CRD есть scheduled задача по просмотру созданных им Secret
2. Указанный Secret сравнивается с тем, что есть в Vault и обновляется при необходимости

Аутентификация самого Vault-CRD в HashiCorp Vault возможна с использованием Token (для тестов подойдет, а дальше лучше не использовать из-за проблемы Secret Zero) или с использованием Kubernetes Authentication (предпочтительный вариант, проверкой занимается условно-доверенная третья сторона).

Доступны следующие типы секретов, которые могут быть сгенерированы при помощи Vault-CRD: Key/Value, PKI, Cert. Поддерживаются следующие версии Secret Engines Vault: K/V1 и K/V2.

Еще одна интересная функция: Change Adjustment Callback – можно сделать так, что deployment будет пересоздан при изменении Secret. Как обычно, больше подробностей можно посмотреть в repo и в документации.

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

Всем привет!

Недавно вышло обновление Gatekeeper до версии 3.7.0. Одним из интересных нововведений стала возможность делать mutating-операции.

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

В начале статьи приводится краткое описание mutation, состава политик:
🍭 Mutation scope – то, что мы хотим поменять
🍭 Intent – поле и значение, которое подвергнется изменению
🍭 Conditions – условия, при которых изменение произойдет

Далее в статье создается несколько простых политик, которые добавляют labels в спецификацию pod или меняют значение securityContext.Privileged в значение false.

Общую информацию про admission controllers можно почитать тут, больше информации про обновления в Gatekeeper предоставлено вот тут.

Важно (!) Функционал все еще находится в стадии Alpha и его НЕ рекомендуется использовать в production средах.

Привет!

И причем тут канарейки? Все так, речь пойдет про deployment strategies!

В статье, на примере Kubernetes, рассматриваются такие стратегии как:
🍭 Rolling Update. Один за одним переводим pod’ы старой версии на pod’ы новой версии, сохраняя доступность целевого ресурса. Да, при этом часть пользователей увидит новый функционал, а часть – старый
🍭 Recreate. «Жесткий вариант» - убиваем старую версию и «раскатываем» новую. Да, будет некоторый downtime
🍭 Blue-Green. Существует 2 версии – Blue (текущая) и Green (вот-вот, почти). Но активной является только одна – Blue. Как только все тесты в Green успешно пройдены – переключаем трафик!
🍭 Canary! А вот и она! Новой версии ПО предоставляется небольшой трафик для оценки нововведений со стороны пользователей и/или поиска ошибок/недоработок. Если «Ок» – увеличиваем поток трафика, если нет – дорабатываем и разбираемся с ошибками. Для тех, кому все-таки интересно при чем тут канарейки – грустная статья

Помимо графических схем, поясняющих ту или иную deployment-strategy в статье есть примеры для самостоятельного воспроизведения и технические подробности того, что «происходит под капотом» ☺️

Привет!

Разработка helm-чартов не самый простой процесс, особенно с точки зрения «отладки».

Где-то «съедет» форматирование, где-то забудешь указать необходимые данные, где-то ошибешься с типом (например, «словарь» вместо «списка» и т.д.)

Если это Вам знакомо, то рекомендуем обратить внимание на статью «Kubernetes Helm Charts Testing».

В ней рассматриваются способы проверок helm-чартов и, конечно же, автоматизация:
🍭 KubeEval. Наверное, один из лучших инструментов по теме. Позволяет сопоставить генерируемые helm-chart’ом манифесты со спецификацией Kubernetes и показать, где ошибка/чего не хватает
🍭 Добавим немного ИБ-проверок? Запросто! Conftest! Framework, который позволяет писать OPA-политики на REGO и проверять манифесты на соответствие (кстати, такое можно делать и просто при помощи OPA, об этом мы писали вот тут)
🍭 А что делать если пользователь некорректно указал значение в Values (например, опечатался, в CPU: 250Mi)? Можно использовать инструмент Schema Validation, который позволяет проанализировать данные Values и указать на ошибки
🍭 Тестирование? Есть и такое – helm-unitetst и kubetest...

Вариантов много. Возможно, что не все они нужны, но, как минимум, KubeEval уже значительно облегчит жизнь 😊

Важно (!): в статье не рассматривается процесс написания helm-чартов и применимые лучшие практики, а только способы поиска ошибок

Привет!

Helm позволяет удобно структурировать все, что нужно для deploy и управлять изменениями.

Бывает, что при первом deploy надо создать секреты, используемые для аутентификации сервисов. Это можно сделать "вручную", а можно чуть иначе!

В статье описаны возможные способы автогенерации секретов с использованием возможностей helm:
🍭 Использование генераторов случайных чисел, поддерживаемых Helm
🍭 А если это не первый deployment и секрет уже был создан? Не вопрос, можно использовать "условное" (conditional) создание секрета - несколько if и lookup. Helm проверит существование секрета и создаст его, только если не обнаружит данных
🍭 Явное задание пользователем секрета в Values, но так лучше не делать, если только для тестов

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

Привет!

Observeability - важный аспект, который помогает нам понимать что происходит в кластере и может быть полезен при поиске ошибок.

У Kubernetes есть сущность - Event - которая помогает более точно понять, что (не)произошло и почему.

В статье автор описывает что это такое и чем это может быть полезно на примере:
🍭 Failed Events. Например, pod не был создан или проблемы в работе node
🍭 Evicted Events. "Переселение" нагрузок не всегда является проблемой, но лучше понимать, что стало причиной
🍭 Storage-Specific Events. Все, что связано с использованием Storage
🍭 Scheduling Events. Почему не получилось выбрать node для нагрузки
🍭 Node-Specific Events. Проблемы с nodes: недоступность, перезапуски и т.д.

Важно помнить, что Events бывают разные: Normal, Information и Warning. Не все из них одинаково полезны и рекомендуются к анализу.

В завершении статьи автор показывает, как можно получить доступ к рассматриваемому объекту и как можно фильтровать запросы.

Всем привет! Если вы ещё не погрузились в тематику защиты контейнеров или только начинаете это делать, мы подготовили небольшое обзорное видео в рамках нашей рубрики Security Small Talk.

Итак, о чем вы узнаете из ролика?
🍬 Что именно нужно защищать и почему обычных СЗИ для этого мало.
🍬Как хакеры атакуют Kubernetes, чем опасны подделки запросов к kube-apiserver или kubelet и что будет, если киберпреступник заберётся внутрь контейнера.
🍬 Готовый фреймворк для защиты кластера на всех уровнях — от узла до контейнера.
🍬Верхнеуровневое знакомство с Open Source и коммерческими решениями.

Ролик доступ по ссылке.