Консультируя, время от времени встречаю вопросы о различных стандартах в сфере Kubernetes. Прям стандартов нет, но есть два хороших документа, которые могут служить заменой/подменой таковым:

- CIS Kubernetes Benchmark (271 стр) - step-by-step checklist для Kubernetes.
Состоит из рекомендаций для: Control Plane Components (Master Node Configuration Files, API Server, Controller manager, Scheduler), etcd, Control Plane Configuration, Worker Nodes (Worker Node Configuration Files, Kubelet), Policies (RBAC and Service Accounts, Pod Security Policies, Network Policies and CNI, Secrets Management, Extensible Admission Control, General Policies).

- NIST Special Publication 800-190 "Application Container Security Guide" (63 стр) - руководство о контейнерных угрозах, рисках и то ка ким можно противодействовать без привязки к системе оркестрации.

Основные разделы: Introduction to Application Containers, Major Risks for Core Components of Containers Technologies, Countermeasure for Major Risks, Container Threat Scenario Examples, Container Technology Life Cycle Security Considerations.

Есть еще и CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.0.0 и CIS Google Kubernetes Engine (GKE) Benchmark v1.0.0. Также у CIS в разделе Cloud Providers можно найти документы по: Amazon Web Services, Google Cloud Computing Platform, Microsoft Azure и Oracle Cloud Infrastructure.

Стоит отметить с какой скоростью в Kubernetes вносятся изменения и улучшения, данные документы лишь ориентир, так как они не обновляются так часто.

P.S.
NIST - National Institute of Standarts and Technology
CIS - Centre of Internet Security

Вторая тема (после runtime behaviour analysis), которая мне чрезвычайно нравится в безопасности и в безопасности Kubernetes, в частности, это уменьшение поверхности атаки - attack surface reduction. Основная суть которой: "The basic strategies of attack surface reduction include the following: reduce the amount of code running, reduce entry points available to untrusted users ...".

Возьмем пример из IoT: если умная лампочка на борту имеет CPU общего назначения и полноценную ОС Linux, то она сразу становится очень перспективной и привлекательной целью для злоумышленника для организации плацдарма для дальнейших атак. Хотя, по сути, там должен быть микроконтроллер, который позволяет регулировать яркость, цвет и включать, и выключать ее. По этой теме/проблеме есть замечательная презентация "Security, Moore’s law, and the anomaly of cheap complexity".

Для контейнерных приложений ситуация аналогичная: если атакующий попадает на контейнер, где есть подходящее ему окружение (на пример, тулы curl, wget, отладчики, интерпретаторы и т.д.), то ему и дальнейшую атаку выполнять куда проще и на другие контейнеры и инфраструктуру в целом.

При этом attack surface reduction сильно связана с runtime behaviour analysis, ведь чем более неблагоприятные условия попадает атакующий, тем больше ему приходится совершать лишних/пробных действия, что отражается на runtime behaviour и выдает атакующего.

К сожалению, такие контейнеры можно редко у кого встретить, хотя инструменты и механизмы для этого есть, на пример связка: distroless images + Ephemeral Containers (для отладочных целей (с 1.16 в alpha)).

Некоторое время назад мы уже обсуждали тему специально подготовленного image для пентеста контейнерных инфраструктур. И там речь шла о проекте botty. Сегодня хотелось бы представить проект под названием hacker-container, который сам автор описывает как: "Container with all the list of useful tools/commands while hacking Kubernetes Clusters" . На борту данного контейнера порядка 52 инструментов и есть еще список todo, что автор хочет туда добавить.

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

Какой же из этих контейнеров лучше? Я считаю, что каждый для себя это решит сам, и лучше все делать под себя в этом вопросе, а не использовать полную чужую сборку (благо изменение Dockerfile дело не хитрое)

На сайте конференции KubeCon + CloudNativeCon Европа 2020. Выложили слайды и транскрипции выступлений (где-то только транскрипции, видео пока не доступно).
- Доклады с KubeCon + CloudNativeCon (+ фильтр "Security + Identity + Policy")
- Доклады с Cloud Native Security Day

Попозже обязательно рассмотрим отдельно наиболее интересные доклады по теме security.

В версии Kubernetes 1.19 поддержка seccomp перешла в статус General Availability (GA) (начало было положено в 1.10)! Благодаря данной штуке можно повышать безопасность ваших workload'ов с помощью ограничений допустимых системных вызовов для определенного Pod'а (и всех контейнеров внутри него) или чисто для определенного контейнера. Это сузит Attack Surface для злоумышленника и может ему очень сильно усложнить попытки поднять свои привилегии или сбежать из контейнера. Задаются эти профили в securityContext в seccompProfile секции spec при описании Pod или в PodSecurityPolicy. Более технические моменты реализации данного механизма можно посмотреть в KEP - Seccomp to GA.

Подробнее о использовании seccomp в Kubernetes можно почитать на страничке tutorials. Там же можно посмотреть, как выглядят данные профили.

Проблемой для применения в проде seccomp по-прежнему остается сложность создания полноценных fine-grained профилей, что может привести к аварийному завершению приложения. Имеющиеся инструменты oci-seccomp-bpf-hook, go2seccomp, а также "SCMP_ACT_LOG" режим самого seccomp имеет ряд недостатков и ограничений ... Хотя для начала можно начать и с типа RuntimeDefault, но нет гарантий что даже он у вас заработает.

C релизом Kubernetes 1.19 увеличилось окно поддержки с 9 месяцев до 1 года (начиная только с этой версии!). По-простому, теперь вместо поддержи 3 релизов, будет поддержка 4 релизов, что и увеличит поддержку до 1 года.

Раньше нужно было обновляться как минимум 1 раз в 9 месяцев чтобы иметь поддерживаемую версию.

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

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

Поговорим сегодня о Honeypots, а именно о Honeypot stack на Kubernetes под названием beehive. В этот стек сейчас входит 15 honeypot'ов, покрывающих:
- Android Debug Bridge over TCP/IP
- Cisco ASA honeypot
- ICS/SCADA honeypot
- SSH/Telnet honeypot
- dionaea honeypot
- Elasticsearch honeypot
- Credentials catching honeypot
- Low to medium interaction honeypot
- TCP or UDP services honeypot
- SMTP Honeypot
- HL7 / FHIR honeypot
- RDP honeypot
- Web application honeypot sensor

И за всем смотрим логи с помощью Elasticsearch и Kibana.

Если ваше приложение уже работает в K8s, то можно очень просто сделать honeypot инсталляцию вашего сервиса или специальную тестовую инсталляцию для растерзания при аудите/пентесте или BugBounty, чтобы случайно не пострадали пользовательские данные. K8s позволяет очень быстро и гибко развернуть вашу уникальную приманку (ваш собственный сервис) как у себя локально, так и в любом облаке, в любом масштабе. В данном направлении уже есть выступления на конференциях ("How to Deploy Honeypots into your Kubernetes"), так и отдельные статьи ("Creating and Deploying Honeypots in Kubernetes"). Это позволит ловить на 1-day так и 0-day атаки на ваше приложение. Тут главное, чтобы у вас был хороший мониторинг нацеленный на Container RunTime Security.


Вся тема honeypot'ов получила в последнее время вторую жизнь благодаря лозунгам "Detection through Deception", "Security Through Deception" и продуктам класса Deception Technology (спасибо маркетологам).

Выложили видео выступлений с KubeCon + CloudNativeCon Europe 2020

Выложили ряд видео докладов с Cloud Native Security Day:

- Opening Remarks - Emily Fox, US National Security Agency
- Collection is not Detection - Sec Ops in a Cloud Native Environment - Sarah Young, Microsoft
- PARSEC: A New Platform Abstraction for Security - Hugues de Valon & Ionut Mihalcea, Arm
- Image Provenance and Security in Kubernetes - Adrian Mouat, Container Solutions
- Cloud native or cloud agnostic? The questions you need to ask - Sriram Rajan, Rackspace
- How Secure Is Your Build/Server? - Patrick Debois, Snyk
- Pod Security as an Afterthought - Alban Crequy, Kinvolk
- Defenders Think in Lists. Attackers Think in Graphs. - Reuven Harrison, Tufin
- Kubernetes Attack and Defense: Inception-Style - Jay Beale, InGuardians
- New Paradigms for the Next Era of Security - Sounil Yu, Cyber Defense Matrix
- Closing Remarks - Brandon Lum, IBM

Интересная (но предсказуемая) эволюция арсенала преступной группы TeamTNT, атакующей облачные окружения, включая Docker, Kubernetes. Теперь на ряду с криптомайнерами, зараженными docker образами есть и легитимные инструменты. В частости известный инструмент для мониторинга Weave Scope. Они используют его для составления карты окружения жертвы, выполнения системных команд без деплоя вредоносного кода. В результате они получают мощный backdoor на основе легитимного инструмента.

Развитие атаки:
1) Через доступный Docker API устанавливают привилегированный контейнер с чистым образом Ubuntu
2) Данный контейнер сконфигурирован с маунтом к файловой системе сервера жертвы для полного доступа к файлам сервера
3) Скачивание и выполнение криптомайнеров на сервере
4) Попытка получения root доступа на сервере и создание пользователя ‘hilde’ для соединения по SSH
5) Скачивание и установка Weave Scope с git
6) Подключение к Weave Scope dashboard по HTTP на 4040 порт для полного контроля инфраструктуры жертвы.

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

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

При проектирование своего Kubernetes кластера чрезвычайно важным его элементом является Container Runtime. При этом мало кто знает, что он, по сути, состоит из 2 частей: High-level Runtime и Low-level Runtime.

High-level Runtime (CRI Implementations):
• Dockershim
• CRI-O
• Containerd
• Frakti
• rktlet

Low-level Runtime (OCI Runtimes):
• runC
• runV
• Clear Containers
• kata-runtime
• gVisor


Изучая и сравнивая Docker и Containerd - можно лишний раз убедиться, что специализированное решение (Containerd) лучше, чем решение общего назначения. Для этого я сравнил security related информацию, выдаваемую командами crictl inspect <containerid> и docker inspect <containerid>. По мимо той же прямой связи с ресурсами Kubernetes есть и нформация по capabilities, seccomp настройкам работающего контейнера.

Отдельно советую посмотреть слайды "How Container Runtimes matter in Kubernetes?" про сравнение данных вещей в плане производительности и более новое исследование "Performance Evaluation of Container Runtime".

На днях от одного security вендора вышел отчет "2020 Cloud Native Threat Report: Evolution of Attacks in the Wild on Container Infrastructure". В отчете авторы рассматривают "attacks against cloud native environments".

Мой же взгляд что атакующие в первую очередь не cloud атакуют, а приложения, сервисы и они могут даже не знать где это все располагается. Облачные/контейнерные технологии как и любые технологии изменяют/расширяют attack surface (те самые misconfigured Docker API). И глупо было бы со стороны злоумышленников к своим сканам приложений на различные RCE, не добавить еще и этот крутой мисконфиг.

Отчет строится на основе результатов полученными с помощью honeypots. Honeypots очень классная штука. ТОЛЬКО в зависимости от того, как он "приготовлен", такие результаты и получаться! Глупо ожидать от honeypots с misconfigured Docker API, ловли RCE атак на Redis, Nginx, WordPress и другие приложения, что крутятся и смотрят в интернет в ваших сервисах.

К сожалению, авторы совсем не описали свою методологию тестирования ... Говорится что "In 100% of the attacks, the initial access was ‘Exploit Public-Facing Application’.", то что это за приложения непонятно. Скорее всего Honeypot это misconfigured Docker API и все.

По мне заголовок отчета не соответствует содержимому и более правильное название — это "Анализ вредоносных images".

P.S. В отчете нет ни одного упоминания Kubernetes/k8s. Хотя можно было бы в интернет вытащить и порты от его сервисов (etcd, dashboard и т.д.) и вообще много чего еще интересного ;)

Интересную заметку в своем блоке опубликовали исследователи из одной security-компании - "Falco Default Rule Bypass".

Обходы заключаются в логической ошибке в описании двух достаточно серьезных правил детектирования: "Launch Sensitive Mount Container" и "Launch Privileged Container". Из-за этой ошибки атакующий может создать такие images, что при их использовании система Falco ничего не увидит и промолчит.

За данным проектом я наблюдаю давно и для меня всегда оставалась загадкой его целевая аудитория?!

Если предполагается что предопределённые правила нужны новичкам, то в это не укладывается конфигурирование файла falco_rules.yaml (объем которого боле 1600 строк). Для его грамотной настройки явно порог входа не новичок. Тут нужно и Kubernetes понимать и то, как работают все ваши сервисы. Часть правил к вам вообще может быть не применима или применима не всегда и не везде в вашей инфраструктуре. А с учетом того, что сервисы меняются/развиваются, то и данный файл с правилами также надо своевременно редактировать. И как мы видим в блоге ни сами авторы инструмента, ни вы при редактировании правил не застрахованы от ошибок.

Если предполагается что предопределённые правила нужны большим и зрелым security командам, то большинство из его детектов можно закрыть другими механизмами, встроенными в сам Kubernetes. Например, Admission Control, PodSecurityPolicy, NetworkPolicy + Logging. Есть конечно и прецеденты, кто использует его, но тут надо иметь очень зрелый цикл разработки, слаженное взаимодействие между командами + приличную security team, что могут позволить себе далеко не все. Так как иначе это поддерживать в актуальном состоянии будет очень-очень тяжело.

Также Falco позиционирует себя как детектор аномального поведения и при этом базируется на человека созданных предопределенных правилах... При этом абсолютно естественно, когда, например, в одном image запуск процесса bash это аномально, а для другого это нормально. Так что это будет в итоге? Или на этот случай надо модифицировать правила для каждого image?

Замечательная заметка "Impact of CVE-2020-14386 on Kubernetes and Containers (Docker)" лишний раз не дает забыть о том, что безопасность хоста, на котором работает Kubernetes это также часть безопасность Kubernetes инфраструктуры.

Здесь речь идет о критической уязвимости ядра Linux - CVE-2020-14386, благодаря которой можно поднять свои привилегии до root'а или сделать побег из контейнера на Node, на которой он работает. Атакующий способен эксплотировать данную уязвимость, выполняя свой код внутри Pod'а с CAP_NET_RAW capability.

Естественно, это далеко не первая и не последняя уязвимость в ядре Linux которая позволяет делать "container escape". И все это никакими правилами и сигнатурами заранее не описать, не предусмотреть.

Что в таком случае делать для защиты?
1) Можно/нужно мониторить аномальную активность внутри ваших контейнеров. Так или иначе атакующему придётся для побега из контейнера делать то, что ранее в контейнере у вас не происходило. Это позволит вам ловить не только попытки "container escape", но и другу. Вредоносную активность внутри контейнера (Lateral Movement, запуск манейров и т.д.)
2) Можно присмотреться к защищенным/усиленным вариантам Low-level Runtime (OCI Runtimes) о которых говорили ранее. Но стоит учитывать, что они, как и любое ПО сами не застрахованы от уязвимостей, а просто сильно уменьшают и усложняют attack surface. Так GKE Sandbox использует для этого gVisor.

Уже давно хочу написать о докладе "Advanced Persistence Threats: The Future of Kubernetes Attacks" и чтобы на него обратило как можно больше не равнодушных к безопасности Kubernetes людей.

Сразу стоит отметить, что все продемонстрированные атаки в докладе предполагают, что атакующий так или иначе стал администратором кластера. А возможно это вообще недовольный кластер админ перед своим увольнением =)

Основная суть не в том, чтобы стать кластер админом, а закрепиться на кластере - получить Persistence. В общем, это краткое пособие о том, как могут оставить backdoor в вашем кластере.
Сценарии:
- Вредоносный validating webhook - во время валидации все что надо отправляется атакующему
- Shadow API Server - теневой kubeapi server с отключенной безопасностью лазит в etcd и забирает все что надо.
- C2BERNETES - С2 на базе k3s
- Вредоносное использование фич 1.19 для возрождения kubelet-exploit

Отдельно стоит отметить, что для всех сценариев авторы использовали легальное ПО - никакой малвари.

По мне эти сценарии далеки от идеальных и могут сработать если вы вообще не смотрите что у вас происходит в кластере. Но мне нравится сам полет фантазии авторов в этих техниках - на их базе можно придумать вещи куда по интереснее =)

Многие думаю не особо следят за CNCF Special Interest Group on Security, но в ней сейчас кипит работа над очень интересным документом "Cloud-Native Security Whitepaper" для CISO, CSO, CTO, Architects, целью которого является безопасность Cloud Native приложений. Как говорят сами авторы: "Our perspective for operators, what they should be thinking when considering cloud native security. How to inject security into the pipeline, not as an afterthought."

Документ находится еще в статусе WIP, так что его более детальный анализ проведем по его релизу. Но пробежавшись по нему могу сказать, что это очень достойный документ. Отличная работа SIG Security Group!

В своих постах я не раз отмечал чрезвычайную важность безопасности etcd. Если у атакующего есть туда доступ, то это GAME OVER.

На страницах документации etcd в разделе Operations guide есть секции "Role-based access control" и "Transport security model", на которых и строится базовая безопасность данного компонента Kubernetes кластера.

В первой секции говорится о работе с пользователями, ролями и аутентификацией, а во второй насчет транспортной безопасности на основе 4 примеров:
1: Client-to-server transport security with HTTPS
2: Client-to-server authentication with HTTPS client certificates
3: Transport security & client certificates in a cluster
4: Automatic self-signed transport security

Все больше компаний начинают переходить на Kubernetes (не важно внутренний или managed в облаке) или по крайней мере присматриваться к нему. Логично что в начале возникает вопрос: а с чего необходимо начать формирование его безопасности?

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

Далее идут всем хорошо известные встроенные механизмы безопасности Kubernetes. НО нужно помнить, что в каждой компании Kubernetes уникален почти как снежинка, от компании к компании разные подходы к разработке, культура/процессы работы/разработки, в конце концов разные продукты/сервисы и, конечно, же уровень зрелости в вопросах информационной безопасности.

Поэтому чужие success story о использовании того или иного инструмента или подхода могут быть совершенно не эффективны или не применимы для вас.

Инструменты/подходы должны не латать дыры, а выстраивать правильный процесс (не забываем, что безопасность — это не состояние, а процесс!) внутри компании. Так на пример использование самого крутого инструмента поиска/анализа инцидентов будет совершенно не эффективным, если команда безопасности будет утопать в этих же инцидентах, не успевая их разбирать.

Подход при котором для решение проблемы "A", возьмем решение "X", для решения проблемы "B" возьмем решение "Z" и т.д. далеко не всем по карману и в условиях быстро трансформирующегося современного бизнеса не эффективен на длинных дистанциях.

Поэтому выстраивайте процессы, а не состояния безопасности и перед тем, как что-то внедрять разбирайтесь в том что и как у вас работает/устроено внутри. Иначе внедрением почти любого security механизма можно очень легко что-то сломать … А знакомство с безопасностью должно быть приятным, а не отталкивающим =)

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

Не все сразу задумываются о важности для безопасности культуры использования tags для images и labels для k8s ресурсов.

Хотя именно благодаря ним с помощью различных selector'ов и других механизмов можно очень гибко применять управлять и контролировать вопросы безопасности. Те же NetworkPolicy, PodSecurityPolicy без этого не взлетят.

Чем раньше вы продумаете стратегию/систему использования tags для images и labels для k8s ресурсов, тем проще вам будет потом использовать различные security и не security инструменты и подходы в будущем. Поэтому уделите время на обсуждение данного вопроса с вашими разработчиками, DevOps специалистами и это сэкономит вам много времени в будущем.

P.S. Не используйте tag latest ;)