Всем привет!
В статье описывается интересный подход к созданию набора OPA-проверок, которые формируются на основании входных данных.
Суть проста – у нас есть n проверок по различным группам, например, storage, network, compute, security и т.д. Скорее всего, за каждый тип проверок отвечают разные команды и разные люди.
Как быть в такой ситуации? Писать единое «полотно» с указанием всевозможных проверок по группам? И так для каждого приложения? А если их много? Вероятно, такой подход не является самым оптимальным и правильным.
В статье предлагается рассмотреть альтернативный подход – каждая команда создает свои проверки и создается общий main-файл, который возьмет на себя роль «роутера» и позволит перенаправлять запросы и получать обратную связь по проверкам.
Это придаст гибкость и повысит управляемость использования OPA-проверок. Небольшой пример описанного концепта приводится в статье ☺️
В статье описывается интересный подход к созданию набора OPA-проверок, которые формируются на основании входных данных.
Суть проста – у нас есть n проверок по различным группам, например, storage, network, compute, security и т.д. Скорее всего, за каждый тип проверок отвечают разные команды и разные люди.
Как быть в такой ситуации? Писать единое «полотно» с указанием всевозможных проверок по группам? И так для каждого приложения? А если их много? Вероятно, такой подход не является самым оптимальным и правильным.
В статье предлагается рассмотреть альтернативный подход – каждая команда создает свои проверки и создается общий main-файл, который возьмет на себя роль «роутера» и позволит перенаправлять запросы и получать обратную связь по проверкам.
Это придаст гибкость и повысит управляемость использования OPA-проверок. Небольшой пример описанного концепта приводится в статье ☺️
Styra
Dynamic Policy Composition for OPA
Learn how to use dynamic policy composition in Open Policy Agent (OPA) systems, across applications and infrastructure.
🔥1
Привет!
В продолжение темы проверки K8S-манифестов представляем kube-review! Небольшую утилиту, которая используется для трансформации манифеста в… AdmissionReview Request!
Это может быть удобно для локального тестирования манифестов, без необходимости обращения к Kubernetes API.
Можно тестировать:
🍭 Манифесты локально, в том числе с использованием OPA
🍭 Манифесты, использованные для запуска сущностей на кластере
Единственное, что не поддерживается kube-review – это CRD
В продолжение темы проверки K8S-манифестов представляем kube-review! Небольшую утилиту, которая используется для трансформации манифеста в… AdmissionReview Request!
Это может быть удобно для локального тестирования манифестов, без необходимости обращения к Kubernetes API.
Можно тестировать:
🍭 Манифесты локально, в том числе с использованием OPA
(kube-review... | opa eval...). Есть альтернативный вариант локального использования OPA, о нем мы писали тут🍭 Манифесты, использованные для запуска сущностей на кластере
(kubectl get pod -o yaml | kube-review... | opa eval...)
Таким образом можно сделать небольшой инструмент аудита, в том числе уже запущенных сущностей. Подобный функционал есть и у Gatekeeper/Kyverno, но kube-review может быть попроще для начала (например, потому что не требуется создание и настройка дополнительных сущностей в кластере)Единственное, что не поддерживается kube-review – это CRD
GitHub
GitHub - anderseknert/kube-review: Create Kubernetes AdmissionReview requests from Kubernetes resource manifests
Create Kubernetes AdmissionReview requests from Kubernetes resource manifests - anderseknert/kube-review
Привет!
Написание RBAC правил в Kubernetes не самое увлекательное занятие, в котором можно легко запутаться.
Иногда хочется некоторого полиморфизма – «Мне нужна почти такая же роль, толькос перламутровыми пуговицами с немного иными привилегиями…».
И все заново – перечисляем ресурсы, права… Можно ли как-то иначе?
Оказывается, можно! С проектом от Red Hat, который называется Dynamic RBAC-operator. Он как раз дает тот самый полиморфизм: мы указываем «родительскую» роль и на базе нее создаем нужную нам, внося небольшие правки и корректировки.
В repo есть отличный пример создания роли «admin-without-users», наследованной от «cluster-admin», но с некоторыми отличиями ☺️
Написание RBAC правил в Kubernetes не самое увлекательное занятие, в котором можно легко запутаться.
Иногда хочется некоторого полиморфизма – «Мне нужна почти такая же роль, только
И все заново – перечисляем ресурсы, права… Можно ли как-то иначе?
Оказывается, можно! С проектом от Red Hat, который называется Dynamic RBAC-operator. Он как раз дает тот самый полиморфизм: мы указываем «родительскую» роль и на базе нее создаем нужную нам, внося небольшие правки и корректировки.
В repo есть отличный пример создания роли «admin-without-users», наследованной от «cluster-admin», но с некоторыми отличиями ☺️
GitHub
GitHub - redhat-cop/dynamic-rbac-operator
Contribute to redhat-cop/dynamic-rbac-operator development by creating an account on GitHub.
👍4
NIST.SP.800-218.pdf
722.5 KB
Всех с пятницей!
В приложении свежий материал от NIST (февраль, 2022) – «Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities».
Framework вводит 4 группы практик:
🍭 Prepare The Organization (PO): в Компании должна быть зрелая культура, готовая принять практики безопасной разработки
🍭 Protect the Software (PS): защита всех компонентов ПО от изменений и несанкционированного доступа
🍭 Produce Well-Secured Software (PW): стремление к сокращению уязвимостей в ПО при релизах
🍭 Respond to Vulnerabilities (RV): управление «остаточными» уязвимостями
Далее, как обычно – перечень рекомендаций по группам, примеры реализации и, что особенно круто – готовый mapping на аналогичные контроли в других стандартах.
P.S. Сам по себе документ небольшой, всего 36 страниц. Всем отличного вечера пятницы и выходных!
В приложении свежий материал от NIST (февраль, 2022) – «Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities».
Framework вводит 4 группы практик:
🍭 Prepare The Organization (PO): в Компании должна быть зрелая культура, готовая принять практики безопасной разработки
🍭 Protect the Software (PS): защита всех компонентов ПО от изменений и несанкционированного доступа
🍭 Produce Well-Secured Software (PW): стремление к сокращению уязвимостей в ПО при релизах
🍭 Respond to Vulnerabilities (RV): управление «остаточными» уязвимостями
Далее, как обычно – перечень рекомендаций по группам, примеры реализации и, что особенно круто – готовый mapping на аналогичные контроли в других стандартах.
P.S. Сам по себе документ небольшой, всего 36 страниц. Всем отличного вечера пятницы и выходных!
🔥2
Привет!
Хорошая обзорная статья про Persistent Volume и как его настроить. Каждый pod, по умолчанию, потеряет данные после того, как будет воссоздан заново.
Для того, чтобы исправить это используются механизмы Volume (грубо говоря – папку на worker node) и Persistent Volume.
Именно о вторых и пойдет речь в статье:
🍭 Что такое Persistent Volume (PV) и принципы его работы
🍭 В чем разница между Storage Class, Persistent Volume и Persistent Volume Claim
🍭 Режимы доступа (Access Modes): ROX, RWO, RWX, RWOP. Приводится краткое описание каждого режима доступа
🍭 Описание процесса выделения дискового пространства pod’у: выбор подходящего Storage Class, определение требуемого объема памяти (Persistent Volume), создание Persistent Volume Claim, чтобы у pod была возможность использования внешнего хранилища данных
В завершении статьи приводится пример того, как это можно реализовать. Как всегда, с кодом, командами и небольшими пояснениями ☺️
Хорошая обзорная статья про Persistent Volume и как его настроить. Каждый pod, по умолчанию, потеряет данные после того, как будет воссоздан заново.
Для того, чтобы исправить это используются механизмы Volume (грубо говоря – папку на worker node) и Persistent Volume.
Именно о вторых и пойдет речь в статье:
🍭 Что такое Persistent Volume (PV) и принципы его работы
🍭 В чем разница между Storage Class, Persistent Volume и Persistent Volume Claim
🍭 Режимы доступа (Access Modes): ROX, RWO, RWX, RWOP. Приводится краткое описание каждого режима доступа
🍭 Описание процесса выделения дискового пространства pod’у: выбор подходящего Storage Class, определение требуемого объема памяти (Persistent Volume), создание Persistent Volume Claim, чтобы у pod была возможность использования внешнего хранилища данных
В завершении статьи приводится пример того, как это можно реализовать. Как всегда, с кодом, командами и небольшими пояснениями ☺️
Medium
Kubernetes Persistent Volume Explained
Learn what a Persistent Volume is and how to create a persistent volume from a storage class. Then, learn how to create a persistent volume…
Всем привет!
В repo доступна ссылка на Container Security Checklist от Carol Valencia, участницы команды Aqua Security.
Подборка сделана с привязкой к жизненному циклу контейнера и покрывает аспекты ИБ, значимые как при создании образа, так и при последующей его эксплуатации в качестве контейнера (workload).
Подборка структурирована по категориям:
🍭 Secure the Build. Повышение защищенности образов во время сборки, использование Hadolint для проверки Dockerfile, сканирование образов на наличие уязвимостей, подпись образов
🍭 Secure the Container Registry. Использование private registry, управление доступом с использованием RBAC
🍭 Secure the Container Runtime. Настройка runtime в соответствии с лучшими практиками (CIS Benchmark)
🍭 Secure the Infrastructure. Управление уязвимостями и обновлениями для хостов, настройка хостов в соответствии с рекомендациями CIS Benchmark
🍭 Secure the Data. Контроль доступа к файловой системе, корректная инъекция секретов
🍭 Secure the Workloads. Контроль действий контейнеров, применение практик контроля drift prevention для обеспечения неизменяемости (immutable) контейнеров
Подборка содержит как общие советы по информационной безопасности, так и вполне конкретные действия. Также можно найти ссылки на open source инструменты и статьи, которые могут быть использованы для выполнения ряда требований
В repo доступна ссылка на Container Security Checklist от Carol Valencia, участницы команды Aqua Security.
Подборка сделана с привязкой к жизненному циклу контейнера и покрывает аспекты ИБ, значимые как при создании образа, так и при последующей его эксплуатации в качестве контейнера (workload).
Подборка структурирована по категориям:
🍭 Secure the Build. Повышение защищенности образов во время сборки, использование Hadolint для проверки Dockerfile, сканирование образов на наличие уязвимостей, подпись образов
🍭 Secure the Container Registry. Использование private registry, управление доступом с использованием RBAC
🍭 Secure the Container Runtime. Настройка runtime в соответствии с лучшими практиками (CIS Benchmark)
🍭 Secure the Infrastructure. Управление уязвимостями и обновлениями для хостов, настройка хостов в соответствии с рекомендациями CIS Benchmark
🍭 Secure the Data. Контроль доступа к файловой системе, корректная инъекция секретов
🍭 Secure the Workloads. Контроль действий контейнеров, применение практик контроля drift prevention для обеспечения неизменяемости (immutable) контейнеров
Подборка содержит как общие советы по информационной безопасности, так и вполне конкретные действия. Также можно найти ссылки на open source инструменты и статьи, которые могут быть использованы для выполнения ряда требований
GitHub
GitHub - krol3/container-security-checklist: Checklist for container security - devsecops practices
Checklist for container security - devsecops practices - krol3/container-security-checklist
👍4
Привет!
Вчера мы писали про лучшие практики по защите контейнеров на разных этапах жизненного цикла. Одной из таких практик, применимой для runtime, является контроль drift prevention.
Есть один занимательный способ, как это можно реализовать при помощи… Admission Controller и инструмента kube-exec-controller!
Идея ребят из Box простая и достаточно элегантная:
🍭 У нас есть Validating Webhook, который срабатывает для
🍭 Чтобы понять, к какому именно pod было «обращение» средствами kube-exec-controller вешается метка (label), в которой содержится информация о времени exec, об инициаторе
🍭 Дальше – интересней! Все pods, обладающие такой «черной меткой» начнут eviction process. Авторы подумали о том, что иногда exec бывает удобен и нужен, например, при debug. По этой причине они добавили Pod Time-To-Life (TTL), который больше для Dev-окружений и крайне мал для Prod-окружений
Чтобы с этим инструментом было проще работать ребята сделали kubectl plugin, получивший имя kubectl pi (сокращенно от pod interaction), который может показывать «меченых» и управлять временем TTL.
Если интересно – то можно почитать статью в официальном блоге Kubernetes, где детализируется этот концепт и есть наглядные схемы ☺️
Вчера мы писали про лучшие практики по защите контейнеров на разных этапах жизненного цикла. Одной из таких практик, применимой для runtime, является контроль drift prevention.
Есть один занимательный способ, как это можно реализовать при помощи… Admission Controller и инструмента kube-exec-controller!
Идея ребят из Box простая и достаточно элегантная:
🍭 У нас есть Validating Webhook, который срабатывает для
[pods/exec, pods/attach]. Он их «пропускает», но событие мы регистрируем🍭 Чтобы понять, к какому именно pod было «обращение» средствами kube-exec-controller вешается метка (label), в которой содержится информация о времени exec, об инициаторе
🍭 Дальше – интересней! Все pods, обладающие такой «черной меткой» начнут eviction process. Авторы подумали о том, что иногда exec бывает удобен и нужен, например, при debug. По этой причине они добавили Pod Time-To-Life (TTL), который больше для Dev-окружений и крайне мал для Prod-окружений
Чтобы с этим инструментом было проще работать ребята сделали kubectl plugin, получивший имя kubectl pi (сокращенно от pod interaction), который может показывать «меченых» и управлять временем TTL.
Если интересно – то можно почитать статью в официальном блоге Kubernetes, где детализируется этот концепт и есть наглядные схемы ☺️
GitHub
GitHub - box/kube-exec-controller: An admission controller service and kubectl plugin to handle container drift in K8s clusters
An admission controller service and kubectl plugin to handle container drift in K8s clusters - box/kube-exec-controller
👍3
Всем привет!
В статье рассказывается про то, как можно использовать возможности LinkerD для контроля трафика внутри K8S кластера.
Для этого используется механизм Traffic Policy (не путать с Network Policy), который в отличие от своего «K8S аналога» позволяет в том числе реализовать mTLS.
Статья разбита на несколько частей:
🍭 Принципы работы и способы конфигурации
🍭 Наглядный пример контроля трафика: запрет между namespace, разрешение внутри namespace, исключение из правила для некоторого трафика между namespace (например, health checks, metrics)
В завершении – подробная инструкция, «шаг за шагом», как это можно реализовать с примерами YAML и описанием действий
В статье рассказывается про то, как можно использовать возможности LinkerD для контроля трафика внутри K8S кластера.
Для этого используется механизм Traffic Policy (не путать с Network Policy), который в отличие от своего «K8S аналога» позволяет в том числе реализовать mTLS.
Статья разбита на несколько частей:
🍭 Принципы работы и способы конфигурации
🍭 Наглядный пример контроля трафика: запрет между namespace, разрешение внутри namespace, исключение из правила для некоторого трафика между namespace (например, health checks, metrics)
В завершении – подробная инструкция, «шаг за шагом», как это можно реализовать с примерами YAML и описанием действий
buoyant.io
Go directly to namespace jail: Locking down network traffic between Kubernetes namespaces
How do you restrict network traffic between namespaces in a Kubernetes cluster? Whether you’re running a multi-tenant cluster with strict isolation guarantees or simply want to introduce a layer of control, locking down namespaces within a cluster is a common…
👍1
Всем привет!
Небольшой longread (~ 10 минут), посвященный использованию sigstore stack (Cosign, Rekor и Fulcio) для подписи и проверки подписи образов контейнеров.
Все происходит постепенно:
🍭 Сперва демонстрируются возможности Cosign для подписи «локального» образа с использованием «локальных» ключей
🍭 Далее – добавляем Rekor в качестве альтернативного/дополнительного источника истины. Схема взаимодействия и количество компонентов сильно меняется
🍭 В завершении – концепт keyless sign с использованием Fulcio и Cosign
В статье приведены наглядные схемы взаимодействия компонентов и приводится много примеров и, конечно же, код, код и еще раз код. Рекомендуем к прочтению!
Небольшой longread (~ 10 минут), посвященный использованию sigstore stack (Cosign, Rekor и Fulcio) для подписи и проверки подписи образов контейнеров.
Все происходит постепенно:
🍭 Сперва демонстрируются возможности Cosign для подписи «локального» образа с использованием «локальных» ключей
🍭 Далее – добавляем Rekor в качестве альтернативного/дополнительного источника истины. Схема взаимодействия и количество компонентов сильно меняется
🍭 В завершении – концепт keyless sign с использованием Fulcio и Cosign
В статье приведены наглядные схемы взаимодействия компонентов и приводится много примеров и, конечно же, код, код и еще раз код. Рекомендуем к прочтению!
www.chainguard.dev
sigstore, the local way
Build and run Sigstore locally to easily sign and verify container images without external dependencies. Everything you need to know about securing the software supply chain.
👍1
Привет!
Поиск проблем в сетевом взаимодействии – не самый тривиальный процесс, особенно когда дело касается контейнеров.
Именно для этого ребята сделали netshoot, который описали, как «швейцарский нож» для идентификации проблем в сети.
Он может быть полезен для выявления причин:
🍭 Проблем с latency
🍭 Некорректного routing
🍭 Ошибок в DNS resolution
🍭 Некорректной конфигурации firewall
🍭 Ошибок в ARP
Внутри repo есть перечень всего, что включено в netshoot, а также удобная графическая диаграмма, описывающая варианты применения инструментов и объектов для анализа.
Кроме того, в repo можно найти примеры использования netshoot (use case): iperf, tcpdump, netstat, nmap и другие.
Еще один вариант подобного инструмента - Network-MultiTool. Он является более актуальным, если смотреть по обновлениям repo.
Как и Netshoot, Network-MultiTool содержит в себе большое количество утилит для поиска проблем в сети. Есть несколько вариантов, которые отличаются набором утилит: Minimal и Extra.
Детальное описание "состава" можно найти в repo.
Поиск проблем в сетевом взаимодействии – не самый тривиальный процесс, особенно когда дело касается контейнеров.
Именно для этого ребята сделали netshoot, который описали, как «швейцарский нож» для идентификации проблем в сети.
Он может быть полезен для выявления причин:
🍭 Проблем с latency
🍭 Некорректного routing
🍭 Ошибок в DNS resolution
🍭 Некорректной конфигурации firewall
🍭 Ошибок в ARP
Внутри repo есть перечень всего, что включено в netshoot, а также удобная графическая диаграмма, описывающая варианты применения инструментов и объектов для анализа.
Кроме того, в repo можно найти примеры использования netshoot (use case): iperf, tcpdump, netstat, nmap и другие.
Еще один вариант подобного инструмента - Network-MultiTool. Он является более актуальным, если смотреть по обновлениям repo.
Как и Netshoot, Network-MultiTool содержит в себе большое количество утилит для поиска проблем в сети. Есть несколько вариантов, которые отличаются набором утилит: Minimal и Extra.
Детальное описание "состава" можно найти в repo.
GitHub
GitHub - nicolaka/netshoot: a Docker + Kubernetes network trouble-shooting swiss-army container
a Docker + Kubernetes network trouble-shooting swiss-army container - nicolaka/netshoot
Всем привет!
Некоторое время назад SUSE купила NeuVector. А в январе 2022 года она сделала его open source: «The work to fully open source a formerly proprietary technology is a testament to SUSE’s open-source culture and our commitment to deliver open, interoperable and innovative solutions to our partners and customers»
NeuVector - комплексное решение по защите сред контейнерной оркестрации. У него достаточно много функций, в том числе по защите runtime:
🍭 Контроль сетевых соединений (monitor/prevent)
🍭 Контроль запускаемых процессов внутри контейнеров (monitor/prevent)
🍭 Сканирование образов контейнеров на наличие уязвимостей
🍭 Compliance-проверки для nodes
🍭 Admission controller для анализа запускаемых в кластере сущностей и многое другое
Описывать все функции в TG-посте вряд ли получится, это не полезная утилита, а полноценное решение, которое ранее было enterprise. Если вам интересно узнать больше о его возможностях – рекомендуем почитать документацию.
P.S. Ссылка на новость о покупке NeuVector компанией SUSE
P.P.S Ссылка на новость о том, что NeuVector стал open source
Некоторое время назад SUSE купила NeuVector. А в январе 2022 года она сделала его open source: «The work to fully open source a formerly proprietary technology is a testament to SUSE’s open-source culture and our commitment to deliver open, interoperable and innovative solutions to our partners and customers»
NeuVector - комплексное решение по защите сред контейнерной оркестрации. У него достаточно много функций, в том числе по защите runtime:
🍭 Контроль сетевых соединений (monitor/prevent)
🍭 Контроль запускаемых процессов внутри контейнеров (monitor/prevent)
🍭 Сканирование образов контейнеров на наличие уязвимостей
🍭 Compliance-проверки для nodes
🍭 Admission controller для анализа запускаемых в кластере сущностей и многое другое
Описывать все функции в TG-посте вряд ли получится, это не полезная утилита, а полноценное решение, которое ранее было enterprise. Если вам интересно узнать больше о его возможностях – рекомендуем почитать документацию.
P.S. Ссылка на новость о покупке NeuVector компанией SUSE
P.P.S Ссылка на новость о том, что NeuVector стал open source
GitHub
GitHub - neuvector/neuvector
Contribute to neuvector/neuvector development by creating an account on GitHub.
Привет!
В продолжение темы анализа сетевой связности для идентификации проблем. Если вы не хотите использовать для этого контейнеры и вам удобнее работать через kubectl… то есть отличный plugin – ksniff!
Он крайне прост в использовании: перенаправление tcpdump в локальный instance Wireshark.
Далее – используем привычный инструмент для разбора трафика.
Если хотите направить информацию в stdout – это также возможно (пример есть в repo).
Важно (!): согласно описанию ksniff пока лучше не использовать в production-окружениях.
P.S. О контейнерах, в которых собраны необходимые инструменты для анализа сетевого трафика мы писали тут
В продолжение темы анализа сетевой связности для идентификации проблем. Если вы не хотите использовать для этого контейнеры и вам удобнее работать через kubectl… то есть отличный plugin – ksniff!
Он крайне прост в использовании: перенаправление tcpdump в локальный instance Wireshark.
Далее – используем привычный инструмент для разбора трафика.
Если хотите направить информацию в stdout – это также возможно (пример есть в repo).
Важно (!): согласно описанию ksniff пока лучше не использовать в production-окружениях.
P.S. О контейнерах, в которых собраны необходимые инструменты для анализа сетевого трафика мы писали тут
GitHub
GitHub - eldadru/ksniff: Kubectl plugin to ease sniffing on kubernetes pods using tcpdump and wireshark
Kubectl plugin to ease sniffing on kubernetes pods using tcpdump and wireshark - eldadru/ksniff
👍1
Всем привет!
Хорошая обзорная статья от ребят из Flant, посвященная Kube-Bench и Kube-Hunter. Это open source утилиты, которые можно использовать при анализе ИБ сред контейнерной оркестрации.
🍭 Kube-Bench анализирует узлы кластера на соответствие требованиям CIS-benchmark. Можно включать и отключать проверки на усмотрение аналитика
🍭 Kube-Hunter позволяет взглянуть на кластер «глазами атакующего». Работает в нескольких режимах: Passive и Active. При этом в Active-режиме может изменить состояние кластера
В статье автор рассказывает про общие принципы работы, про возможности запуска (локально, в виде контейнера, внутри анализируемого кластера), про возможности настройки и, что самое интересное – приводит свои мысли по поводу результатов.
Вывод простой – использовать инструменты можно и нужно, но «слепо» следовать рекомендациям лучше не стоит. Ко всему стоит подходить с критическим мышлением и анализом возможных последствий
Хорошая обзорная статья от ребят из Flant, посвященная Kube-Bench и Kube-Hunter. Это open source утилиты, которые можно использовать при анализе ИБ сред контейнерной оркестрации.
🍭 Kube-Bench анализирует узлы кластера на соответствие требованиям CIS-benchmark. Можно включать и отключать проверки на усмотрение аналитика
🍭 Kube-Hunter позволяет взглянуть на кластер «глазами атакующего». Работает в нескольких режимах: Passive и Active. При этом в Active-режиме может изменить состояние кластера
В статье автор рассказывает про общие принципы работы, про возможности запуска (локально, в виде контейнера, внутри анализируемого кластера), про возможности настройки и, что самое интересное – приводит свои мысли по поводу результатов.
Вывод простой – использовать инструменты можно и нужно, но «слепо» следовать рекомендациям лучше не стоит. Ко всему стоит подходить с критическим мышлением и анализом возможных последствий
Palark
Kubernetes cluster security assessment with kube-bench and kube-hunter
Improving the security of your clusters can be easier: here's how you can benefit from well-known Open Source tools.
👍2
Всем привет!
Недавно была опубликована новая уязвимость – CVE-2022-0847, получившая имя «Dirty Pipe». Ее эксплуатация позволяет модифицировать файлы, которые должны быть доступны только для чтения.
Интересный анализ влияния этой уязвимости на контейнеры провел Rory McCune из команды Aqua Security. Он применил ее для модификации файлов в используемых образах контейнеров.
Если упростить, то модификация существующего файла в контейнере никак не должна модифицировать этот самый файл в используемом образе, что обусловлено использованием overlay filesystems.
Для проверки гипотезы Rory сделал следующее:
🍭 Взял самый обычный образ Ubuntu 21.04 с Dockerhub
🍭 При помощи exploit, подготовленного Max Kellerman, добавил “Hello world” в /etc/shells, находясь внутри контейнера [1]
🍭 Запустил новый контейнер [2] из того же самого образа Ubuntu 21.04 и… “Hello world” был в /etc/shells
Детали, screenshots и т.д. – можно посмотреть в статье по ссылке. Также рекомендуем почитать пост в блоге Max Kellerman, в котором приведено детальное описание Dirty Pipe, информация о способах противодействия (как обычно – patch) и пример рабочего exploit
P.S. Ссылка на саму CVE-2022-0847 в NVD
Недавно была опубликована новая уязвимость – CVE-2022-0847, получившая имя «Dirty Pipe». Ее эксплуатация позволяет модифицировать файлы, которые должны быть доступны только для чтения.
Интересный анализ влияния этой уязвимости на контейнеры провел Rory McCune из команды Aqua Security. Он применил ее для модификации файлов в используемых образах контейнеров.
Если упростить, то модификация существующего файла в контейнере никак не должна модифицировать этот самый файл в используемом образе, что обусловлено использованием overlay filesystems.
Для проверки гипотезы Rory сделал следующее:
🍭 Взял самый обычный образ Ubuntu 21.04 с Dockerhub
🍭 При помощи exploit, подготовленного Max Kellerman, добавил “Hello world” в /etc/shells, находясь внутри контейнера [1]
🍭 Запустил новый контейнер [2] из того же самого образа Ubuntu 21.04 и… “Hello world” был в /etc/shells
Детали, screenshots и т.д. – можно посмотреть в статье по ссылке. Также рекомендуем почитать пост в блоге Max Kellerman, в котором приведено детальное описание Dirty Pipe, информация о способах противодействия (как обычно – patch) и пример рабочего exploit
P.S. Ссылка на саму CVE-2022-0847 в NVD
Aqua
Dirty Pipe Linux Vulnerability: Overwriting Files in Container Images
CVE-2022-0847 Dirty Pipe in the Linux kernel allows users on Linux hosts running containerized applications to modify files in container images on the host
👍1
Привет!
В последнее время участились случаи добавления в open source проекты модификаций, применимых при использовании на территории РФ.
Они могут быть безобидными для ИТ - например, вставка каких-то сообщений в логи, а могут быть и достаточно "ощутимыми" - например, перезапись содержимого файла (пример с VueJS).
Одним из выходов (по возможности) может быть явное указание версий (проверенных) используемого open source без обновления до последних/актуальных версий.
Второй - контроль и аналитика используемого open source в сборке и создание SBOM, чтобы оперативно понять - присутствует ли уязвимый компонент у вас или нет.
Есть инициатива по ведению реестра такого "искаженного" open source, пока что просто в google-документах. Если у вас есть, что добавить в этот перечень, нужно воспользоваться формой.
В последнее время участились случаи добавления в open source проекты модификаций, применимых при использовании на территории РФ.
Они могут быть безобидными для ИТ - например, вставка каких-то сообщений в логи, а могут быть и достаточно "ощутимыми" - например, перезапись содержимого файла (пример с VueJS).
Одним из выходов (по возможности) может быть явное указание версий (проверенных) используемого open source без обновления до последних/актуальных версий.
Второй - контроль и аналитика используемого open source в сборке и создание SBOM, чтобы оперативно понять - присутствует ли уязвимый компонент у вас или нет.
Есть инициатива по ведению реестра такого "искаженного" open source, пока что просто в google-документах. Если у вас есть, что добавить в этот перечень, нужно воспользоваться формой.
GitHub
!!!!!!!!!!!! Please do something to warn USERS besides publishing new versions · Issue #7054 · vuejs/vue-cli
See https://github.com/RIAEvangelist/node-ipc/issues/233#issuecomment-1068182278 the node-ipc is doing things far more than ever expected. If any users are using ip in russia, all their file will b...
👍3
NSA_CISA_K8S.PDF
1.8 MB
Всем привет!
В марте 2022 года CISA и NSA обновили свой Kubernetes Hardening Guide.
Первая версия была выпущена в августе 2021 и получила смешанные отзывы. Отчасти это связано с тем, что первая версия рассматривала способы повышения ИБ кластера, которые были deprecated, например, Pod Security Policy.
Ребята прислушались к мнению community и доработали документ. Он состоит из следующих частей:
🍭 Threat Model
🍭 Kubernetes Pod Security
🍭 Network Separation and Hardening
🍭 Authentication and Authorization
🍭 Audit Logging and Threat Detection
Кстати, некоторые «артефакты» первой версии все еще есть в Приложениях, однако, там теперь явно указано о статусе «Deprecated». Сам документ прилагаем.
В марте 2022 года CISA и NSA обновили свой Kubernetes Hardening Guide.
Первая версия была выпущена в августе 2021 и получила смешанные отзывы. Отчасти это связано с тем, что первая версия рассматривала способы повышения ИБ кластера, которые были deprecated, например, Pod Security Policy.
Ребята прислушались к мнению community и доработали документ. Он состоит из следующих частей:
🍭 Threat Model
🍭 Kubernetes Pod Security
🍭 Network Separation and Hardening
🍭 Authentication and Authorization
🍭 Audit Logging and Threat Detection
Кстати, некоторые «артефакты» первой версии все еще есть в Приложениях, однако, там теперь явно указано о статусе «Deprecated». Сам документ прилагаем.
🔥3
Всем привет!
Regula – простая и удобная утилита, которая позволяет идентифицировать недостатки в конфигурационных файлах Cloud Formation, Terraform, Azure Resource Management и Kubernetes.
"Из коробки" доступна часть правил, их можно добавлять самостоятельно. Есть небольшая инструкция с рекомендациями в официальной документации.
А если не хочется тестировать локально, но все равно интересно посмотреть на результаты, то можно почитать статью, в которой:
🍭 Используется простой pod-манифест, который «с первого взгляда» вроде и не очень опасен
🍭 Этот манифест анализируется при помощи Regula далее идет процесс по привидению в соответствие с комментариями от автора
Есть несколько вариантов использования: например, локальный анализ манифестов или встраивание Regula в pipeline для автоматизации указанных проверок
Regula – простая и удобная утилита, которая позволяет идентифицировать недостатки в конфигурационных файлах Cloud Formation, Terraform, Azure Resource Management и Kubernetes.
"Из коробки" доступна часть правил, их можно добавлять самостоятельно. Есть небольшая инструкция с рекомендациями в официальной документации.
А если не хочется тестировать локально, но все равно интересно посмотреть на результаты, то можно почитать статью, в которой:
🍭 Используется простой pod-манифест, который «с первого взгляда» вроде и не очень опасен
🍭 Этот манифест анализируется при помощи Regula далее идет процесс по привидению в соответствие с комментариями от автора
Есть несколько вариантов использования: например, локальный анализ манифестов или встраивание Regula в pipeline для автоматизации указанных проверок
GitHub
GitHub - fugue/regula: Regula checks infrastructure as code templates (Terraform, CloudFormation, k8s manifests) for AWS, Azure…
Regula checks infrastructure as code templates (Terraform, CloudFormation, k8s manifests) for AWS, Azure, Google Cloud, and Kubernetes security and compliance using Open Policy Agent/Rego - fugue/r...
Способы интеграции HashiCorp Vault и Kubernetes
Всем привет!
В статье приводится сравнение способов интеграции HashiCorp Vault и Kubernetes, которое можно реализовать несколькими способами:
🍭 Использование Vault Sidecar Injector
🍭 Использованием Vault Container Storage Interface (CSI) Provider
Начинается статья с общего описания и принципов работы Vault Sidecar и Vault CSI, что они из себя представляют и как решают задачу по инъекции секретов в контейнеры.
Далее – описываются преимущества и недостатки подходов, а в конце – самое интересное! Сводная таблица, резюмирующая все, о чем говорится в статье.
Итого: станет понятно, в чем разница и какой способ является оптимальным для вас ☺️
Если кратко, то Vault Sidecar обладает большим функционалом, однако Vault CSI гораздо проще реализовать и поддерживать.
Всем привет!
В статье приводится сравнение способов интеграции HashiCorp Vault и Kubernetes, которое можно реализовать несколькими способами:
🍭 Использование Vault Sidecar Injector
🍭 Использованием Vault Container Storage Interface (CSI) Provider
Начинается статья с общего описания и принципов работы Vault Sidecar и Vault CSI, что они из себя представляют и как решают задачу по инъекции секретов в контейнеры.
Далее – описываются преимущества и недостатки подходов, а в конце – самое интересное! Сводная таблица, резюмирующая все, о чем говорится в статье.
Итого: станет понятно, в чем разница и какой способ является оптимальным для вас ☺️
Если кратко, то Vault Sidecar обладает большим функционалом, однако Vault CSI гораздо проще реализовать и поддерживать.
👍5
Профилирование приложений для оптимизации их работы
Привет!
Для поиска проблем в работающем ПО зачастую обращаются к логам. Но этого может быть не всегда достаточно.
В статье автор предлагает рассмотреть возможность профилирования приложения для идентификации «проблемных мест» (bottlenecks).
Основная цель профилирования – оптимизация эффективности работы, что достигается за счет анализа потребления памяти, времени выполнения отдельных функций и т.д.
В качестве инструмента рассматривается open source продукт – Pyroscope. Автор приводит принципы его работы, сведения о поддерживаемых языках и об архитектуре.
В завершении – установка, настройка и несколько примеров встраивания для Python, .Net и Golang.
Полученную информацию можно фильтровать и анализировать для того, чтобы идентифицировать наиболее ресурсоемкие/длительные операции и разбираться «а должно ли оно быть так на самом деле?»
P.S. Ссылка на открытую документацию Pyroscope
Привет!
Для поиска проблем в работающем ПО зачастую обращаются к логам. Но этого может быть не всегда достаточно.
В статье автор предлагает рассмотреть возможность профилирования приложения для идентификации «проблемных мест» (bottlenecks).
Основная цель профилирования – оптимизация эффективности работы, что достигается за счет анализа потребления памяти, времени выполнения отдельных функций и т.д.
В качестве инструмента рассматривается open source продукт – Pyroscope. Автор приводит принципы его работы, сведения о поддерживаемых языках и об архитектуре.
В завершении – установка, настройка и несколько примеров встраивания для Python, .Net и Golang.
Полученную информацию можно фильтровать и анализировать для того, чтобы идентифицировать наиболее ресурсоемкие/длительные операции и разбираться «а должно ли оно быть так на самом деле?»
P.S. Ссылка на открытую документацию Pyroscope
Beellz Dev
Continuous Profiling in Kubernetes Using Pyroscope
Let's look into continuous profiling in K8s clusters & dive deep into how you can monitor CPU usage with Pyroscope to identify performance bottlenecks
👍1
Бесплатные курсы по Dev(Sec)Ops
Всем привет!
По ссылке приводится емкий обзор бесплатных курсов по тематике Dev(Sec)Ops. Примеры того, что можно найти «внутри»:
🍭 GitOps Fundamentals
🍭 Certified Calico Operator: Level 1
🍭 Gitlab 101 Certification
🍭 Elastic Observability Fundamentals
🍭 Introduction to Service Mesh with Linkerd
И много другое! Есть как «просто курсы», так и подборки материалов (видео/статей) по теме, как, например, VMWare Kube Academy или Aqua Cloud Native Academy
Всем привет!
По ссылке приводится емкий обзор бесплатных курсов по тематике Dev(Sec)Ops. Примеры того, что можно найти «внутри»:
🍭 GitOps Fundamentals
🍭 Certified Calico Operator: Level 1
🍭 Gitlab 101 Certification
🍭 Elastic Observability Fundamentals
🍭 Introduction to Service Mesh with Linkerd
И много другое! Есть как «просто курсы», так и подборки материалов (видео/статей) по теме, как, например, VMWare Kube Academy или Aqua Cloud Native Academy
Medium
Cloud Native Free Training and Certifications
We are already a little past the middle of 2021, which has been as convulsive and unpredictable as 2020, which surprised us with so many…
🔥8👍1
Управление инфраструктурой через… Kubernetes!
Привет!
Любите Kubernetes, любите YAML(вы правда есть?), любите писать CRD и хотите управлять всей инфраструктурой, как сущностями Kubernetes?
Тогда проект Crossplane для вас! Согласно документации, он «превращает ваш K8S кластер в универсальный control plane, что позволяет ему (кластеру) управлять ИТ-инфраструктурой и managed-сервисами».
Работает все это через CRD, которых "из коробки" достаточно много, например:
🍭 Helm
🍭 Terraform
🍭 SQL
🍭 GitLab
🍭 Styra
И другие (полный перечень можно найти по ссылке). После установки и настройки Crossplane создаем YAML-файлы с описанием, например, БД, применяем их на кластере и «общаемся» с ними через знакомые
Возможно, такой подход покажется не самым удобным, но имеет место быть, да и сама идея достаточно оригинальная.
Если хочется узнать больше про архитектуру, сценарии использования, рекомендуем почитать вот этот документ.
P.S. У Crossplane открытая документация, с которой можно ознакомиться по ссылке.
Привет!
Любите Kubernetes, любите YAML
Тогда проект Crossplane для вас! Согласно документации, он «превращает ваш K8S кластер в универсальный control plane, что позволяет ему (кластеру) управлять ИТ-инфраструктурой и managed-сервисами».
Работает все это через CRD, которых "из коробки" достаточно много, например:
🍭 Helm
🍭 Terraform
🍭 SQL
🍭 GitLab
🍭 Styra
И другие (полный перечень можно найти по ссылке). После установки и настройки Crossplane создаем YAML-файлы с описанием, например, БД, применяем их на кластере и «общаемся» с ними через знакомые
kubectl get ... и т.д.Возможно, такой подход покажется не самым удобным, но имеет место быть, да и сама идея достаточно оригинальная.
Если хочется узнать больше про архитектуру, сценарии использования, рекомендуем почитать вот этот документ.
P.S. У Crossplane открытая документация, с которой можно ознакомиться по ссылке.
crossplane.io
Crossplane Is the Cloud-Native Framework for Platform Engineering
Create platforms like cloud providers by building your own APIs and services with control planes, extending Kubernetes to manage any resource anywhere, and using a library of components to assemble your platform faster
👍1