В преддверии моего выступления на Kuber Conf поучаствовал в легендарном подкасте «The Art Of Programming» (выходит с 2008 года). Мы записали небольшой выпуск на злободневную тему: «Безопасные безопасности».

Список тем из выпуска:
- Город поребриков и контекст
- Безопасность и регуляторы
- Ностальгия и мотивация
- Очный DevOpsConf и Security champions
- SRE, Observability, Root Cause Analysis
- Наш путь и международный ландшафт
- Безопасность и open source
- Важное и полезное


Слушайте нас в 254 подкаста!

Telegram
VK
Twitter
FB

Почти спустя месяц после релиза "ATT&CK® for Containers" мои руки дошли до него. Теперь это уже официальная часть ATT&CK версии 9.0.

Матрица от Microsoft для Kubernetes мне нравится больше. Почему?
Рассматривать контейнер в отрыве от окружения по мне неправильно - много важных моментов теряется. Мне кажется, это поняли и авторы, так как в части пунктов упоминается "orchestration", а если зайти в каждую из техник, то там часто встречается либо пример, либо метод детектирования связанный с Kubernetes. А еще не очень приятный момент что часть техник они просто пересекли с техниками из Enetrprise матрицы и в итоге читаете описание и примеры, вообще никак не связанные с контейнерами ...

Но тем не менее можно эту матрицу сочетать с матрицей Microsoft.

Достаточно неплохая статья "PCI DSS compliance in Kubernetes-based platforms" для тех, у кого голова об этом болит ;) Базовые пункты и рекомендации покрыты не плохо с примерами OpenSource проектов. Но назвать это полноценным и лучшим выбором нельзя. Но для тех, кто только начинает - хороший старт.

Скоро начнётся мой доклад на Kuber Conf https://youtu.be/VLcMAS_lIQw

Знаю, что многие очень негативно или скептически относятся к Kubernetes c Node на Windows ...

Но злоумышленники уже прощупывают эту почву. И даже container escape делают через технику Thread Impersonation, используя недокументированный вызов Windows под названием NtImpersonateThread, а далее уже NtSetInformationSymbolicLink для самого побега. По сути это продолжение вот этой истории. Ну и тут все как положено с Microsoft)))

Далее уже вредоносное ПО на Node ищет kubectl.exe и config файл по RegExp для продолжения атаки.

Продолжение статьи про Identity Aware Proxy

Для аутентификации с помощью ServiceAccount, необходимо иметь permission iam.serviceAccounts.getOpenIdToken и получить OIDC токен

Нюанс №2
ServiceAccount с permission iam.serviceAccounts.getOpenIdToken может выписывать OIDC токен для любого другого ServiceAccount
Соответственно, обладая ServiceAccount'ом с таким permission, можно имперсонировать другой аккаунт и обойти IAP.
К сожалению ограничить действие permission на определенные ServiceAccount через Conditions не представляется возможным.

Используя этот нюанс можно было решить мою таску на Hack and Learn Initiative про мисконфиги в GCP. В ней также был реализован нюанс из прошлой статьи — кривая проверка хедеров от IAP
Подробный write-up можно почитать тут

Как бы удобны не казались облачные сервисы, нужно вдумчиво читать всю документацию, чтобы по пути не сделать несколько ошибок, в попытке сделать своё приложение безопаснее.

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

Буквально несколько дней назад было объявлено о CVE-2021-34824 (или по внутренней нумерации ISTIO-SECURITY-2021-007), которая звучит как: "Istio contains a remotely exploitable vulnerability where credentials specified in the Gateway and DestinationRule credentialName field can be accessed from different namespaces." с CVSS Impact Score равным 9.1. Так что патчимся ;)

А вообще у Istio есть хорошая официальная страничка о найденных в нем уязвимостях (как раз та внутренняя нумерация) и там можно отметить, что за 2021 год было уже закрыто 7 уязвимостей и их CVSS не ниже 7.5! Так что обратите внимание на этот момент.

Есть легендарный пост на GitHub: "What happens when you type google.com into your browser's address box and press enter?" (и подобные), объясняющий что же там за магия творится .

Некоторое время назад на канале мы публиковали похожий материал "What happens when ... Kubernetes edition!", где описывается что происходит при создании Pods, через команду:

kubectl run nginx --image=nginx --replicas=3

В продолжении данной темы мы рекомендуем обратить свое внимание на статьи про то, что происходит, когда используется kubectl exec (не малозначимая команда для ИБ):
- "How It Works — kubectl exec" (Docker shim)
- "How does 'kubectl exec' work?" (CRI-O)

Если вы как и наша команда хотите не просто использовать k8s, но и понимать его, понимать как он работает, то это определенно MUST READ!

А сегодня, в продолжении прошлого поста, давайте посмотрим на kubectl exec или на POST запрос /api/v1/namespaces/{namespace}/pods/{name}/exec кому как удобнее и приятнее - с точки зрения RBAC.

И тут для начала нужно вспомнить, что некоторые Kubernetes ресурсы имеют так называемые subresource, к которым как раз и относится exec, как и те же logs, attach, portforward и т.д. По итогу, чтобы пользователь мог делать exec ему необходимо иметь pods/exec:

- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]

Ну или "*" в графе resources ;)

Помните о "subresource" и управляйте правами в соответствии с принципом наименьших привилегий (Principle of least privilege).

Малоизвестный факт о Kubernetes RBAC: каждому действию (verb) в RBAC есть четкое сопоставление HTTP команды. Так что даже по HTTP логам можно определить какие действия совершались над тем или иным ресурсом. Или даже можно попытаться по HTTP логу за какой-то промежуток времени сгенерировать Role типа как тут.

Сегодня пятничный пост, который в первую очередь нацелен на вашу активность ;)

Поделитесь в комментариях интересными, полезными operator'ами для Kubernetes, которые как могут связаны с ИБ, так и нет. А может быть просто инструмент завязан на Mutating и/или validating admission webhook. При этом они могут быть очень маленькими, малоизвестными или даже уже не поддерживаемыми, но у них очень классная идея, которая вам очень нравится. В общем то, что так или иначе нельзя найти на OperatorHub.io и не просто найти на GitHub, Bitbucket и т.д.

Лично для меня таким является проект Kubernetes Janitor (хоть Custom Resources он не использует), о котором я писал ранее, и Kubernetes Security Profiles Operator - писал тут. В общем, давайте поделимся малоизвестными operator'ами =)

В рамках CNCF сейчас активно работает Policy Working Group. Как можно догадаться из названия она работает над тем, как будет в Kubernetes выглядеть сущность Policy. А именно ресурсы из wgpolicyk8s.io/v1alpha2:
- ClusterPolicyReport
- PolicyReport
Основную часть которых занимают PolicyReportSummary и PolicyReportResult.

Какую они проблемы решают и вообще, для чего это надо?

Сейчас уже существует множество разных инструментов для Kubernetes, которые проводят те или иные анализы, проверки и создают свой отчет. И вот каждый из них последнее делает как хочет. А ClusterPolicyReport и PolicyReport призваны унифицировать это в виде конкретных типов ресурсов и еще на один шаг приблизить работу со всеми инструментами к концепции Policy-as-Code!

Так на работу прототипа можно посмотреть на примере проекта kube-bench (CIS benchmark) в этом репе.

А еще подробнее можно узнать из документа "Kubernetes Policy Management Whitepaper Proposal" (находится еще в работе).

P.S. Далее мы рассмотрим какое сильное влияние это должно оказать на весь процесс работы с Kubernetes ;)

В продолжении темы о необходимости регулярного аудита конфигурации AWS IAM, рассмотрим еще один инструмент - Red-Shadow. Данная утилита позволяет проверить конфигурацию политик IAM на предмет несоответствия привилегий относительно групп и конкретных users/roles, с целью поиска Shadow Admins.
Другими словами, представим что IAM политиками группы строго запрещено взаимодействие, например директива
"Effect": "Deny",
"Action": "*",
"Resource": "arn:aws:iam::13371337:group/k8s-admins"
запрещает любое взаимодействия для этой группы, но данный запрет не распространяется на конкретных пользователей/роли. Данная ошибка конфигурации может повлечь существование Shadow Admins, по аналогии с мисконфигами Active Directory, это позволяет атакующему без особого труда повысить привилегии.

В этом примере политика должна запрещать любое действие IAM, выполняемое пользователями, группами или ролями, к которым эта политика привязана, с помощью, например condition policy iam:ResourceTag.

Копаясь в заметках встреч Policy Working Group, можно найти упоминание документа от Department of Defense (DOD) про "Zero Trust Reference Architecture" с пометкой "has similar concepts for policy" и картинкой из него (в превью данного поста). Поэтому можно судить к чему стремится данная группа при разработке Policy - SOAR (Security Orchestration, Automation and Response)!!!

Еще выжимка оттуда: "Policy Engine & Automation (SOAR): These terms are used to define technologies that handle threat management, incident response, policy enforcement and security policy automation. A Zero Trust Architecture will require dynamic policy enforcement and automation. SOAR will work in concert with analytics and policy engines to develop confidence levels and automate the delivery of policy to enforcement points."

В общем, автоматизация на любые ИБ моменты ;)

Давайте рассмотрим проект, которым уже многие компании у себя закрыли ряд моментов с ИБ. Речь пойдет про Starboard. Он автоматически создает/обновляет security отчеты для того или иного компонента (ReplicaSet, Node и т.д.) при его появлении/изменении. Под капотом у него:
- Vulnerability Scanners: Trivy
- Сonfiguration checkers: Polaris или Conftest
- CIS Kubernetes Benchmark: kube-bench
- Kubernetes cluster pentest: kube-hunter


Речь о нем сегодня не случайно - он как раз является ярким представителем, когда инструменты завернуты в Kubernetes operators (хотя есть и реализация CLI), а результаты работы в виде Custom Resources (на смену которым и должны прийти ClusterPolicyReport и PolicyReport):
- VulnerabilityReport
- ConfigAuditReport
- CISKubeBenchReport
- KubeHunterReport

А далее эти отчеты вы уже можете обрабатывать (сами автоматически считать риски, критичность и создавать тикеты, автоматически реагировать т.д.) и выводить как вашей душе угодно (Grafana и т.д.).

Давайте подытожим сегодня мое виденье о правильном и/или будущем подходе к ИБ в Kubernetes, которое я связываю с OODA loop:

1) Наши любимые инструменты проверок обернуты в Kubernetes operator и автоматически запускаются при появлении/изменении того или иного Kubernetes ресурса, за анализ которого они отвечают.
2) Результат анализа записывается в отдельный унифицированный отчет в виде Kubernetes resource.
3) Специальный Kubernetes operator выполняет роль SOAR (Security Orchestration, Automation and Response) и автоматически реагирует на появлении/изменение отчета анализа на шаге 2.

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

А в качестве пятничного поста я порекомендую (кому интересно) за выходные посмотреть свежее выступление "ATT&CKing Kubernetes: Technical deep dive into ATT&CK for Containers" с конференции Pass the SALT 2021. По сути, оно состоит из примеров, в основном из ITW (In The Wild) кейсов, которые смапленые на матрицу ATT&CK для контейнеров. Также стоит предупредить, что выступление не полное и докладчик не расскажет про защитные меры, так как не уложился в тайминг =)

Одним из двигающих/приоритизирующий механизмов развития NetworkPolicy являются так называемые User Stories - где пользователи описывают, свои истории/ситуации, с которыми они сталкиваются и им их хотелось бы решить относительно стандартной NetworkPolicy (не забываем, что у разработчиков CNI есть и кастомные реализации).

Этот список сейчас будет полезен всем по 2 причинам:
1) Вы узнаете какие возможности только появятся в NetworkPolicy
2) Вы узнаете какие сценарии прямо сейчас вы не сможете реализовать

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

file-integrity-operator - еще один интересный operator с открытым исходным кодом, который используется в RedHat OpenShift. Узнал я о нем недавно, благодаря посту про Kubernetes operators - спасибо за наводку ;)

Он, что логично, позволяет проверять целостность файлов на Node с определенной периодичностью. Для некоторых систем или в соответствии с некоторыми compliance такое может требоваться (типа требований 10.5.5 и 11.5 в PCI DSS) и тут как раз этот operator поможет. В коммерческих решения такая функциональность обычно называется как File integrity monitoring (FIM).

Выполнен о тут в виде DaemonSet в котором запускается привилегированный контейнер с проектом AIDE (Advanced Intrusion Detection Environment), который также имеет открытый исходный код.

Для работы вам помимо самого file-integrity-operator потребуется описать его Custom Resource типа (kind) FileIntegrity (там описывается, где запускаться через nodeSelector, с какой частотой gracePeriod и т.д.) и непосредственно конфиг для AIDE, который выглядит примерно так (что сканировать, а что нет и т.д.).

Результат будет в отдельном специальном ресурсе FileIntegrityNodeStatus (вспоминаем тут тему про отдельный тип ресурсов для Policy), а в процессе работы создаются соответствующие Events ресурсы о продвижении сканирования.

Ни одно серьезное приложение сегодня уже не обходится без сервиса хранения данных. И естественно данный сервис или скорее данные находящиеся там являются чаще всего целью для плохих парней. О защите данного сервиса много говорится и в документе "Cloud Native Security Whitepaper" в разделе "Storage". И вот Microsoft выпустила еще и свою "Threat matrix for storage services". Видимо им очень это понравилось делать самостоятельно без организации MITRE, как они уже делали для Kubernetes.

В матрице, конечно, просматривается некоторый ориентир на специфику Azure, но как база подойдет как для любых managed инсталляций, так и onprem. Помним об обилие решений в категории Cloud Native Storage в CNCF Cloud Native Landscape и то что каждое из этих решений обладает своими механизмами, настройками безопасности, которые требуют правильной конфигурации.

Поговорим сегодня о таких Kubernetes ресурсах как Endpoint и EndpointSlice, а точнее о целых двух новых уязвимостях, связанных с ними.

CVE-2021-25737: Holes in EndpointSlice Validation Enable Host Network Hijack
Уровень Low (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N)

Краткая суть: "user may be able to redirect pod traffic to private networks on a Node.". Пользователь, конечно, должен иметь права на работу с данным типом ресурса. При этом подобное для Endpoint закрыли, а про EndpointSlice забыли.

Помимо обновления kube-apiserver для митигийшена/закрытия данной проблемы можно использовать policy engine, который предотвращает создание endpoint с адресами в диапазонах 127.0.0.0/8 и 169.254.0.0/16.


CVE-2021-25740: Endpoint & EndpointSlice permissions allow cross-Namespace forwarding
Уровень Low (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N)

Краткая суть: "that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack."

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

Также в описании CVE говорится, что подобная атака возможно и с Ingress, но тут нужно проверять это для каждой реализации отдельно …