Продолжая тему атаки на цепочку поставок (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 среднестатистическим разработчиком?
- Зачем перегружать разработчика инфой, когда можно просто дать ему кнопку?

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

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

Выскажусь на тему одного из прошлых постов «Нужно ли разработчику знать Kubernetes». Как показывает мой опыт общения с компаниями у которых уже используется Kubernetes все зависит от возможностей компании и ее процессов. И, по сути, кто-то идет по пути специализация, а кто-то диверсификации.

В каких-то компаниях уже выстроены зрелые процессы (их перестраивание не простое дело), и они могут позволить (или вынуждены) себе специалиста под определенную задачу и там разработчик может совсем ничего не знать про Kubernetes.

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

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

Очень классная исследовательская работа "Docker image history modification - why you can't trust `docker history`". Общая идея статьи показать, что история образа это всего лишь meatadata, которая также может быть изменена/подделана и не надо ей слепо доверять. И тут опять плавно возвращаемся к supply chain атакам.

Отдельное внимание уделяется инструменту от Google под названием container-diff. А потом демонстрируется (почти пошаговая инструкция) как можно подделать историю и данный инструмент не найдет отличий.

Для корректного подтверждения подлинность образов Docker, которые вы создаете или используете, лучше использовать их подпись (в Docker есть Docker Content Trust (DCT), а в Kubernetes, на пример, Notary в pipeline), а не данную metadata.

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

Для тех, кто разбирается с проблемами работоспособности, возникающими с workloads в Kubernetes такой ресурс как Events хорошо знаком (если забыли, то вспомните нижнюю часть вывода команды describe). Он очень полезен при решении проблем, но время от времени можно задаться вопросом, а какие они вообще бывают и о чем могут сообщить, предупредить ...

Для этого на этот (да и на любой) может помочь исходный код ;) В данном файле собраны все (и это не правда) Events с группировкой по категориям Container, Pod, Image, kubelet и других более мелких групп. К сожалению, там все-таки собрано не все — вот, на пример, событие Evicted описано в другом файле и сколько таких еще - не известно.

Можно обратить внимание, что Events относящихся к безопасности нет (по крайней мере в этом списке и я таких не знаю). Но было бы круто если бы они там появились — это прекрасное место для уведомления о runtime угрозах. При этот на сколько я понимаю сторонние решения могут взять это на себя и генерировать подобные сообщения, имея права работы с Events ресурсами.

Вернемся к теме «Нужно ли разработчику знать Kubernetes». Общаясь с компаниями, использующими Kubernetes (и не только), повсеместно наблюдаю такую картину, что специалистов по ИБ в разы меньше (естественно), чем людей, занятых в разработке и поддержки. А к этому еще летит большое количество правок, изменений и т.д в микросервисах. Контролировать, проверять, реагировать на все это небольшой команде очень тяжело ...

Команде, занимающейся ИБ, нужна так или иначе помощь тех же разработчиков. НО разумно можно задаться вопросом: а нужно ли это разработчикам вообще? В поисках, ответа на этот вопрос я набрел на очень интересную статью "Maximizing Developer Effectiveness", с которой рекомендую ознакомиться.

После прочтения я пришел к таким выводам: чем больше разработчик будет знать и понимать как об окружении (в нашем случае Kubernetes), так и о процессах других команд, которые на него могут повлиять (тот же отдел ИБ - сканерами, проверками), тем проще и быстрее он без посторонней помощи (сам в себе) может решать задачи. И на этом всем можно хорошо стоить как DevOps, так и DevSecOps культуру в рамках компании.

С марта к данному каналу подключатся два моих хороших товарища и мы постепенно начнём раскрывать тему безопасности managed Kubernetes. А именно Google Kubernetes Engine (GKE) и Amazon Elastic Kubernetes Service (EKS).

Возможно со временем рассмотрим и другие managed Kubernetes, но начнём с самых популярных, технически продвинутых (с точки зрения дополнительных сервисов и наработок как минимум) и где у нас уже есть определенная экспертиза.

Особое внимание, конечно, будет уделено Identity and Access Management (IAM) и другим особенностям характерным cloud provider’ам. Но также будем проводить сравнения, аналитику и анализ новостей, инструментов как для защиты, так и для атаки + свои мысли и идеи с проектов.

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

На канале также начнет появляться информацию о RedHat OpenShift. Для разработки и тестирования у нас в лабе появилась и данная система - буду постепенно изучать и ее.

В процессе разработки мы используем две бесплатные версии/модификации OpenShift:
- okd
- crc

Первый развернут на 5 нодах (3 мастера) и максимально приближен к оригинальному RedHat OpenShift - на нем мы гоняем интеграционные, большие тесты. Второй более минималистичен (там нет мониторинга) развернут в несколько копий по 1 ноде - на них мы обычно гоняем быстрые, частые тесты.

Если вы захотите поизучать/поиграться с RedHat OpenShift - обратите внимание на эти дистрибутивы.

Чтобы закрыть тему внутреннего тестирования и экспериментов в нашей команде - отвечу на вопрос что прилетал в личку. Как наша команда работает с Kubernetes?

Для этого у нас есть внутренний инструмент, который в несколько кликов или через CLI тулзу (она используется в CI\CD) поднимает Kubernetes кластер нужной конфигурации.

На текущий момент можно выбрать:
- foundation - выбор ОС для кластера (centos, debian, ubuntu, fedora, rhel)
- container_runtime - выбор container runtime (docker, containerd, crio)
- num_nodes - количество Node в кластере
- ttl - время жизни кластера
- kubernetes_version - версия Kubernetes (1.15-1.20)

И в ближайшее время добавится:
- cni - выбор сетевого плагина (calico, flannel, cilium, weave)
- service_mesh - при необходимости поставить сервисную сеть (istio, linkerd)

Это нам позволяет быстро тестировать наше решение, сторонние тулзы, проверять баги/уязвимости, проводить исследования и разные эксперименты на разных конфигурация.