Сегодня пост из категории мысли в слух.

За последнее время появилось достаточно много статических анализаторов ресурсов (Terraform, Helm, Kubernetes и т.д.) для проверки их в репозитариях, которые по заветам GitOps являются единственным источником правды. Это могут быть проверки как на best-practices, так и на security.

Но есть ли уверенность в том, что мы увидим тоже самое после выкатки этих ресурсов? Ответ: совсем не обязательно - статическая и динамическая картина могут отличаться.

В процессе выкатки, MutatingAdmissionWebhook может внести туда множество изменений. В качестве примера: переменные окружения, init и sidecar контейнеры, изменение LimitRange и ResourceQuota, установку privileged режима, монтирование директорий и т.д. Это может быть как с благими, так и с вредоносными намерениями (ну или для обхода ограничений в угоду более быстрой разработки).

Может помочь ValidatingAdmissionWebhook, но не стоит забывать, что если условие было добавлено спустя какое-то время, то в инфраструктуре уже могут существовать ресурсы, не подходящие под его условия. В одном из своих постов я уже писал, что возможно и создание вредоносных ValidatingAdmissionWebhook. Создание вредоносного MutatingAdmissionWebhook злоумышленником/инсайдером или просто не очень квалифицированным сотрудником также возможно.

Динамическая природа Kubernetes вносит свои коррективы в жизнь ресурсов и это надо учитывать, как и строгий контроль того кто и что делает с помощью MutatingAdmissionWebhook и ValidatingAdmissionWebhook.

kubestrike - инструмент на Python для идентификации security misconfigurations (по сути своей слабых и не безопасных настроек) в Kubernetes (как self-hosted, так и Amazon EKS, Azure AKS, Google GKE и т.д.).

Есть поддержка двух режимов сканирования:
- Аутентифицированное (нужен токен с read-only привилегиями)
- Не аутентифицированное (возможно в случае наличия анонимного доступа в кластере)

Текущие возможности:
- Анализ IAM в кластере, привилегированных субъектов в кластере , контейнеров, сервисов, Pod Security Policies, Network Policies
- Возможность запускать команды в контейнерах
- Предоставляет информацию о потенциальных возможностях поднятия привилегий

Все проверки можно поискать по коду по паттерну [+] Scanning for их достаточно много. Сам инструмент по своей сути просто yet another tool для Kubernetes, но может кому и приглянется.

P.S.Вспомнил как еще в бытность редактором рубрик "X-Toolz"и "Security soft" в журнале "Хакер" приходилось к выпуску готовить по 15-30 tool

"Improving Kubernetes and container security with user namespaces"

Наверно лучшая статья, которую я читал по безопасности Kubernetes в этом году.

Из этой статьи вы узнаете, что такое и зачем нужен user namespace, как он влияет на безопасность контейнеров. И самое интересное, что необходимо изменить со стороны файловой системы, Container Runtime и Kubernetes volumes, чтобы это наконец смогло заработать в самом Kubernetes. Работа кипит и за ней можно следить тут.

Статья просто MUST READ, в процессе чтения раскрывается много не самых простых и очевидных базовых моментов работы контейнеров, который очень важны для понимания.

Дополнительно можно почитать как к таким изменениям подошел Netflix в своей системе оркестрации контейнеров Titus.

Всем, привет!

Сегодня в преддверии праздников хочется рассказать и сказать спасибо за помощь и содействие моим друзьям и товарищам с других Telegram каналов, за которыми я слежу и с которыми мы хорошо общаемся:
- Технологический Болт Генона
- DevSecOps Talks
- CloudSec Wine

В наше время нет проблем с наличием информации, есть проблемы с ее фильтрацией - нахождением полезной и нужной информации в море маркетинга и рекламы. Читайте разные каналы, анализируйте информацию - помните, что у вас всегда есть своя голова на плечах ;)
Особенно это важно для Cloud Native инфраструктур/сервисов/приложений, где все очень разное, разнообразное и то, что отлично работает у одних, может быть совершенно не применимо у вас.

Всем, привет!

Ребята с не малоизвестного ресурса Habr пригласили меня сегодня в 19:00 (Мск) поучаствовать в их видкасте.

Тема:
Инфобез как война роботов

Описание:
Многие уловили момент, когда информационная безопасность перешла из стадии человек против человека в стадию человек против машины, но пропустили, когда же инфобез стал войной роботов. А между тем фактически вся ИБ уже работает на ИИ. Так когда это произошло? И какие форматы предиктивной защиты подарило нам машинное обучение? Чем теперь занимаются освободившиеся люди? Как дальше будут эволюционировать машинописные угрозы? Обсуждаем все, что касается настоящего и будущего инфобеза.

Online можно смотреть в VK, Facebook и YouTube.

Kyverno - Kubernetes Native Policy Management.

Проект также как и OpenPolicyAgent (OPA) находится под эгидой CNCF, но при этом известен/распиарен куда меньше. OPA мне всегда нравился, но при этом меня смущало в нем необходимость использование/знание Rego (считай еще одного ЯП). Это можно сказать прям ломало Kubernetes Native подход ...

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

Если их сравнивать, то OPA, конечно, способен покрыть не только Kubernetes (но нужно ли вам это вообще?) и его язык дает более широкие возможности (переменные, хранилища ресурсов и т.д.) (но я с ходу смог придумать только 1 такой кейс ...).

Но и у Kyverno есть свои фишки можно делать не только операции Validating, но и Mutating и Generating с ресурсами. Конечно, при использование последних двух опять GitOps в пролете, но может быть очень полезно ;) При этом они оба умеют сканировать ресурсы, которые уже работают в системе (у одного это называется Audit у другого Background Scans).

Лично мне ближе Kyverno как минимум тем, что он сохранят единый язык общения между Dev, Ops и Sec командами и они продолжают понимать друг друга. Очень важно, чтобы безопасность не была 'блокером', а прозрачно встраивалась для всех.

Контейнеры versus VM

В рамках своего канала я уже не однократно рассказывал, что в качестве container runtime в Kubernetes можно использовать VM. Изучая данное направление, следя за их развитием, я все больше убеждался в крутости использования VM, базирующейся в первую очередь на их высокой изолированности (и безопасности).

НО если посмотреть на них не с точки зрения безопасности, то можно заметить как очевидные, так и не очень ограничения и недостатки. Во-первых, это определенные требования к окружению/железу - не везде VM запуститься (тут еще стоит помнить про разные типы виртуализации full, paravirtualization, nested) и не любой сервис вам даст это сделать. Во-вторых, очень сильную изоляцию чаще рассматривают не в контексте security, а в контексте multitenancy, что далеко не всем вообще надо. В-третьих, сильно падает (исчезает?) observability происходящего внутри контейнеров. Если в случаи классических контейнеров для вас это такие же linux процессы просто с определенными свойствами, то в случаи VM это несколько общих процессов, представляющих для вас "черный ящик". И наблюдать за происходящим там можно только за тем, что вы сами или разработчики VM запрограммировали для передачи наружу в систему мониторинга, а любимые и проверенные инструменты уже не помогут.

Третий пункт лично для меня (как в прочем и для ИБ) наиболее критичный. Наличие любого "черного ящика" в системе затрудняет как обнаружение, так и расследование инцидентов.

P.S. Уверен есть и другие ограничения и недостатки - можно их собрать в комментариях.

BPFBox - Exploring process confinement in eBPF.

Очень интересный академический проект, о котором вы могли слышать на eBPF Summit 2020 в докладе "bpfbox: Simple Precise Process Confinement with KRSI and eBPF". Он точно не готов для использования в prod окружении. Там много чего не хватает, да и требования к ядру > 5.8 (таких ядер в prod я ни у кого еще не видел). Такая высокая версия ядра обусловлена требованием наличия KRSI (Kernel Runtime Security Instrumentation), который в upstream появился только с 5.7, и типу ringbuf map (5.8+).

Сам проект использует eBPF и позволяет ограничивать user-space и kernel-space вызовы в соответствии с описанной политикой. Можно представить себе это как будущее sandboxing и prevention систем. И можно это использовать как для standalone приложений, так и для контейнерный приложений в Kubernetes, без вреда стабильности работы и сложности SELinux или AppArmor.

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

Подробнее о проекте можно узнать из документа "bpfbox: Simple Precise Process Confinement with eBPF".

Есть такой замечательный инструмент как osquery. Он превращает вашу ОС на базе Linux, macOS, Windows, FreeBSD в реляционную БД (набор SQL табличек) и позволяет запрашивать из них данные о системе (пользователи, железо, процессы, ФС и т.д.) по необходимости или с определенной периодичностью, что может быть полезно для мониторинга или аналитики. У инструмента даже есть своя конфа QueryCon, где ее пользователи делятся своим опытом и наработками. Первая версия появилась в сентябре 2014.

В ноябре 2020 года появился проект cloudquery. Он был вдохновлен osquery и terraform и является compliance-as-code инструментом. Он также представляет вашу облачную инфраструктуру в виде SQL или Graph (Neo4j) базы данных. Сейчас инструмент поддерживает:
- AWS
- Azure
- GCP
- Okta
- Kubernetes (alpha стадия)

O Kubernetes инструмент знает только информацию о Pods и Services и пока все. Получает он это через Kubernetes API. Для AWS есть готовый AWS CIS policy pack.

P.S. kube-query экспериментальное расширение для osquery для поддержки Kubernetes + пример его использования.

В связи с нашумевшей атакой на SolarWinds очень остро стал вопрос с атаками на цепочку поставок (supply chain).

Давайте повернем это все в наш контекст - контекст приложений для Kubernetes. Что мы имеем:
1) Open Source код - а кто его сегодня не использует? Начиная от ваших собственных разработок, заканчивая инструментов/тулов что вы используете в готовом виде и коммерческих решений.
2) Образы контейнеров - тут сходу вспоминаются истории как на DockerHub залиты образы с backdoors и вредоносным кодом.
3) k8s ресурсы - такая своего рода обертка над контейнерами, которая также позволяет и внедрить что-то не очень заметно, так понизить уровень безопасности самого контейнера.
4) Helm чарты - наверно вершина этой пирамиды, призванная максимально упростить процесс установки приложений в кластер. И часто вы их читаете полностью что там написано? И легко ли это вообще сделать? Скорее нет ;)

В ситуации с SolarWinds был заражен их продукт Orion (это кажется платформа мониторинга). Долгое время вредоносная активность от этого решения была не замечена, а все из-за того что никто и не знал как оно работает (что может делать, а что нет - считай черный ящик). А также относились к нему как к доверенному компоненту системы - а в наше время без ZeroTrust подхода уже никуда.

В случае Kubernetes инфраструктуры при правильном подходе такое можно было бы обнаружить без супер усилий. На помощь приходит и observability, visibility в контейнерах и иммутабильность образов контейнеров с NetworkPolicy, PodSecurityPolicie для ZeroTrust.

Выложили запись workshop'а на тему "Applied Defense On Docker And Kubernetes" продолжительностью 2,5 часа с конференция HackInTheBox (язык английский). Очень люблю данную конференцию, сам там выступал и хорошо общаюсь с их главным организатором.

В самом workshop’e его участники по мне так могут узнать только основную базу - подробнее можно посмотреть agenda в программе:
- Docker
• Kernel namespaces
• Kernel capabilities
• Mandatory Access Controls
• Container UID & GID
• Userns-remap
• Distroless

- Kubernetes
• API Authentication
• API Authorization
• Security Context
• Security Policies
• Network Policies

Так что я не согласен с утверждением автора: "Students will walk away having learned the advanced security features of Docker & Kubernetes."

И сам workshop по мне полностью повторяет выступление автора с конференции BlackHat USA 2020 под названием "Defending Containers Like a Ninja: A Walk through the Advanced Security Features of Docker & Kubernetes", свое мнение о котором я уже писал ранее тут.

Заранее сказать по какой причине Node может решить завершить свою работу нельзя (а с ним и ваши сервисы). Это могу быть как легитимные причины или просто какие-то технические проблемы, так и намеренные действия злоумышленника или неумелые действия сотрудника. Поэтому надежность работы системы и ее безопасность вещи не разделимые.

А речь сегодня пойдет о ресурсе `PodDisruptionBudgets (сокращенно `PDB), который может помочь избежать простоя в работе Kubernetes-кластера. Чаще всего вы, конечно, найдете упоминание данного ресурса при описании Zero Downtime Deployment или Upgrade кластера. Данные ресурс описывает квоту неработающих Pods. Важно также понимать отличия принципов работы PodDisruptionBudgets и Deployment.

По мне это он идет в туже копилку что и LimitRange и ResourceQuota, о которых я писал ранее.

Я много пишу о различных механизмах Kubernetes, инструментах и технологиях. Но все это не будет играть большого значения, если внутри компании не построены правильные процессы и создана культура разработки.

Ни один инструмент вам не поможет, если он не используется или результат его работы попросту игнорируется. Также куда больше бед вам может принести, хождение разработчиков на prod кластера, чем не соответствие best-practices. При этом разработчик (или кто-то другой) не только могут нанести вред по неосторожности или невнимательности, но и быть скомпрометированы и сразу подарить атакующему билет в prod кластер.

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

Как наверно вы уже знаете, что от PodSecurityPolicy откажутся в будущих версия Kubernetes. Более точно данный тип ресурса перейдет в статус deprecate в версии 1.21, а будет УДАЛЕН в версии 1.25.

Разработчики сторонних решений уже предлагают присмотреться к OPA или к Kyverno (писал о нем недавно тут).

Я рассуждал на тему что станет с PSP и не рассматривал вариант, что от него полностью откажутся, а реализацию подобной функциональности возложат на сторонние решения. Но на самом деле такое очень даже возможно! По сути, PodSecurityPolicy это просто Admission Controller, который на выбор вы можете использовать любой или не использовать вообще. Почти аналогичная картина и с сетью (CNI), стороджем (CSI) и container runtime (CRI) - только их вы обязаны использовать ;)

“Bad Pods: Kubernetes Pod Privilege Escalation”

Статья о 8 не безопасных конфигураций для Pod и соответствующие способы для повышения привилегий. Предполагается что у атакующего есть или возможность создать Pod с такой конфигурацией или он в него попал тем или иным образом. Рассматриваются такие свойства Pod и их сочетания как: hostNetwork, hostPID, hostIPC, hostPath, privileged (список на самом деле можно и расширить):

#1: Все разрешено
#2: Privileged и hostPid
#3: Только Privileged
#4: Только hostPath
#5: Только hostPid
#6: Только hostNetwork
#7: Только hostIPC
#8: Ничего не разрешено

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

Автор также выложил репозиторий со всеми манифестами, и вы можете повторить все описанное в статье. Материал полезен как пентестерам, так и людям, отвечающим за безопасность в Kubernetes.

Общий посыл не забываем про принцип наименьших привилегий (principal of least privilege).

P.S. Если атакующий попал в такой Pod через RCE, то он не знает о этих свойствах Pod и будет итеративно перебирать эти сценарии, тем самым создавая много аномальной активности внутри ;)

Сегодня речь пойдет не о security, а о compliance в Kubernetes ;)

Надеюсь, все знают и понимают разницу между ними. И так в различных коммерческих решениях мне доводилось видеть следующие виды комплаенсов:
- CIS Benchmarks Docker
- CIS Benchmarks Kubernetes
- HIPPA
- NIST SP 800-190
- NIST SP 800-53
- PCI DSS
- SOC 2
- GDPR
- AWS Well-Architected Framework
- ISO27001

По сути пункты из этих документов переносятся в проверки, и система определяет сколько из них прошли успешно. Возможно 3 развития события:
1) Пункт считается закрытым, тем фактом что у вас используется само решение, которое и проводит проверку
2) Пункт может считаться закрытым, если определенные настройки в системе применены
3) Пункт остается открытым, так как решение не способно определить - обычно это какие-то не технические процессные вещи. (такое бывает до 50% от всех проверок)

Помните, что это чеклисты и они абсолютно не учитывают контекст.

В статье "Kubernetes Honey Token" рассматривается пример реализации концепции Canary Tokens в Kubernetes. Общая идея данной концепции заключается в том, что для злоумышленников специально оставляются какие-то интересные ему сущности, при взаимодействии с которыми мы сразу об этом можем узнать.

Авторы в данной статье в качестве такого выбрали ServiceAccount. И предлагают взять его от Helm v2 тот, что с Tiller. Тоесть если вы его используете по назначению, то вам такой подход не подойдет - он не должен использоваться у вас.

Естественно, можно придумать и другие подходы с этими Canary Tokens в Kubernetes и даже использовать их комбинацию. Среди моих идей на пример есть:
- Подкладывать файлы через init container и смотреть обращение к ним
- Смотреть использование дефолтного ServiceAccount токена, где он вообще не используется (если вы его не отключили)
- Добавлять в переменные окружения контейнеров специальные адреса и мониторить обращение к ним

В общем в данной теме есть где разгуляться фантазии ;)

P.S. Предлагайте свои идеи в комментариях!

Общаясь тут со своими иностранными товарищами, открыл для себя такую, набирающую обороты тему (по крайней мере в МАРКЕТИНГОВОМ плане) как облачный vendor lock =) Точнее его избежание.

Смысл/идея в том, что со временем все больше компаний будет Multi-cloud, тоесть располагаться не у одного облачного провайдера, а у нескольких, дублируя свои инфраструктуры (тот же managed Kubernetes). Это должно убрать тот самый vendor lock, быть гибкими в случае проблем у одного из провайдеров (или у вас с ним) или распределять нагрузки в случае DDoS в общим избавляться от единой точки отказа.

Насколько действительно сейчас существует такая потребность мне лично сказать сложно. Так я точно знаю, что в определенных отраслях есть требования чтобы не было vendor lock. И если я не ошибаюсь, то тем же сотовым операторам необходимо закупать оборудование разных производителей как раз чтобы не было vendor lock, но это все таки другая история…

Читая рекомендации о построении безопасности внутри компании можно встретить такое количество наименований команд безопасности, что это порой может просто превосходить общую численность людей, что имеют к ней вообще отношение. И так на просторах сети можно встретить:
- Internаl security Team
- Product security Team
- Compliance Team
- Blue Team
- Red Team
- Purple Team
- DevSecOps Team
- SecOps Team

Если это докатиться и до нас, то можно будет только порадоваться за выпускников профильных вузов, что они смогут заниматься интересными техническими вопросами ИБ. Но на сегодняшний день ситуация такова что security специалистов в компании в десятки раз меньше, чем разработчиков. И равным никогда не будет, да и это бессмысленно. Скорее правильное распределение ответственности между всеми департаментами, правильные подходы и процессы (ZeroTrust, ShiftLeft security) принесут наибольшую пользу с наименьшими затратами.

P.S. Знаете еще названия команд - пишите в комментариях.

Сегодняшний пост в виде вопроса:

В вашей компании/организации внедряют DevOps/DevSecOps практики, инструменты или решают с помощью них проблемы? В принципе, это касается любых практик и инструментов. Логично можно прийти и к выводу, что привносят и новые проблемы)

Изучая заметки последней встречи CNCF SIG-Security, обнаружил упоминание проекта MITRE ATT&CK for Containers. Насколько вы наверно знаете матрицы для контейнеров пока нет, есть только для Cloud и неофициальная для Kubernetes от Microsoft.

Насколько я разобрался в данном вопросе, MITRE находится в стадии разработки данной матрицы и сейчас привлекает сообщество для участия в этом. Что они хотят: "ATT&CK team is now investigating adversarial behavior in containers for potential inclusion in ATT&CK.If we find that there’s enough adversary behavior in containers to warrant ATT&CK coverage, we’ll consider that content for a future ATT&CK release."