Всем привет!

Пока мы морально готовимся к «рабочим выходным», миримся с ушедшим бабьим летом и промокаем под постоянными дождями, наступила пятница!
И в этот день судьба решила порадовать нас и подарить чудесный солнечный день!
А мы порадуем вас интересной фичей - от команды хорошо знакомого нам 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 ☺️

Привет!

У 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 формате!