Как наверно вы уже знаете, что от 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."

Проект K8s-mirror создает зеркало целевого Kubernetes кластера для его дальнейшего безопасного offline анализа.

Работает это все по следующей схеме:
1) Все ресурсы из целевого кластера экспортируются в json файл
2) Вы модифицируете соответствующим образом dockerfile из проекта. Там есть etcd и kube-apiserver.
3) Собираете и запускаете этот контейнер, который подгружает этот json файл в локальный etcd.
4) Обращаетесь к данному kube-apiserver с помощью любимого kubectl и проводите анализа ресурсов.

Спокойно можно проверять RBAC с имперсонизацией, kubectl auth can-i и т.д. Может быть очень полезно, чтобы не давать прямой доступ на prod кластер.

Отдельно отмечу, что сам автор говорит, что это всего лишь проект выходного дня и никаких гарантий по полной работоспособности и покрытию всех версий k8s он не дает. Также это нельзя использовать как backup средство!

Продолжая тему атаки на цепочку поставок (supply chain), рекомендую обратить свое внимание на статью "Detecting zero days in software supply chain with static and dynamic analysis".

Автор пытается ответить на вопрос как можно обнаружить неизвестные уязвимости (0day) в пакетах и пакеты с backdoor'ами. И для статического обнаружения он предлагает использовать инструмент semgrep, а для динамического какой-либо трассировщик системных вызовов на базе eBPF, ptrace, strace и т.д.

Предложенные идеи достаточно очевидные и очень простые. Обход рукописных правил semgrep вообще не проблема - тут еще надо знать, что искать вообще. Относительно динамического детектирования лучше, но где уверенность что эта функциональность сработает на страте приложения?! Атакующий может знать примерное время работы контейнера и его код срабатывать по таймеру. А если срок жизни малый (статистика показывает, что таких сервисов хватает), то конечно, его код должен отработать в начале.

Мое виденье, что спасением здесь будет полное понимание нормального поведения вашего приложения (взаимодействие процессов, файловые операции и сетевые). Так или иначе образ собирается и тестируется на DEV, TEST, STAGE и уже далее PROD кластере. За это время тестов можно и понять нормальное поведение и аномальное.

Появилась новость о новой вредоносной компании направленной на Kubernetes от небезызвестной группы TeamTNT. Начальный доступ получается через неправильную конфигурацию kubelet, позволяющую анонимный доступ. Так злоумышленники через kubelet API попадают в первый контейнер, который находится под управлением найденного kubelet и загружают туда вспомогательные инструменты. Далее уже вредоносный код (Hildegard) пытается как можно в большем количестве найти контейнеров в кластере и запустить через kubelet API в них майнеры.

По оценке исследователей безопасности данная атака еще не имеет широкого распространения и находится только в стадии разработки/подготовки. Из интересного, вредоносный код несет с собой два OpenSource инструмента для поднятия привилегий и побега из контейнера: Peirates и BOtB.

По моей оценке:
1) Если у вас kubelet торчит в интернет, то это game over.
2) Если вы видите и знаете, что у вас происходит внутри контейнеров, то такое поведение нельзя не заметить.

В России начинают возвращаться оффлайн мероприятия! И 10 февраля в Москве на международном форуме iFin-2021 (для банковского сектора) в секции (с очень пафосным названием) «ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ BIG DATA, AI, ОБЛАКОВ, OPEN API, РОБОТИЗАЦИИ, БИОМЕТРИИ, БЛОКЧЕЙНА В ФИНАНСОВОМ СЕКТОРЕ» я расскажу доклад "Kubernetеs: Незнание своей системы – злейший враг".

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

За основу для названия доклада я взял цитату известного специалиста по ИБ Bruce Schneier: “Complexity is the worst enemy of security, and our systems are getting more complex all the time.”

Буду очень рад как живому общению, так и вопросам по теме на самом мероприятии)

На прошлой неделе удалось посмотреть трансляцию доклада "HashiCorp Vault в k8s" на площадке DevOps Novosibirsk. Я не специалист по решению от HashiCorp и доклад для меня был полезным. В нем рассказывается о нескольких возможных подходах для работы с секретами, их плюсы и минусы. Для нетерпеливых, в итоге внутри компании докладчика остановились на проекте bank-vaults, который работает через MutatingAdmissionWebhook. Одним из важных критериев при выборе подхода играло соответствие 12 факторам.

В рамках Q&A часто упоминался предыдущий доклад автора "Hashicorp Vault и как его готовить для разных команд". Для полной картины по работе с Vault его также рекомендуется посмотреть. После трансляции была интересная дискуссия про backup Vault (в записи ее нет) и работы с ним при необходимости. Актуальная проблема/задача особенно в рамках больших компаний.

Как всегда, стоит помнить то, что отлично работает в одной компании, может не заходить у вас и к выбору технологий стоит подходить очень внимательно. При этом технологии активно развиваются и как говорит сам автор в рамках доклада, что, когда они внедряли у себя, некоторых фичей вообще не было в том же Vault.

Kubernetes Failure Stories - очень классная компиляция публичных историй о сбоях/отказах/проблемах в Kubernetes инфраструктурах. Истории связаны как с основными компонентами Kubernetes, так и со сторонними. При этом для каждого случая сразу выделено: involved - какие компоненты были замешаны и impact - к каким последствиям привело. Можно быстро и просто найти возможно похожую проблему, с которой столкнулись непосредственно вы или избежать подобных проблем в будущем.

Безопасность и надежность вещи очень взаимосвязанные ;)

0_o - моё выражение лица, когда по гистограммам ловят атакующего. Такое можно встретить и в коммерческих решениях и просто порой как импорт событий во всеми любимую Grafana. На лицо отражение чисто количественных показателей в отсутствии контекста.

Смотрел вчера круглый стол «Нужно ли разработчику знать Kubernetes».
Участники в процессе этого пытались ответить на вопросы:
- В какой момент компания должна понять, что им необходим k8s?
- Какие зоны ответственности разработчиков и DevOps-ов при работе над проектом в Kubernetes?
- Что такое "знать Kubernetes"?
- В какой момент стоит задаться вопросом о необходимости умения использовать Kubernetes среднестатистическим разработчиком?
- Зачем перегружать разработчика инфой, когда можно просто дать ему кнопку?

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

Мое мнение по данной теме напишу в отдельном посте.