k8s (in)security

2022-04-01 09:02:12 Не знаю как вы, но я парой люблю возвращаться к какой-либо старой/устоявшейся теме и переосмыслять ее необходимость/важность в текущих реалиях – время идет, все меняется. И так я тут последнее время все раздумывал: "А настолько ли важен Kubernetes Audit Log сегодня для безопасности?!" ...

Пока я прихожу к выводу, что на сегодняшний день не так уж и важен (сразу оговорюсь что речь идет о зрелых компаниях)! Мои аргументы:
1) Kubernetes ресурсы выкатывает не человек, а какая-то система (‘GitOps’ подходы и операторы и тд) выкатки в компании из Git по тем или иным правилам и в log мы всегда видим в принципе что действия совершены он аккаунта данной системы (часть замысла аудита теряется - установка авторства). Так можно либо из Git узнать кто какие изменения делал или обогатить Kubernetes ресурс теми или иными annotations для создания контекста операции.
2) Благодаря PolicyEngine мы можем очень просто и гибко аудировать, и даже предотвращать любую нежелательную операцию в момент ее возникновения - AdmissionReview содержит всю необходимую информацию. В случае Kubernetes Audit Log каждый раз при изменении политики аудита нужно перезапускать kubernetesapi. А в случае managed Kubernetes так мы вообще, как пользователи не можем влиять на политику аудита и, на пример, можем аудировать действия с CustomResources вообще (часть замысла аудита теряется - не полнота картины) ... Не зря же в CNCF много усилий вложил в концепцию, описанную в "Kubernetes Policy Management Paper".

Если у вас есть аргументы За или Против моих, то с удовольствием почитаю в комментариях, возможно что я что-то упускаю из виду.

P.S. Отдельно отмечу, что не стоит это воспринимать как призыв к отказу от Kubernetes Audit Log. Безопасность вещь комплексная ;) Открыть/Комментировать

2022-03-31 08:40:33 Talos это специализированная OS для Kubernetes и она наконец достигла версии 1.0! Отличительные моменты данной OS:
- minimal
- secure
- immutable

И при этом все управление идете через API - никаких shell или interactive console на Nodes, а также никаких скриптов, а только декларативные конфиги и все! При этом система отлично поддерживает Cluster API [1,2]! Зачем вообще в 2022 ходить на Nodes и тратить время инженеров, когда проще и быстрее поднять чистую Node и перекатить нагрузку туда?!

Я честно не знаю компаний, которые уже используют Talos (если используете пишите в комментариях), но общаясь с инженерами ведущих IT-компаний, могу сказать, что за проектом они пристально наблюдают ;)

Облачные гиганты уже используют свои собственные OS: Container-Optimized OS у Google, Bottlerocket у Amazon. Как по мне Talos это шаг в туже сторону, но еще дальше и по направлению к Kubernetes.

Live demo можно посмотреть в этом видео. Открыть/Комментировать

2022-03-30 08:13:23 Буквально вчера вышел замечательный whitepaper “All About That Base Image”, который посвящён безопасности популярных базовых образов - image security если хотите и уязвимостям в них.

Авторы в документе задаются вопросом: "Is it possible, though, to have a base image without vulnerabilities?" и помогают грамотно подойти к выбору базового образа для ваших контейнеров. Основными критериями выбора/поиска являются:
- Наличие малого или нулевого количества известных уязвимостей в образе
- Плюсом будет наличие SBOM
- Плюсом будет наличие цифровой подписи

Все это в первую очередь помогает бороться с "шумом" от сканеров уязвимостей. Ведь никто не хочет разбираться с тысячами уязвимостей и еще при том, что разработчики далеко не сразу буду браться за их устранение. Открыть/Комментировать

2022-03-01 09:00:25 Для некоторых может быть новостью, но

kubeclt -n get all - не работает!

То есть вы получите не полную - не правильную картину. И при этом это совсем не новость и не сенсация в Kubernetes сообществе — это уже неоднократно обсуждалось [1,2].

Имея не правильную картину происходящего в кластере, можно принять не правильные решения и тем самым привести к сбоям, проблемам и долгим отладкам в недоумении от происходящего. На пример, вы не будете видеть кастомных NetworkPolicy или ресурсов от Istio и долго упорно отлаживать сетевое взаимодействие ...

Одним из решений проблемы может быть krew плагин для kubectl под названием ketall/get-all.

За более детальным погружением в проблему и другими возможными решениями рекомендую обратиться к моему выступлению "Kubernetes Resource Model (KRM): Everything-as-Code"

503 viewsD1g1, 06:00

Открыть/Комментировать

2022-02-28 08:56:26 Kubernetes Security SIG и Policy WG зарелизили новый документ, который касается вопроса контроля автоматизации, так и безопасности происходящего в кластере, под названием "Kubernetes Policy Management Paper".

По сути это набор best practices для управления конфигурациями Kubernetes, используя политики (привет Policy Engines!). Документ освещает два момента:
1) Какие проблемы Kubernetes политики могут помочь решить
2) Как Kubernetes политики могут быть реализованы

В итоге, обсуждается эталонная архитектура для управления политиками в Kubernetes с описанием каждого необходимого компонента.

Без внимания не остается Runtime политики, покрывающие происходящие уже внутри контейнеров и дополняющие Policy engines.

Документ MUST READ для всех. Без подобного построить грамотную безопасность в K8s невозможно на мой скромный взгляд. Открыть/Комментировать

2022-02-25 09:00:06 Проект vulnerability-operator это логическое продолжение проекта sbom-operator, от того же автора. Если sbom-operator отвечает за формирование SBOM, то vulnerability-operator берет результаты первого и по расписанию сканирует его на известные уязвимости сканером Grype.

На текущий момент данный оператор берет SBOM из git-repository сканирует его и результат отдает в JSON-file через endpoint и/или как Prometheus метрики.

С автором я обсудил еще один вариант совместной работы этих операторов, и он его уже занес в планы. А именно такой:
1) sbom-operator создает результат своей работы в виде ресурса PolicyReport и связывает его по ownerReference с микросервисом (по аналогии как это делает Starboard-operator).
2) vulnerability-operator реагирует на появление нового PolicyReport и переодически его сканирует и обновляет информацией о известных уязвимостях.

В итоге это позволит полностью реализовать Kubernetes Resource Model (KRM), в которой всегда все о системе можно узнать из YAML ресурса =) Открыть/Комментировать

2022-02-24 08:58:21 Всем привет!

Напомню что ещё есть возможность купить билеты на ZeroNights 2022 по сниженной/ранней цене и подать свой доклад на конференцию через CFP. Если кто-то сомневается или делает это впервые, то я могу помочь и все подсказать ;)

И конкурс!
В комментариях к этому посту напишите историю из вашей практики или друзей друзей про fails в области ИБ при работе с Kubernetes.

Для затравки я напишу две (согласовано с действующими лицами) вне конкурса!

3 наиболее интересные на мой взгляд истории получат билеты на ZeroNights 2022!

Победителей объявлю 28 февраля ;) Открыть/Комментировать

2022-02-22 09:11:43 Сheckov прекрасный инструмент, который позволяет управлять и анализировать IaC таких платформ как Terraform, Kubernetes, Helm и многих других. Он активно продвигает концепцию Policy-as-code.

Его можно использовать как CLI для сканирований на локальных машинах разработчиков или даже как часть IDE или более обыденно в CI pipelines через GitHub Actions. Но все равно остаётся риск что злоумышленник обойдет эти этапы. И тогда последним бастионом защиты остается Validating Admission Controller!

Проект Whorf это как раз такой контроллер на базе Сheckov.

Мое мнение:
1) Whorf проигрывает любому специализированному Policy Engine для k8s
2) Kyverno и OPA Gatekeeper также умеют в CLI
3) Вы врятли его даже попробуете так как для запуска надо получать API key от вендора

Многие вендоры сегодня пытаются сделать универсальные комбайны, но отлично видно, как они сильно проигрывают специализированным решениям в той или иной области. Все это скорее чтобы закрыть пустоту, а не решить проблему Открыть/Комментировать

2022-02-21 08:51:19 Все больше встречаю компаний, которые задумываются или уже начинают экспериментировать c Service Mesh в своих инфраструктурах как для задач связанных с информационной безопасность, так и нет. Но далеко не все на сегодняшний день представляю возможные вариации реализаций Service Mesh и их плюсы и минусы.

В статье "eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay" мне понравилось как рассматривается текущая картина в сравнении да еще и с учетом технологии eBPF. В итоге рассматривается 4 архитектуры:

1) Sidecar proxy (service proxy)
2) Shared proxy per node
3) Shared proxy per service account (per node)
4) Shared remote proxy with micro proxy

Все это при этом сравнивается по 4 пунктам:
- Memory/CPU overhead
- Feature isolation
- Security granularity
- Upgrade impact

И не могу не сказать о статье "How eBPF will solve Service Mesh - Goodbye Sidecars" - там речь о еще одной архитектуре:
5) eBPF Accelerated Per-Node Proxy

2 важные цитаты про eBPF в этом контексте из статей:
1) " this would be quite difficult and may not be the right approach. eBPF is an event-handler model that has some constraints around how it runs."
2) "For some use cases, a proxy is still needed."

Выводы делайте сами с учетом ваших потребностей ;) Открыть/Комментировать

2022-02-18 09:05:30 В общем, не важно какой у вас стек, главное чтобы вы видели, понимали как у вас это устроено, взаимосвязано и кто на что влияет.

В связи с ростом сложности и запутанности систем, на первый план выходит observability. А то мало ли на чем там у вас это все держится ;)

Это как надежности, так и безопасности системы касается.

Всем хорошей пятницы и выходных! Открыть/Комментировать