Всем привет!
Это птица? Это самолёт? Это Network Policy Editor for Kubernetes!
Сколько копий сломано по безопасности сети в Kubernetes, сколько слов об этом сказано, но так мало говорят о том, как конфигурировать сетевые правила удобно.
Безусловно, декларативное описание настроек это хорошо и правильно. Весь Kubernetes на этом построен. Но как все же порой хочется, чтобы унылый текст конфигураций превратился в нечто более наглядное и user-friendly.
И вот, свершилось! То чего многие так ждали! Интерактивный редактор сетевых политик!
Проект Cilium представляет ряд решений по управлению сетью в Kubernetes. Однако Network policy Editor for Kubernetes выделяется среди них своей нежной заботой об администраторе Kubernetes. Да, может и не труЪ, зато красиво и понятно.
Как пользоваться? Все просто:
🍩 На схеме обозначить ресурсы
🍩 Наглядно описать сетевое правило
🍩 Убедиться что все верно
🍩 Готово!
Дальше NPEK переформатирует правило в манифест и его можно применять в кластере!
С радостью делимся ссылкой на редактор, а подробную информацию о проекте можно найти на сайте разработчика 👇
https://cilium.io/blog/2021/02/10/network-policy-editor
P.S. с портативных браузеров редактор не открывается, иначе будет неудобно с ним работать ☺️
Это птица? Это самолёт? Это Network Policy Editor for Kubernetes!
Сколько копий сломано по безопасности сети в Kubernetes, сколько слов об этом сказано, но так мало говорят о том, как конфигурировать сетевые правила удобно.
Безусловно, декларативное описание настроек это хорошо и правильно. Весь Kubernetes на этом построен. Но как все же порой хочется, чтобы унылый текст конфигураций превратился в нечто более наглядное и user-friendly.
И вот, свершилось! То чего многие так ждали! Интерактивный редактор сетевых политик!
Проект Cilium представляет ряд решений по управлению сетью в Kubernetes. Однако Network policy Editor for Kubernetes выделяется среди них своей нежной заботой об администраторе Kubernetes. Да, может и не труЪ, зато красиво и понятно.
Как пользоваться? Все просто:
🍩 На схеме обозначить ресурсы
🍩 Наглядно описать сетевое правило
🍩 Убедиться что все верно
🍩 Готово!
Дальше NPEK переформатирует правило в манифест и его можно применять в кластере!
С радостью делимся ссылкой на редактор, а подробную информацию о проекте можно найти на сайте разработчика 👇
https://cilium.io/blog/2021/02/10/network-policy-editor
P.S. с портативных браузеров редактор не открывается, иначе будет неудобно с ним работать ☺️
editor.networkpolicy.io
Network Policy Editor for Kubernetes
editor.networkpolicy.io makes it easy to build, visualize, and make sense of Network Policies, which can then be downloaded as YAML and run in any Kubernetes cluster with a Network Policy-aware CNI.
Всем привет!
В библиотеке IEEE Xplore есть интересная статья про контейнеры и безопасность. Она называется Container Security: Issues, Challenges, and the Road Ahead (апрель 2019).
Цель этой статьи со слов авторов – помочь разобраться в требованиях к ИБ в части контейнеров и дать более четкое представление о возможных уязвимостях и атаках.
Авторы проанализировали различную литературу, сформировали 4 глобальных типа требований по безопасности (они называют это use cases) с разбивкой по способу реализации (software/hardware) и для каждой составили модель угроз с описанием угрозы, атаки, примера исполнения и варианта устранения.
Пример 1:
🍡Use case I: защита контейнеров от запускаемых в них приложений
🍡Угроза: Уязвимости в образах
🍡Атака: Remote Code Execution
🍡Сценарий: Эксплуатация уязвимости CVE-2014-6271 (ShellShock)
🍡Решение: периодические сканирование образов на уязвимости
Пример 2:
🍡Use case 2: защита взаимодействий между контейнерами
🍡Угроза: бесконтрольный сетевой доступ между контейнерами
🍡Атака: сканирование портов, поиск уязвимостей
🍡Сценарий: использование скомпрометированного контейнера для поиска и сканирования контейнеров, размещенных в других сетях с иным уровнем доступа
🍡Решение: разделение контейнеров по виртуальным сетям с различным уровнем доступа, мониторинг аномального поведения
Эти материалы также дополняются достаточно подробным описанием стандартных механизмов защиты, реализуемых в ОС Linux (такие как namespaces, SELinux и пр.).
В качестве итога статьи приводится сводная таблица, охватывающая все описанные угрозы и меры по их устранению с указанием источников на дополнительные материалы.
Ссылка на статью: https://ieeexplore.ieee.org/document/8693491
В библиотеке IEEE Xplore есть интересная статья про контейнеры и безопасность. Она называется Container Security: Issues, Challenges, and the Road Ahead (апрель 2019).
Цель этой статьи со слов авторов – помочь разобраться в требованиях к ИБ в части контейнеров и дать более четкое представление о возможных уязвимостях и атаках.
Авторы проанализировали различную литературу, сформировали 4 глобальных типа требований по безопасности (они называют это use cases) с разбивкой по способу реализации (software/hardware) и для каждой составили модель угроз с описанием угрозы, атаки, примера исполнения и варианта устранения.
Пример 1:
🍡Use case I: защита контейнеров от запускаемых в них приложений
🍡Угроза: Уязвимости в образах
🍡Атака: Remote Code Execution
🍡Сценарий: Эксплуатация уязвимости CVE-2014-6271 (ShellShock)
🍡Решение: периодические сканирование образов на уязвимости
Пример 2:
🍡Use case 2: защита взаимодействий между контейнерами
🍡Угроза: бесконтрольный сетевой доступ между контейнерами
🍡Атака: сканирование портов, поиск уязвимостей
🍡Сценарий: использование скомпрометированного контейнера для поиска и сканирования контейнеров, размещенных в других сетях с иным уровнем доступа
🍡Решение: разделение контейнеров по виртуальным сетям с различным уровнем доступа, мониторинг аномального поведения
Эти материалы также дополняются достаточно подробным описанием стандартных механизмов защиты, реализуемых в ОС Linux (такие как namespaces, SELinux и пр.).
В качестве итога статьи приводится сводная таблица, охватывающая все описанные угрозы и меры по их устранению с указанием источников на дополнительные материалы.
Ссылка на статью: https://ieeexplore.ieee.org/document/8693491
Всем привет!
Свежие новости с передовой от команды Team Nautilus (Aqua Security).
Группировка TeamTNT запустила новую кампанию против сред, в основе которых лежит Docker и Kubernetes.
Они выложили пачку вредоносных образов на Docker Hub, предназначенных для атак на некорректно сконфигурированный docker daemon, KubeFlow дашборды и Weave Scope с целью хищения учётных записей облачных провайдеров, криптомайнинга, использования backdoor-в и запуска червя для поиска следующей жертвы. По словам автора это первая столь масштабная кампания, направленная на массовое и систематическое сканирование Интернета для поиска "проблемных" сред контейнеризации и оркестрации для проведения дальнейших атак.
В статье также указано название репозитория Docker Hub и приведён поименный перечень вредоносных образов с кратким описанием того, что делает каждый из них.
Почитать можно здесь: https://blog.aquasec.com/teamtnt-campaign-against-docker-kubernetes-environment
Свежие новости с передовой от команды Team Nautilus (Aqua Security).
Группировка TeamTNT запустила новую кампанию против сред, в основе которых лежит Docker и Kubernetes.
Они выложили пачку вредоносных образов на Docker Hub, предназначенных для атак на некорректно сконфигурированный docker daemon, KubeFlow дашборды и Weave Scope с целью хищения учётных записей облачных провайдеров, криптомайнинга, использования backdoor-в и запуска червя для поиска следующей жертвы. По словам автора это первая столь масштабная кампания, направленная на массовое и систематическое сканирование Интернета для поиска "проблемных" сред контейнеризации и оркестрации для проведения дальнейших атак.
В статье также указано название репозитория Docker Hub и приведён поименный перечень вредоносных образов с кратким описанием того, что делает каждый из них.
Почитать можно здесь: https://blog.aquasec.com/teamtnt-campaign-against-docker-kubernetes-environment
Aquasec
Threat Alert: TeamTNT Pwn Campaign Against Docker and K8s Environments
TeamTNT campaign exploits container images targeting Docker and K8s environments to steal cloud credentials, open backdoors, and mine cryptocurrency.
Всем привет!
Если вы часто ошибаетесь при написании YAML файлов или «никак не можете найти ту самую ошибку» в существующем, то вам может пригодиться вот этот сайт: https://containership.github.io/konstellate-editor/?utm_sq=g0ojaltgko
Работает просто – создание YAML файлов практически через drag’n’drop!
Выбираете тип того, что хотите создать, например:
🍭 Pod!
🍭 Добавляете metadata и, например, labels
🍭 Указываете необходимые значения параметров, поступаете аналогично со spec!
🍭 Готово, осталось только сохранить и пользоваться!
Помимо этого можно использовать существующие файлы для того, чтобы понять, как они структурированы (сайт графически группирует логически связанные объекты) или найти «ту самую ошибку» (она будет обведена красным)
Если вы часто ошибаетесь при написании YAML файлов или «никак не можете найти ту самую ошибку» в существующем, то вам может пригодиться вот этот сайт: https://containership.github.io/konstellate-editor/?utm_sq=g0ojaltgko
Работает просто – создание YAML файлов практически через drag’n’drop!
Выбираете тип того, что хотите создать, например:
🍭 Pod!
🍭 Добавляете metadata и, например, labels
🍭 Указываете необходимые значения параметров, поступаете аналогично со spec!
🍭 Готово, осталось только сохранить и пользоваться!
Помимо этого можно использовать существующие файлы для того, чтобы понять, как они структурированы (сайт графически группирует логически связанные объекты) или найти «ту самую ошибку» (она будет обведена красным)
Привет!
Что общего у инструментации (instrumentation) и защиты контейнеров? На первый взгляд – ничего, но это только на первый ☺️
Про инструментацию очень мало статей на русском языке, а этот подход зачастую используется в интерактивных сканерах (Interactive Application Security Testing) и не только. Но интернет помнит! Есть статья 2013 года, в которой описаны такие вещи как:
🍭 Инструментация исходного кода
🍭 Инструментация байт-кода
🍭 Инструментация бинарного кода
🍭 Статическая бинарная инструментация
🍭 Динамическая бинарная инструментация
Скорее всего не все ссылки или указанные в статье инструменты доступны/поддерживаются. Но сам принцип, описанный в статье, остается!
Так при чем тут контейнеры? Все просто! Те, кто дочитают статью до конца увидят, что ее автор – D1g1 – основатель и бессменный лидер одного из лучших каналов по безопасности контейнеров - k8s (in)security 😊 Очень рекомендуем! Сами читаем и многое для себя узнаем!
👉 Ссылка на канал Дмитрия: https://t.me/k8security
👉 Ссылка на статью Дмитрия: https://xakep.ru/2013/09/11/61232/
Что общего у инструментации (instrumentation) и защиты контейнеров? На первый взгляд – ничего, но это только на первый ☺️
Про инструментацию очень мало статей на русском языке, а этот подход зачастую используется в интерактивных сканерах (Interactive Application Security Testing) и не только. Но интернет помнит! Есть статья 2013 года, в которой описаны такие вещи как:
🍭 Инструментация исходного кода
🍭 Инструментация байт-кода
🍭 Инструментация бинарного кода
🍭 Статическая бинарная инструментация
🍭 Динамическая бинарная инструментация
Скорее всего не все ссылки или указанные в статье инструменты доступны/поддерживаются. Но сам принцип, описанный в статье, остается!
Так при чем тут контейнеры? Все просто! Те, кто дочитают статью до конца увидят, что ее автор – D1g1 – основатель и бессменный лидер одного из лучших каналов по безопасности контейнеров - k8s (in)security 😊 Очень рекомендуем! Сами читаем и многое для себя узнаем!
👉 Ссылка на канал Дмитрия: https://t.me/k8security
👉 Ссылка на статью Дмитрия: https://xakep.ru/2013/09/11/61232/
Telegram
k8s (in)security
Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ценим и любим reliability и security, а также observability.
Ведет команда www.luntry.ru
Вопросы, идеи, предложения => @Qu3b3c
Ведет команда www.luntry.ru
Вопросы, идеи, предложения => @Qu3b3c
Неделя короткая, зато более-менее спокойная, есть время на подумать. Сегодня предлагаю поговорить за резервные копии конфигурации Kubernetes.
Как пишут в нашей базе знаний, если есть почти работающий кластер (c) с которого нужно срочно мигрировать и полчаса времен, можно воспользоваться тулой https://github.com/WoozyMasta/kube-dump.
Можно запускать:
📍разово на локальной машине как скрипт, но должны быть установлены jq и yq (скорее всего они у вас есть);
📍разово в виде контейнера на локальной машине;
📍разово и как cron job в Kubernetes.
Можно сделать дамп как всего кластера, так и отдельных ресурсов в отдельных неймспейсах. Круто, что автоматически можно залить в Git, но будьте внимательны с секретами.
Как пишут в нашей базе знаний, если есть почти работающий кластер (c) с которого нужно срочно мигрировать и полчаса времен, можно воспользоваться тулой https://github.com/WoozyMasta/kube-dump.
Можно запускать:
📍разово на локальной машине как скрипт, но должны быть установлены jq и yq (скорее всего они у вас есть);
📍разово в виде контейнера на локальной машине;
📍разово и как cron job в Kubernetes.
Можно сделать дамп как всего кластера, так и отдельных ресурсов в отдельных неймспейсах. Круто, что автоматически можно залить в Git, но будьте внимательны с секретами.
GitHub
GitHub - WoozyMasta/kube-dump: Backup a Kubernetes cluster as a yaml manifest
Backup a Kubernetes cluster as a yaml manifest. Contribute to WoozyMasta/kube-dump development by creating an account on GitHub.
Привет!
Сегодняшний пост будет коротким, потому что не поделиться таким - просто грех!
Наткнулись на интерактивную карту ядра Linux.
Все что вы хотели узнать про работу ядра в операционной системе, но боялись спросить - все отражено на карте, все кликабельно и наглядно!
На схеме представлены модули и компоненты:
🍩 Основные подсистемы ОС
🍩 Зависимости процессов, модулей и устройств
🍩 Послойная структура от hardware до системных процессов
Схема может очень пригодиться для как для более глубокого понимания устройства операционной системы, так и для структурирования уже имеющегося понимания.
Ну а про наглядность нечего говорить, куда лучше увидеть самому.
Карта доступна по ссылке на GitHub. На мобильных браузерах может не работать, лучше заходить с десктопа:
https://makelinux.github.io/kernel/map/
Сегодняшний пост будет коротким, потому что не поделиться таким - просто грех!
Наткнулись на интерактивную карту ядра Linux.
Все что вы хотели узнать про работу ядра в операционной системе, но боялись спросить - все отражено на карте, все кликабельно и наглядно!
На схеме представлены модули и компоненты:
🍩 Основные подсистемы ОС
🍩 Зависимости процессов, модулей и устройств
🍩 Послойная структура от hardware до системных процессов
Схема может очень пригодиться для как для более глубокого понимания устройства операционной системы, так и для структурирования уже имеющегося понимания.
Ну а про наглядность нечего говорить, куда лучше увидеть самому.
Карта доступна по ссылке на GitHub. На мобильных браузерах может не работать, лучше заходить с десктопа:
https://makelinux.github.io/kernel/map/
Привет!
Многим нравится осуществлять конфигурацию кластером Kubernetes с использованием терминала, но, есть те, кто верит, что «лучше 1 раз увидеть, чем сто раз услышать!».
Именно для тех, кто ищет удобный web ui для Kubernetes, рекомендуем обратить внимание на проект Headlamp. Согласно статье, он:
🍭 100% open source
🍭 Активно поддерживается
🍭 Может быть расширен при помощи плагинов
🍭 Позволяет делать read/write – операции, а не read-only
Более подробно с решением можно познакомиться, почитав документацию 😊
Многим нравится осуществлять конфигурацию кластером Kubernetes с использованием терминала, но, есть те, кто верит, что «лучше 1 раз увидеть, чем сто раз услышать!».
Именно для тех, кто ищет удобный web ui для Kubernetes, рекомендуем обратить внимание на проект Headlamp. Согласно статье, он:
🍭 100% open source
🍭 Активно поддерживается
🍭 Может быть расширен при помощи плагинов
🍭 Позволяет делать read/write – операции, а не read-only
Более подробно с решением можно познакомиться, почитав документацию 😊
GitHub
GitHub - headlamp-k8s/headlamp: A Kubernetes web UI that is fully-featured, user-friendly and extensible
A Kubernetes web UI that is fully-featured, user-friendly and extensible - headlamp-k8s/headlamp
Всем привет!
Нашли простую и лаконичную статью от Isaac Z. Schlueter (одного из авторов npm), в которой приводятся рекомендации о том, как минимизировать ущерб или не допустить реализацию supply chain attack (о них мы недавно писали) на примере использования npm.
Если кратко, то:
🍭 Использование scope для внутренних пакетов (предопределенное имя, начинающееся с @)
🍭 Использование. npmrc файла в корне проекта с указанием
🍭 Корректно настраивать proxy
🍭 Анализировать причины нарушения сборок (звучит очевидно, но происходит не всегда)
Нашли простую и лаконичную статью от Isaac Z. Schlueter (одного из авторов npm), в которой приводятся рекомендации о том, как минимизировать ущерб или не допустить реализацию supply chain attack (о них мы недавно писали) на примере использования npm.
Если кратко, то:
🍭 Использование scope для внутренних пакетов (предопределенное имя, начинающееся с @)
🍭 Использование. npmrc файла в корне проекта с указанием
@mycompany:registry = https://registry.mycompany.local/
, что позволит использовать локальный реестр «по умолчанию»🍭 Корректно настраивать proxy
🍭 Анализировать причины нарушения сборок (звучит очевидно, но происходит не всегда)
The GitHub Blog
Avoiding npm substitution attacks
Supply chain attacks are a reality in modern software development, but you can reduce attack surface by taking precautions and managing dependencies.
Большинство из нас регулярно пользуется продуктами HashiCorp вроде Terraform, Vault и Consul, а вот про Nomad многие только слышали. Это оркестратор, в том числе для контейнеров, концептуально отличный от Kubernetes. Краткий экскурс в терминах k8s:
https://www.hashicorp.com/blog/a-kubernetes-user-s-guide-to-hashicorp-nomad
https://www.hashicorp.com/blog/a-kubernetes-user-s-guide-to-hashicorp-nomad
HashiCorp
A Kubernetes User's Guide to HashiCorp Nomad
Learn the equivalent terminologies, comparisons, and differentiations between HashiCorp Nomad and Kubernetes.
Всем привет!
Сегодня за инструменты. kube-psp-advisor - утилита от Sysdig, которая помогает упростить разработку Pod Security Policies (политики для реализации контекстов ИБ в Kubernetes). Она может работать как с реальной конфигураций Kubernetes, так и с конкретными YAML файлами, содержащими спецификацию подов (например, с Deployment, DaemonSet и пр)
Утилита имеет 2 команды:
Установка утилиты осуществляется одним из вариантов:
🍡Через Krew плагин
🍡Сборка (make build)
🍡Контейнер
Дополнительную информацию, такую как описание сценариев использования, пример политик и пр, можно найти по ссылке: https://github.com/sysdiglabs/kube-psp-advisor?utm_sq=gn81msojq4
Сегодня за инструменты. kube-psp-advisor - утилита от Sysdig, которая помогает упростить разработку Pod Security Policies (политики для реализации контекстов ИБ в Kubernetes). Она может работать как с реальной конфигураций Kubernetes, так и с конкретными YAML файлами, содержащими спецификацию подов (например, с Deployment, DaemonSet и пр)
Утилита имеет 2 команды:
🍡kube-psp-advisor inspect
- выполняет подключение к API серверу кластера и сканирует workload-ы в конкретном namespace или во всем кластере, затем генерирует PSP🍡kube-psp-advisor convert
- анализирует YAML, затем генерирует PSPУстановка утилиты осуществляется одним из вариантов:
🍡Через Krew плагин
🍡Сборка (make build)
🍡Контейнер
Дополнительную информацию, такую как описание сценариев использования, пример политик и пр, можно найти по ссылке: https://github.com/sysdiglabs/kube-psp-advisor?utm_sq=gn81msojq4
GitHub
GitHub - sysdiglabs/kube-psp-advisor: Help building an adaptive and fine-grained pod security policy
Help building an adaptive and fine-grained pod security policy - sysdiglabs/kube-psp-advisor
Привет!
Компания Sonatype расширила свое предложение, добавив туда Nexus Container и расширив возможности Lifecycle добавлением Infrastructure as Code Pack.
Nexus Container позволяет сканировать образы на наличие уязвимостей и compliance-несоответствий, но, что наиболее интересно на наш взгляд: «Not only do we continuously monitor your containers to identify vulnerabilities and share available fixes once in-production, we’re the only solution that can enforce Data Loss Protection and prevent zero-day malware and network attacks, tunneling, and breaches». Container DLP engine – звучит интересно, что из себя представляет на практике пока не очень понятно (как только протестируем – расскажем!)
Infrastructure as Code помогает выбирать наиболее безопасные open-source компоненты для использования в вашей инфраструктуре
Немного подробней можно почитать тут:
🍭 Nexus Container: https://www.sonatype.com/nexus/container?topnav=true
🍭 Infrastructure as Code: https://www.sonatype.com/nexus/infrastructure-as-code?topnav=true
Компания Sonatype расширила свое предложение, добавив туда Nexus Container и расширив возможности Lifecycle добавлением Infrastructure as Code Pack.
Nexus Container позволяет сканировать образы на наличие уязвимостей и compliance-несоответствий, но, что наиболее интересно на наш взгляд: «Not only do we continuously monitor your containers to identify vulnerabilities and share available fixes once in-production, we’re the only solution that can enforce Data Loss Protection and prevent zero-day malware and network attacks, tunneling, and breaches». Container DLP engine – звучит интересно, что из себя представляет на практике пока не очень понятно (как только протестируем – расскажем!)
Infrastructure as Code помогает выбирать наиболее безопасные open-source компоненты для использования в вашей инфраструктуре
Немного подробней можно почитать тут:
🍭 Nexus Container: https://www.sonatype.com/nexus/container?topnav=true
🍭 Infrastructure as Code: https://www.sonatype.com/nexus/infrastructure-as-code?topnav=true
Sonatype
Nexus Container | Sonatype
Find and fix container vulnerabilities and compliance issues from build to ship to run.
Всем привет!
Бывают случаи, когда необходимо создать контейнер из другого контейнера (runner в CI, сбор дополнительных метрик). Как это можно сделать?
Есть несколько основных «стратегий»:
🍭 Docker in Docker, DinD – официальный образ, который позволяет запускать контейнер внутри контейнера we need to go deeper. Нюанс – ему требуется –privileged
🍭 Docker out of Docker, DooD – реализуется через
🍭 Альтернативные runtime – реализуется при помощи «подмены» runtime, например, на sysbox-runc
Более подробно про это можно почитать в статье. В целом практика, хоть и существует, не является безопасной и рекомендуемой.
А вы используете такие подходы? Если да, то зачем и почему без этого нельзя обойтись?
Бывают случаи, когда необходимо создать контейнер из другого контейнера (runner в CI, сбор дополнительных метрик). Как это можно сделать?
Есть несколько основных «стратегий»:
🍭 Docker in Docker, DinD – официальный образ, который позволяет запускать контейнер внутри контейнера we need to go deeper. Нюанс – ему требуется –privileged
🍭 Docker out of Docker, DooD – реализуется через
mount /var/run/docker.sock
, что позволяет использовать docker engine хоста для запуска контейнера «по соседству». Нюанс – можно получить информацию о контейнерах на хосте🍭 Альтернативные runtime – реализуется при помощи «подмены» runtime, например, на sysbox-runc
Более подробно про это можно почитать в статье. В целом практика, хоть и существует, не является безопасной и рекомендуемой.
А вы используете такие подходы? Если да, то зачем и почему без этого нельзя обойтись?
Nestybox Blog Site
Secure Docker-in-Docker with System Containers
Docker-in-Docker (DinD), Docker-out-of-Docker (DooD), Nestybox system containers.
Всем привет!
Kyverno – это инструмент для работы с политиками в Kubernetes, который может использоваться как для сканирования ресурсов кластера на соответствие лучшим практикам, так и для реализации этих практик путем блокировки или изменения API запросов. Важной особенностью является то, что управление политиками осуществляется аналогично управлению ресурсами Kubernetes. Это значит, что а) изучение нового языка (как в случае с OPA используется Rego, например) не требуется и б) управление политиками можно реализовать через стандартные утилиты, такие как kubectl.
Что можно делать с Kyverno?
🍡Проверять, изменять или генерировать любые ресурсы (например, генерировать квоты для namespaces при необходимости)
🍡Блокировать ресурсы или генерировать отчеты о нарушении политик
🍡Проверять политики и ресурсы в CI/CD сборке до применения в кластере, используя Kyverno CLI и пр.
Как работает Kyverno?
🍡Kyverno запускается в кластере как динамический admission controller,
🍡Посредством webhook получает проверяющие или изменяющие HTTP запросы с kube-apiserver
🍡Применяет соответствующие политики контроля
Установить Kyverno можно или напрямую из манифеста, или используя Helm.
Более подробная информация находится здесь: https://kyverno.io/docs/
А есть ли примеры?
Примеры есть. Один из них представлен ниже.
Запрет на использование пользователя с правами root
Kyverno – это инструмент для работы с политиками в Kubernetes, который может использоваться как для сканирования ресурсов кластера на соответствие лучшим практикам, так и для реализации этих практик путем блокировки или изменения API запросов. Важной особенностью является то, что управление политиками осуществляется аналогично управлению ресурсами Kubernetes. Это значит, что а) изучение нового языка (как в случае с OPA используется Rego, например) не требуется и б) управление политиками можно реализовать через стандартные утилиты, такие как kubectl.
Что можно делать с Kyverno?
🍡Проверять, изменять или генерировать любые ресурсы (например, генерировать квоты для namespaces при необходимости)
🍡Блокировать ресурсы или генерировать отчеты о нарушении политик
🍡Проверять политики и ресурсы в CI/CD сборке до применения в кластере, используя Kyverno CLI и пр.
Как работает Kyverno?
🍡Kyverno запускается в кластере как динамический admission controller,
🍡Посредством webhook получает проверяющие или изменяющие HTTP запросы с kube-apiserver
🍡Применяет соответствующие политики контроля
Установить Kyverno можно или напрямую из манифеста, или используя Helm.
Более подробная информация находится здесь: https://kyverno.io/docs/
А есть ли примеры?
Примеры есть. Один из них представлен ниже.
Запрет на использование пользователя с правами root
apiVersion: kyverno.io/v1Больше примеров можно найти по ссылке: https://github.com/kyverno/kyverno/blob/main/samples/README.md
kind: ClusterPolicy
metadata:
name: disallow-root-user
spec:
validationFailureAction: audit
rules:
- name: validate-runAsNonRoot
match:
resources:
kinds:
- Pod
validate:
message: "Running as root user is not allowed. Set runAsNonRoot to true"
anyPattern:
- spec:
securityContext:
runAsNonRoot: true
- spec:
securityContext:
runAsUser: ">0"
- spec:
containers:
- securityContext:
runAsNonRoot: true
- spec:
containers:
- securityContext:
runAsUser: ">0"
GitHub
GitHub - kyverno/kyverno: Cloud Native Policy Management
Cloud Native Policy Management. Contribute to kyverno/kyverno development by creating an account on GitHub.
Всем привет!
С момента большого взрыва, когда из ничего появилась наша вселенная, вместе с ней начало существовать и само время! Миллиарды лет оно движется стабильно и неумолимо, и всегда только в одном направлении. А это значит, что чтобы мы ни делали, она наступает всегда. Пятница!
И сколь неизбежно наступление пятницы, столь неумолимо.... Время забавных постов!
Сегодня спешим поделиться чудесной, прелестно-прекрасной, абсолютно бесполезной, и от того не менее изящной утилитой Kubecraft!
«Название кажется подозрительно знакомым» - скажете вы
«Все верно!» - ответим мы!
Визуализация объектов в кластере Kubernetes через стандартный Minecraft клиент!
Просто загружаете образ сервера в кластер, выполняете expose приложения наружу, подключаетесь по этому адресу и вуаля! В мир Minecraft с неба падают свиньи, коровы и куры ваших приложений в кластере! Почувствуй себя Kubernetes фермером!
Разобраться легко:
🍩 Хрюшки - pods
🍩 Коровки - replicasets
🍩 Курочки - services
🍩 Лошадки - deployments
Щас бы подам хвосты накрутить, ух! Но если это нужно, то можно и управлять workload’ами. Например, удалить deployment, забив лошадь... 😱
2021 год, будущее уже здесь!
Ссылочка на GitHub проекта ниже!
Приятных исследований 😊👇
https://github.com/stevesloka/kubecraft
С момента большого взрыва, когда из ничего появилась наша вселенная, вместе с ней начало существовать и само время! Миллиарды лет оно движется стабильно и неумолимо, и всегда только в одном направлении. А это значит, что чтобы мы ни делали, она наступает всегда. Пятница!
И сколь неизбежно наступление пятницы, столь неумолимо.... Время забавных постов!
Сегодня спешим поделиться чудесной, прелестно-прекрасной, абсолютно бесполезной, и от того не менее изящной утилитой Kubecraft!
«Название кажется подозрительно знакомым» - скажете вы
«Все верно!» - ответим мы!
Визуализация объектов в кластере Kubernetes через стандартный Minecraft клиент!
Просто загружаете образ сервера в кластер, выполняете expose приложения наружу, подключаетесь по этому адресу и вуаля! В мир Minecraft с неба падают свиньи, коровы и куры ваших приложений в кластере! Почувствуй себя Kubernetes фермером!
Разобраться легко:
🍩 Хрюшки - pods
🍩 Коровки - replicasets
🍩 Курочки - services
🍩 Лошадки - deployments
Щас бы подам хвосты накрутить, ух! Но если это нужно, то можно и управлять workload’ами. Например, удалить deployment, забив лошадь... 😱
2021 год, будущее уже здесь!
Ссылочка на GitHub проекта ниже!
Приятных исследований 😊👇
https://github.com/stevesloka/kubecraft
GitHub
GitHub - stevesloka/kubecraft: Kubernetes + Minecraft = Kubecraft
Kubernetes + Minecraft = Kubecraft. Contribute to stevesloka/kubecraft development by creating an account on GitHub.
StateofSecretSprawlReport-2021.pdf
1.8 MB
Привет!
В приложении отчет, подготовленный компанией GitGuardian. Суть отчета проста – показать сколько секретов (API keys, database connection strings, private keys, certificates, usernames and passwords) может быть в репозиториях, используемых командами разработки. Для формирования выборки использовались 2,5 миллиона public commits/per day.
Итого:
🍭 Более 5000 секретов/день
🍭 Более 2 000 000 секретов было идентифицировано в 2020 году
🍭 Наиболее часто удавалось идентифицировать Google Keys (27,6%)
🍭 Вторым «по популярности» идут секреты Development Tools (Django, RapidAPI, Okta, 15,9%)
Кроме того, в отчете приведены ссылки на известные случаи утечки секретов у известных компаний (Uber, Starbucks, Equifax, UN)
В приложении отчет, подготовленный компанией GitGuardian. Суть отчета проста – показать сколько секретов (API keys, database connection strings, private keys, certificates, usernames and passwords) может быть в репозиториях, используемых командами разработки. Для формирования выборки использовались 2,5 миллиона public commits/per day.
Итого:
🍭 Более 5000 секретов/день
🍭 Более 2 000 000 секретов было идентифицировано в 2020 году
🍭 Наиболее часто удавалось идентифицировать Google Keys (27,6%)
🍭 Вторым «по популярности» идут секреты Development Tools (Django, RapidAPI, Okta, 15,9%)
Кроме того, в отчете приведены ссылки на известные случаи утечки секретов у известных компаний (Uber, Starbucks, Equifax, UN)
Всем привет!
В Windows 10 есть одна интересная возможность, которая отключена by default – WSL2 (Windows Subsystem for Linux). Все достаточно просто – практически полноценный bash для Windows без необходимости установки полноценной *nix виртуальной машины!
Устанавливается (активируется, скачивается необходимый "дистрибутив") очень просто, об этом можно почитать тут.
Зачем это нужно? Да много зачем 😊 Один из возможных сценариев
🍭 Скачиваем Visual Studio Code (можно добавить YAML-edition функциональность)
🍭 Настраиваем интеграцию с WSL2 (об этом можно почитать тут)
🍭 Устанавливаем Docker for Windows, попутно интегируя с WSL2 (об этом можно почитать тут)
🍭 Устанавливаем Minikube и kubectl
Готово! Мы получили небольшой стенд, который можно использовать для тестирования и обучения по контейнерам без необходимости создания отдельной VM (если вы привыкли к Windows и не хотите «городить огород»). Подробнее можно почитать в этой статье.
P.S. Единственный нюанс, необходимо прописать alias в ~/.bashrc, чтобы можно было пользовать "kubectl", а не "kubectl.exe", т.к. сам по себе WSL2 этого не делает, аналогично с docker и т.д.
В Windows 10 есть одна интересная возможность, которая отключена by default – WSL2 (Windows Subsystem for Linux). Все достаточно просто – практически полноценный bash для Windows без необходимости установки полноценной *nix виртуальной машины!
Устанавливается (активируется, скачивается необходимый "дистрибутив") очень просто, об этом можно почитать тут.
Зачем это нужно? Да много зачем 😊 Один из возможных сценариев
🍭 Скачиваем Visual Studio Code (можно добавить YAML-edition функциональность)
🍭 Настраиваем интеграцию с WSL2 (об этом можно почитать тут)
🍭 Устанавливаем Docker for Windows, попутно интегируя с WSL2 (об этом можно почитать тут)
🍭 Устанавливаем Minikube и kubectl
Готово! Мы получили небольшой стенд, который можно использовать для тестирования и обучения по контейнерам без необходимости создания отдельной VM (если вы привыкли к Windows и не хотите «городить огород»). Подробнее можно почитать в этой статье.
P.S. Единственный нюанс, необходимо прописать alias в ~/.bashrc, чтобы можно было пользовать "kubectl", а не "kubectl.exe", т.к. сам по себе WSL2 этого не делает, аналогично с docker и т.д.
Docs
Установка WSL
Установите подсистему Windows для Linux с помощью команды wsl --install. Используйте терминал Bash на компьютере Windows под управлением следующих дистрибутивов Linux: Ubuntu, Debian, SUSE, Kali, Fedora, Pengwin, Alpine и пр.
Привет!
В феврале 2021 года была анонсирована новость о покупке StackRox Red Hat’ом. Теперь продукт называется Red Hat Advanced Cluster Security for Kubernetes.
Многим было интересно, как именно OpenShift будет работать вместе с StackRox. Время пришло! Ребята объявили вебинар, на котором будут рассмотрены вопросы (теория + демонстрация):
🍭 Обеспечение безопасности supply chain – сканирование образов и реестров, интеграция с CI/CD
🍭 Защита инфраструктуры – конфигурация Kubernetes, compliance, security posture management
🍭 Защита run time – управление привилегия, контроль сети, анализ и реагирование на угрозы
Вебинар пройдет 24 марта (среда) в 17:00 по Москве. Регистрация доступна по ссылке.
Preview не работает, поэтому дублируем ссылку: https://security.stackrox.com/Kube-native-Security-with-OpenShift_Registration.html?Source=Community&LSource=Community
В феврале 2021 года была анонсирована новость о покупке StackRox Red Hat’ом. Теперь продукт называется Red Hat Advanced Cluster Security for Kubernetes.
Многим было интересно, как именно OpenShift будет работать вместе с StackRox. Время пришло! Ребята объявили вебинар, на котором будут рассмотрены вопросы (теория + демонстрация):
🍭 Обеспечение безопасности supply chain – сканирование образов и реестров, интеграция с CI/CD
🍭 Защита инфраструктуры – конфигурация Kubernetes, compliance, security posture management
🍭 Защита run time – управление привилегия, контроль сети, анализ и реагирование на угрозы
Вебинар пройдет 24 марта (среда) в 17:00 по Москве. Регистрация доступна по ссылке.
Preview не работает, поэтому дублируем ссылку: https://security.stackrox.com/Kube-native-Security-with-OpenShift_Registration.html?Source=Community&LSource=Community
Всем привет!
Управление уязвимостями – одновременно простая (много инструментов, чтобы их найти) и сложная (за что браться в первую очередь, реально ли эта уязвимость exploitable и т.д.) задача. Еще одной «проблемой» становится отсутствие «единой точки управления», которая позволит если не управлять сканированиями, то хотя бы агрегировать информацию в себе.
Одними из примеров решений, решающих такую задачу являются Defect DOJO (open source), Archery (open source) и ThreadFix (entrerprise).
Есть еще один интересный представитель подобного класса решений – Vulcan Cyber!
🍭 Прочитать про него можно на сайте (в самом низу есть набор whitepaper)
🍭 Интеграций много, ознакомиться с ними можно по ссылке
🍭 Есть возможность получения free account (с некоторыми ограничениями, указанными по ссылке)
Единственный «нюанс» - решение облачное и подойдет в РФ далеко не всем, но проект достаточно интересный благодаря предлагаемому функционалу
Управление уязвимостями – одновременно простая (много инструментов, чтобы их найти) и сложная (за что браться в первую очередь, реально ли эта уязвимость exploitable и т.д.) задача. Еще одной «проблемой» становится отсутствие «единой точки управления», которая позволит если не управлять сканированиями, то хотя бы агрегировать информацию в себе.
Одними из примеров решений, решающих такую задачу являются Defect DOJO (open source), Archery (open source) и ThreadFix (entrerprise).
Есть еще один интересный представитель подобного класса решений – Vulcan Cyber!
🍭 Прочитать про него можно на сайте (в самом низу есть набор whitepaper)
🍭 Интеграций много, ознакомиться с ними можно по ссылке
🍭 Есть возможность получения free account (с некоторыми ограничениями, указанными по ссылке)
Единственный «нюанс» - решение облачное и подойдет в РФ далеко не всем, но проект достаточно интересный благодаря предлагаемому функционалу
Vulcan Cyber
Home page
Vulcan Cyber provides the one solution for all exposure risk management needs, helping teams reduce risk across the entire attack surface.
Всем привет!
Поздравляем всех с пятницей! Сегодня можно сбавить обороты, побаловать себя новыми вкусами из ближайшей кофейни и запланировать дела на следующую неделю.
А так как lulz toolz в последнее время у нас было достаточно, сегодня мы хотим поделиться полезной штукой, тест которой можно взять как тему для следующей недели!
Итак, сегодня расскажем про Denial of Service Container - Dostainer!
🍩 Маленькая утилита оформленная в контейнере, организующая стресс-тест вашего k8s кластера.
🍩 Контейнер содержит несколько скриптов, аллоцирующих всю доступную оперативную память и дисковое пространство
🍩 Контейнер так же содержит fork-бомбу, генерирующую множество процессов
С помощью этой утилиты можно провести нагрузочное тестирование вашего кластера целиком или отдельных его нод, на которые приземлится под с контейнером.
Стоит отметить, что утилита призвана искать бреши в ресурсных квотах. Таким образом, если ваш деплой приложений подвергается наложению resource quotas по умолчанию, вам выполнение этого теста не страшно.
⚠️Внимание!⚠️
Однако, если запустить контейнер без limits для ресурсов, он может отправить ноду или весь кластер в отказ!
Будьте осторожны и не планируйте стресс-тесты на PROD’е в пятницу 😉
Подробнее на GitHub разработчика 👇
https://github.com/uchi-mata/dostainer
Поздравляем всех с пятницей! Сегодня можно сбавить обороты, побаловать себя новыми вкусами из ближайшей кофейни и запланировать дела на следующую неделю.
А так как lulz toolz в последнее время у нас было достаточно, сегодня мы хотим поделиться полезной штукой, тест которой можно взять как тему для следующей недели!
Итак, сегодня расскажем про Denial of Service Container - Dostainer!
🍩 Маленькая утилита оформленная в контейнере, организующая стресс-тест вашего k8s кластера.
🍩 Контейнер содержит несколько скриптов, аллоцирующих всю доступную оперативную память и дисковое пространство
🍩 Контейнер так же содержит fork-бомбу, генерирующую множество процессов
С помощью этой утилиты можно провести нагрузочное тестирование вашего кластера целиком или отдельных его нод, на которые приземлится под с контейнером.
Стоит отметить, что утилита призвана искать бреши в ресурсных квотах. Таким образом, если ваш деплой приложений подвергается наложению resource quotas по умолчанию, вам выполнение этого теста не страшно.
⚠️Внимание!⚠️
Однако, если запустить контейнер без limits для ресурсов, он может отправить ноду или весь кластер в отказ!
Будьте осторожны и не планируйте стресс-тесты на PROD’е в пятницу 😉
Подробнее на GitHub разработчика 👇
https://github.com/uchi-mata/dostainer
GitHub
GitHub - uchi-mata/dostainer
Contribute to uchi-mata/dostainer development by creating an account on GitHub.