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