Generating Kubernetes Network Policies By Sniffing Network Traffic
Статья, посвященная эксперименту по генерации Network Policies на базе имеющегося трафика. Все необходимые скрипты можно найти в соответствующем репо. Основное ограничение заключается в том, что под капотом используется старый добрый tcpdump, требующий доп. привилегий, которых чаще всего нет в необходимой среде.
Идея, кстати, не новая. До этого, как правило, с задачей справлялся advisor вроде Inspektor Gadget.
#ops #k8s
Статья, посвященная эксперименту по генерации Network Policies на базе имеющегося трафика. Все необходимые скрипты можно найти в соответствующем репо. Основное ограничение заключается в том, что под капотом используется старый добрый tcpdump, требующий доп. привилегий, которых чаще всего нет в необходимой среде.
Идея, кстати, не новая. До этого, как правило, с задачей справлялся advisor вроде Inspektor Gadget.
#ops #k8s
CIS Red Hat OpenShift Container Platform 4 Benchamark (and RHCOS)
Как показывает статистика поста с OpenShift Security Guide, очень много здесь тех, у кого есть OpenShift, и тех, кто интересуется вопросами его безопасности. Как многие, наверное, знают, классический CIS, как и инструменты контроля соответствия CIS, не применимы к OpenShift из коробки. В частности отличается набор мер по закрытию требований в силу специфики работы системы. С этой целью Red Hat разработали отдельно Compliance Operator, который осуществляет набор проверок на базе собственного чек-листа. Тем не менее сам чек-лист отдельно не публикуется.
Оказывается, это не совсем так. В рамках одного из своих аудитов я узнал, что профили, на базе которых Compliance Operator строит проверки, можно найти на одном из доменов OpenSCAP, инструмента, который используется под капотом оператора.
Прикладываю:
- Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4
Здесь же есть профили со следующими проверками:
- Red Hat Enterprise Linux CoreOS 4
- Red Hat Enterprise Linux 8
- Red Hat Enterprise OpenStack Platform 13 / 10
- Ubuntu 18.04 / 16.04 / 20.04
- Suse Linux Enterprise 12 / 15
- Debian 9 / 10
- CentOS 7 / 8
и еще много разного полезного.
Многие тезисы содержат довольно подробные описания, включая меры и команды по устранению.
#ops #k8s
Как показывает статистика поста с OpenShift Security Guide, очень много здесь тех, у кого есть OpenShift, и тех, кто интересуется вопросами его безопасности. Как многие, наверное, знают, классический CIS, как и инструменты контроля соответствия CIS, не применимы к OpenShift из коробки. В частности отличается набор мер по закрытию требований в силу специфики работы системы. С этой целью Red Hat разработали отдельно Compliance Operator, который осуществляет набор проверок на базе собственного чек-листа. Тем не менее сам чек-лист отдельно не публикуется.
Оказывается, это не совсем так. В рамках одного из своих аудитов я узнал, что профили, на базе которых Compliance Operator строит проверки, можно найти на одном из доменов OpenSCAP, инструмента, который используется под капотом оператора.
Прикладываю:
- Guide to the Secure Configuration of Red Hat OpenShift Container Platform 4
Здесь же есть профили со следующими проверками:
- Red Hat Enterprise Linux CoreOS 4
- Red Hat Enterprise Linux 8
- Red Hat Enterprise OpenStack Platform 13 / 10
- Ubuntu 18.04 / 16.04 / 20.04
- Suse Linux Enterprise 12 / 15
- Debian 9 / 10
- CentOS 7 / 8
и еще много разного полезного.
Многие тезисы содержат довольно подробные описания, включая меры и команды по устранению.
#ops #k8s
Authorizing Microservice APIs With OPA and Kuma
До этого я писал про OPA только в контексте контроля запросов на API кластера с целью их ограничения. В этот раз предлагаю ознакомиться с материалом по применению OPA как способ микросервисной авторизации для реализации Zero Trust Network.
Authorizing Microservice APIs With OPA and Kuma
В данном случае речь именно об интеграции с service mesh Kuma, но это также может быть и Istio. Каждый раз, когда поступает новый внешний запрос, Kuma отправляет запрос авторизации на OPA. В статье также упоминается Styra DAS как инструмент централизованного управления политиками OPA.
Если вам интересно узнать чуть больше про Kuma и Zero Trust, то вот небольшая статья. У разработчиков Kuma есть также демо интеграции enterpise версии service mesh Kong Mesh с OPA.
#opa #ops #k8s
До этого я писал про OPA только в контексте контроля запросов на API кластера с целью их ограничения. В этот раз предлагаю ознакомиться с материалом по применению OPA как способ микросервисной авторизации для реализации Zero Trust Network.
Authorizing Microservice APIs With OPA and Kuma
В данном случае речь именно об интеграции с service mesh Kuma, но это также может быть и Istio. Каждый раз, когда поступает новый внешний запрос, Kuma отправляет запрос авторизации на OPA. В статье также упоминается Styra DAS как инструмент централизованного управления политиками OPA.
Если вам интересно узнать чуть больше про Kuma и Zero Trust, то вот небольшая статья. У разработчиков Kuma есть также демо интеграции enterpise версии service mesh Kong Mesh с OPA.
#opa #ops #k8s
Argo's Threat Model
Trail of Bit выпустили отчет об аудите в связке с моделью угроз для ArgoCD.
Всего по итогу аудита было обнаружено 35 issues (3 medium,16 low, 16 info). Уязвимости с наибольшим уровнем критичности:
16. The zJWT auth tokens allow for denial of service in Argo CD (Severity: Medium, Difficulty: Low)
17. Non-cryptographically secure random function documented as CSPRNG (Severity: Medium, Difficulty: High)
35. Packages with security vulnerabilities in Argo-CD and Argo WorkflowsUI (Severity: Medium, Difficulty: Low)
По итогам проведения моделирования угроз было обнаружено 21 issues (10 medium, 1 info, 8 low, 1 Undetermined, 1 high ). Уязвимости с наибольшим уровнем критичности и наименьшей сложностью эксплуатации):
6. Lack of authentication rate limiting (Severity: Medium, Difficulty: Low)
10. Insufficient default network access controls between pods (Severity: High, Difficulty: High)
11. Lack of authentication rate limiting ( Severity: Medium, Difficulty: Low)
12. API does not require authentication by default (Severity: Medium, Difficulty: Low)
15. TLS is not enabled by default (Severity: Medium, Difficulty: Low)
20. Undocumented potential race condition in Event Bus (Severity: Medium, Difficulty: Low)
В отчете также прилагается описание мер по повышению безопасности инфраструктуры по итогам проведения аудита. Меры делятся на краткосрочные и долгосрочные. Также описана методология тестирования и используемые инструменты (Semgrep, gosec, CodeQL, errcheck).
#ops #k8s #attack
Trail of Bit выпустили отчет об аудите в связке с моделью угроз для ArgoCD.
Всего по итогу аудита было обнаружено 35 issues (3 medium,16 low, 16 info). Уязвимости с наибольшим уровнем критичности:
16. The zJWT auth tokens allow for denial of service in Argo CD (Severity: Medium, Difficulty: Low)
17. Non-cryptographically secure random function documented as CSPRNG (Severity: Medium, Difficulty: High)
35. Packages with security vulnerabilities in Argo-CD and Argo WorkflowsUI (Severity: Medium, Difficulty: Low)
По итогам проведения моделирования угроз было обнаружено 21 issues (10 medium, 1 info, 8 low, 1 Undetermined, 1 high ). Уязвимости с наибольшим уровнем критичности и наименьшей сложностью эксплуатации):
6. Lack of authentication rate limiting (Severity: Medium, Difficulty: Low)
10. Insufficient default network access controls between pods (Severity: High, Difficulty: High)
11. Lack of authentication rate limiting ( Severity: Medium, Difficulty: Low)
12. API does not require authentication by default (Severity: Medium, Difficulty: Low)
15. TLS is not enabled by default (Severity: Medium, Difficulty: Low)
20. Undocumented potential race condition in Event Bus (Severity: Medium, Difficulty: Low)
В отчете также прилагается описание мер по повышению безопасности инфраструктуры по итогам проведения аудита. Меры делятся на краткосрочные и долгосрочные. Также описана методология тестирования и используемые инструменты (Semgrep, gosec, CodeQL, errcheck).
#ops #k8s #attack
GitHub
argoproj/docs/argo_security_final_report.pdf at main · argoproj/argoproj
Common project repo for all Argo Projects. Contribute to argoproj/argoproj development by creating an account on GitHub.
Revealing the secrets of Kubernetes secrets
Небольшая статья в блоге CNCF, посвященная секретам в Kubernetes.
"Can you keep a secret? Hope so, because in this blog, I reveal the secrets of Kubernetes secrets."
В частности рассматривается использование секретов через:
- Secret resources
- kubelet
- Pods
- Kubernetes API
- etcd
Для каждого из применений расписаны некоторые риски, которые стоит учесть. В том числе есть упоминание некоторых мер защиты. Например, механизма sealed-secrets, который позволяет скрыть секреты из JSON и YAML при их хранении в git. Или плагина Helm SOPS от Mozilla для безопасной работы с секретами в Helm.
#k8s #ops #secret
Небольшая статья в блоге CNCF, посвященная секретам в Kubernetes.
"Can you keep a secret? Hope so, because in this blog, I reveal the secrets of Kubernetes secrets."
В частности рассматривается использование секретов через:
- Secret resources
- kubelet
- Pods
- Kubernetes API
- etcd
Для каждого из применений расписаны некоторые риски, которые стоит учесть. В том числе есть упоминание некоторых мер защиты. Например, механизма sealed-secrets, который позволяет скрыть секреты из JSON и YAML при их хранении в git. Или плагина Helm SOPS от Mozilla для безопасной работы с секретами в Helm.
#k8s #ops #secret
Attacking Kubernetes Clusters Through Your Network Plumbing: Part 2
Вторая часть от CyberARK по атакам на сети Kubernetes (первая здесь). В этот раз речь пойдет об изменении маршрутизации (в частности BGP), что приводит к скрытой MiTM-атаке.
#attack #ops #k8s
Вторая часть от CyberARK по атакам на сети Kubernetes (первая здесь). В этот раз речь пойдет об изменении маршрутизации (в частности BGP), что приводит к скрытой MiTM-атаке.
#attack #ops #k8s
Ensure Content Trust on Kubernetes using Notary and Open Policy Agent
Реализация проверки подписи образа через OPA при деплое в Kubernetes с помощью интеграции с Notary-сервисом.
В рамках CI сборки формируется подпись к образу с помощью Notary сервиса. При формировании подписи, ее значение сохраняется в БД. Каждый раз, когда происходит попытка деплоя нового ворклоада, OPA с помощью
Так как работа происходит с OPA, в данной схеме есть возможность применить и
Про альтернативные способы формирования Content Trust я писал ранее.
#opa #k8s #dev #ops
Реализация проверки подписи образа через OPA при деплое в Kubernetes с помощью интеграции с Notary-сервисом.
В рамках CI сборки формируется подпись к образу с помощью Notary сервиса. При формировании подписи, ее значение сохраняется в БД. Каждый раз, когда происходит попытка деплоя нового ворклоада, OPA с помощью
ValidatingAdmissionWebhook проверяет наличие подписи (digest) к образу и идёт с ним в Notary, чтобы убедиться, что подпись была сформирована именно им. В случае, если образ был подменен злоумышленником или изменен за пределами security-проверок в CI, образ развернут быть не сможет.Так как работа происходит с OPA, в данной схеме есть возможность применить и
MutatingAdmissionWebhook. Например, прикреплять digest, если он отсутствует, но подпись для данного образа уже была сформирована и хранится в Notary.Про альтернативные способы формирования Content Trust я писал ранее.
#opa #k8s #dev #ops
Siloscape: First Known Malware Targeting Windows Containers to Compromise Cloud Environments
Разбор от Unit 42 (отдел исследований Palo Alto) вредоносного ПО Siloscape, которое использует Windows контейнеры для выходы за их пределы и эксплуатации мисконфигурации Kubernetes. Все это сопровождается коннектом до внешних C2-серверов через Tor-прокси. Инициализация вредоносного ПО предполагается через RCE веб-сервера.
Кстати, это не первая статья автора, которая посвящена безопасности Windows-контейнеров:
- Windows Server Containers Are Open, and Here's How You Can Break Out
- What I Learned from Reverse Engineering Windows Containers
Важно отметить, что Windows-контейнеры используют те же привилегии, что и хост, из-за чего не должны использоваться в качестве security boundary. Вместо этого рекомендуется использовать Hyper-V containers.
Обсудить можно здесь: @sec_devops_chat
#ops #attack #k8s
Разбор от Unit 42 (отдел исследований Palo Alto) вредоносного ПО Siloscape, которое использует Windows контейнеры для выходы за их пределы и эксплуатации мисконфигурации Kubernetes. Все это сопровождается коннектом до внешних C2-серверов через Tor-прокси. Инициализация вредоносного ПО предполагается через RCE веб-сервера.
Кстати, это не первая статья автора, которая посвящена безопасности Windows-контейнеров:
- Windows Server Containers Are Open, and Here's How You Can Break Out
- What I Learned from Reverse Engineering Windows Containers
Важно отметить, что Windows-контейнеры используют те же привилегии, что и хост, из-за чего не должны использоваться в качестве security boundary. Вместо этого рекомендуется использовать Hyper-V containers.
Обсудить можно здесь: @sec_devops_chat
#ops #attack #k8s
Unit 42
Siloscape: First Known Malware Targeting Windows Containers to Compromise Cloud Environments
The main purpose of Siloscape is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.
AquaSecurity_Cloud_Native_Threat_Report_2021.pdf
7.5 MB
Attacks in the Wild on the Container Supply Chain and Infrastructure
Помните отчет от Aqua, где они установили honeypot'ы для определения атак направленных на контейнерную среду? Они выпустили новый отчет, где атак было зафиксировано больше (рост на 26% за квартал), а результаты не менее интересны. Отчет достаточно хорошо описывает векторы атаки, связанные с MITRE ATT&CK, с приложенными скриншотами используемых скриптов.
#attack #docker #k8s #ops
Помните отчет от Aqua, где они установили honeypot'ы для определения атак направленных на контейнерную среду? Они выпустили новый отчет, где атак было зафиксировано больше (рост на 26% за квартал), а результаты не менее интересны. Отчет достаточно хорошо описывает векторы атаки, связанные с MITRE ATT&CK, с приложенными скриншотами используемых скриптов.
#attack #docker #k8s #ops
OPA instead of PSP
Большинство, кажется, уже в курсе, что PSP в Kubernetes перейдет в статус
Недавно в чат вкинули репо с правилами для OPA, которые можно взять за основу, чтобы полностью заменить PSP. Спасибо @Uburro!
#ops #k8s #ops
Большинство, кажется, уже в курсе, что PSP в Kubernetes перейдет в статус
deprecated в версии 1.21, а альфа-релиз замены появится только в 1.22, но тем не менее проблема будущего встроенного policy движка все еще стоит на повестке. Один из вариантов - Open Policy Agent (OPA) Gatekeeper.Недавно в чат вкинули репо с правилами для OPA, которые можно взять за основу, чтобы полностью заменить PSP. Спасибо @Uburro!
#ops #k8s #ops