Использование Alpine в качестве base image
Всем привет!
Ivan Velichko поделился своими размышлениями об использовании Alpine в качестве базового образа.
Началось с того, что он задал вопрос в Twitter о том, используют ли компании Alpine. Большинство ответили, что «Да!». Следующий вопрос был более общий – что важнее при выборе «основы»: быстрая сборка, общее количество CVE, иное. Варианты «Сборка» и «Количество CVE» были практически идентичны! И, напоследок, Ivan подготовил еще один вопрос: «Я использую Alpine, потому что…». И вот тут вариант ответа «5 Mb!» выбился в лидеры со значительным отрывом.
На основе такого опроса можно попробовать сделать несколько выводов:
🍭 Размеры образа важны, т.к. это ускоряет процесс, сокращает количество CVE (спорно, но скорее всего в более минималистичных образах количество CVE меньше)
🍭 Alpine – не единственный, хоть и очень удобный, выбор в качестве base image. Есть и альтернативы – тот же distroless (про который мы писали тут) или использование DockerSlim (которые еще генерирует AppArmor и Seccomp профили по резлуьтатам работы)
Подробности – в статье от Ivan, крайне рекомендуем к прочтению, как и весть его блог. Множество ценной и полезной информации, подаваемой в простом и удобном для восприятия формате.
Всем привет!
Ivan Velichko поделился своими размышлениями об использовании Alpine в качестве базового образа.
Началось с того, что он задал вопрос в Twitter о том, используют ли компании Alpine. Большинство ответили, что «Да!». Следующий вопрос был более общий – что важнее при выборе «основы»: быстрая сборка, общее количество CVE, иное. Варианты «Сборка» и «Количество CVE» были практически идентичны! И, напоследок, Ivan подготовил еще один вопрос: «Я использую Alpine, потому что…». И вот тут вариант ответа «5 Mb!» выбился в лидеры со значительным отрывом.
На основе такого опроса можно попробовать сделать несколько выводов:
🍭 Размеры образа важны, т.к. это ускоряет процесс, сокращает количество CVE (спорно, но скорее всего в более минималистичных образах количество CVE меньше)
🍭 Alpine – не единственный, хоть и очень удобный, выбор в качестве base image. Есть и альтернативы – тот же distroless (про который мы писали тут) или использование DockerSlim (которые еще генерирует AppArmor и Seccomp профили по резлуьтатам работы)
Подробности – в статье от Ivan, крайне рекомендуем к прочтению, как и весть его блог. Множество ценной и полезной информации, подаваемой в простом и удобном для восприятия формате.
Iximiuz
In Pursuit of Better Container Images: Alpine, Distroless, Apko, Chisel, DockerSlim, oh my!
How to make container images better? What does a better container image really mean? Image size vs the number of vulnerabilites. Pros and cons of using Alpine as a base image. Alpine and distroless alternatives.
👍4
Обзор Kubernetes Services, LoadBalancers и Ingress
Привет!
Еще одна обзорная статья, посвященная базовым аспектам устройствам сети в Kubernetes, но при этом покрывающая очень важные аспекты.
Как организовать сетевое взаимодействие между pod внутри кластера? А как с «внешним миром»? Почему IP-адреса вроде, как и есть, а вроде как их нет? Ответы на эти вопросы и не только можно найти в статье.
Авторы рассматривают такие сущности как:
🍭 Services (ClusterIP, NodePort, LoadBalancer)
🍭 Ingress
Отдельно в статье упоминаются FAQ. Например: можно ли создать несколько Services с одинаковым именем? Можно ли «пинговать» Services? Можно ли взаимодействовать с pods из другого namespace? Что такое Headless Service и т.д.
Есть примеры, ссылки на материалы по теме. А в конце статьи приведена общая табличка с типами сетевых сущностей и разницей между ними, включая уровни модели ISO/OSI, на которых они работают.
Привет!
Еще одна обзорная статья, посвященная базовым аспектам устройствам сети в Kubernetes, но при этом покрывающая очень важные аспекты.
Как организовать сетевое взаимодействие между pod внутри кластера? А как с «внешним миром»? Почему IP-адреса вроде, как и есть, а вроде как их нет? Ответы на эти вопросы и не только можно найти в статье.
Авторы рассматривают такие сущности как:
🍭 Services (ClusterIP, NodePort, LoadBalancer)
🍭 Ingress
Отдельно в статье упоминаются FAQ. Например: можно ли создать несколько Services с одинаковым именем? Можно ли «пинговать» Services? Можно ли взаимодействовать с pods из другого namespace? Что такое Headless Service и т.д.
Есть примеры, ссылки на материалы по теме. А в конце статьи приведена общая табличка с типами сетевых сущностей и разницей между ними, включая уровни модели ISO/OSI, на которых они работают.
home.robusta.dev
The Ultimate Guide to Kubernetes Services, LoadBalancers, and Ingress | Robusta
In this article, we will show how to expose applications running in Kubernetes Pods to other applications inside the cluster and the external world
👍4👎1
Импорт результатов Trivy в PolicyReporter
Всем привет!
Frank Jogeleit подготовил интересный проект. Он взял результаты работы Trivy (Vulnerability Assessment, RBAC Analysis и не только) и «переложил» их в структуру v1alpha2.PolicyReportResult и v1alpha2.ClusterPolicyReportResult.
Указанные структуры представляют из себя CRD, прорабатываются Kubernetes Policy Working Group и набирают все большую популярность.
Именно в таком формате, например, предоставляет результаты и другой инструмент – Kyverno! А для визуализации подобных отчетов есть отдельное решение – PolicyReporter. Суть простая: данные из polr (PolicyReports) и cpolr (ClusterPolicyReports) отображаются в виде графиков, что упрощает дальнейший анализ.
Если объединить первое со вторым, то получится «единое» окно, в котором содержится графическое представление результатов работы сразу нескольких инструментов: Kyverno, KubeBench, Trivy. При желании можно дописать свой mapper или доработать существующие. Например, если вы не согласны с той логикой, что определил Автор.
Дополнительно настраивать ничего не надо. Данные по отчетам Trivy появятся в блоках PolicyReports и ClusterPolicyReports за счет того, что PolicyReporter «подписан» на соответствующие изменения.
Всем привет!
Frank Jogeleit подготовил интересный проект. Он взял результаты работы Trivy (Vulnerability Assessment, RBAC Analysis и не только) и «переложил» их в структуру v1alpha2.PolicyReportResult и v1alpha2.ClusterPolicyReportResult.
Указанные структуры представляют из себя CRD, прорабатываются Kubernetes Policy Working Group и набирают все большую популярность.
Именно в таком формате, например, предоставляет результаты и другой инструмент – Kyverno! А для визуализации подобных отчетов есть отдельное решение – PolicyReporter. Суть простая: данные из polr (PolicyReports) и cpolr (ClusterPolicyReports) отображаются в виде графиков, что упрощает дальнейший анализ.
Если объединить первое со вторым, то получится «единое» окно, в котором содержится графическое представление результатов работы сразу нескольких инструментов: Kyverno, KubeBench, Trivy. При желании можно дописать свой mapper или доработать существующие. Например, если вы не согласны с той логикой, что определил Автор.
Дополнительно настраивать ничего не надо. Данные по отчетам Trivy появятся в блоках PolicyReports и ClusterPolicyReports за счет того, что PolicyReporter «подписан» на соответствующие изменения.
GitHub
GitHub - fjogeleit/trivy-operator-polr-adapter: Creates PolicyReports based on the different Trivy Operator CRDs like VulnerabilityReports
Creates PolicyReports based on the different Trivy Operator CRDs like VulnerabilityReports - fjogeleit/trivy-operator-polr-adapter
👍3
Устройство сети Kubernetes
Всем привет!
По ссылкам можно ознакомиться с циклом статей, посвященному устройству сети Kubernetes. Цикл разбит на три части, в каждой из которых уровень «погружения» увеличивается.
🍭 Первая статья рассказывает про namespaces (pid, mnt, utc, ipc, user, net). Что это такое, зачем оно нужно и какое отношение имеет к контейнерной сети.
🍭 Вторая раскрывает тему Pause Container. Если вы не знаете, что это такое и в чем суть его существования – очень рекомендуем прочесть, ответ достаточно интересный. Простой контейнер с одним бинарным файлом.
🍭 Третья уже вплотную подбирается к Kubernetes. Описывается как взаимодействуют компоненты между собой (на одной node, на разных node), что такое cbr0, примеры маршрутизации трафика.
Статьи отлично подойдут в качестве основы, если вам интересно разобраться в концептах устройства сети Kubernetes.
Всем привет!
По ссылкам можно ознакомиться с циклом статей, посвященному устройству сети Kubernetes. Цикл разбит на три части, в каждой из которых уровень «погружения» увеличивается.
🍭 Первая статья рассказывает про namespaces (pid, mnt, utc, ipc, user, net). Что это такое, зачем оно нужно и какое отношение имеет к контейнерной сети.
🍭 Вторая раскрывает тему Pause Container. Если вы не знаете, что это такое и в чем суть его существования – очень рекомендуем прочесть, ответ достаточно интересный. Простой контейнер с одним бинарным файлом.
🍭 Третья уже вплотную подбирается к Kubernetes. Описывается как взаимодействуют компоненты между собой (на одной node, на разных node), что такое cbr0, примеры маршрутизации трафика.
Статьи отлично подойдут в качестве основы, если вам интересно разобраться в концептах устройства сети Kubernetes.
Medium
Demystifying Kubernetes Networking — Episode 1
In the episode 1 of demystifying Kubernetes networking, lets start from the foundation— The Linux network namespace
👍6👏1
CyberCamp 2022!!!
Всем привет!
Материал не совсем по тематике канала (хотя, spoiler:в программе есть отличный доклад Сергея Канибора из Luntry! ), но не поделиться им мы не можем!!!
Встречайте, CyberCamp 2022 !!!
Присоединяйтесь 14-16 сентября к онлайн-конференции! Практики по кибербезопасности расскажут, как обнаруживать, расследовать и отражать кибератаки.
Что будет?
🔹20 докладов и мастер-классов от пентестеров, специалистов по мониторингу и расследованию инцидентов из Group-IB, «Лаборатории Касперского», «Инфосистемы Джет», Positive Technologies, Luntry, Синклит и Yandex Cloud
🔹Задания для отработки практических навыков в формате игрового обучения
Забронируйте три дня на полезный контент:
🔹Поиск низко висящих фруктов в ИТ-инфраструктуре
🔹Раскладываем атаки по MITRE
🔹Эффективный харденинг ИТ-инфраструктуры
🔹Типовые сценарии Windows Persistence и их обнаружение
🔹Инструменты пентестеров для BlueTeam
🔹Автоматизация работы с инцидентами
🔹Форензика и криминалистические артефакты
🔹Безопасность АСУ ТП: угрозы, подходы, практики
🔹Обогащение в SIEM: как забирать данные из AD, GeoIP, TI
Регистрация на сайте CyberCamp 2022!
Всем привет!
Материал не совсем по тематике канала (хотя, spoiler:
Встречайте, CyberCamp 2022 !!!
Присоединяйтесь 14-16 сентября к онлайн-конференции! Практики по кибербезопасности расскажут, как обнаруживать, расследовать и отражать кибератаки.
Что будет?
🔹20 докладов и мастер-классов от пентестеров, специалистов по мониторингу и расследованию инцидентов из Group-IB, «Лаборатории Касперского», «Инфосистемы Джет», Positive Technologies, Luntry, Синклит и Yandex Cloud
🔹Задания для отработки практических навыков в формате игрового обучения
Забронируйте три дня на полезный контент:
🔹Поиск низко висящих фруктов в ИТ-инфраструктуре
🔹Раскладываем атаки по MITRE
🔹Эффективный харденинг ИТ-инфраструктуры
🔹Типовые сценарии Windows Persistence и их обнаружение
🔹Инструменты пентестеров для BlueTeam
🔹Автоматизация работы с инцидентами
🔹Форензика и криминалистические артефакты
🔹Безопасность АСУ ТП: угрозы, подходы, практики
🔹Обогащение в SIEM: как забирать данные из AD, GeoIP, TI
Регистрация на сайте CyberCamp 2022!
cybercamp.su
CyberCamp — это проект для обмена практическим опытом по теме кибербезопасности. Мы создали новый формат киберучений, где задания тесно связаны с лекциями.
👏8👍3🔥2
Kubernetes OWASP Top-10: примеры
Привет!
Проект Kubernetes OWASP Top 10 продолжает развиваться. Ранее пустые разделы постепенно наполняются описанием и примерами! Появляются статьи, которые разбирают описанные в нем риски.
Одна из таких статей разбирает первый и самый «популярный» - Insecure Workload Configurations. Автор описывает Security Context и что они могут/для чего они нужны.
Он разбирает не все, лишь самые интересные на его взгляд:
🍭 Privileged
🍭 Действия с Capabilities
🍭 runAsUser/Group
🍭 runAsNonRoot
🍭 readOnlyFileSystem
Приведены примеры, что это и зачем, почему это (не) стоит применять. А если Вы не успели ознакомиться с полной версией Kubernetes OWASP Top 10, то он доступен по ссылке.
Привет!
Проект Kubernetes OWASP Top 10 продолжает развиваться. Ранее пустые разделы постепенно наполняются описанием и примерами! Появляются статьи, которые разбирают описанные в нем риски.
Одна из таких статей разбирает первый и самый «популярный» - Insecure Workload Configurations. Автор описывает Security Context и что они могут/для чего они нужны.
Он разбирает не все, лишь самые интересные на его взгляд:
🍭 Privileged
🍭 Действия с Capabilities
🍭 runAsUser/Group
🍭 runAsNonRoot
🍭 readOnlyFileSystem
Приведены примеры, что это и зачем, почему это (не) стоит применять. А если Вы не успели ознакомиться с полной версией Kubernetes OWASP Top 10, то он доступен по ссылке.
Medium
Kubernetes OWASP Top 10: Insecure Workload Configurations
Following on from the overview on the Top 10, this is the first in the series delving into some of the details on the risks posed and ways…
👍5
Контроль доступа к REST-endpoints в k8s
Всем привет!
Допустим, что есть приложение с опубликованным REST-endpoint в Kubernetes. Как предотвратить несанкционированный доступ к такому Endpoint?
У приложения могут быть собственные механизмы аутентификации. А что, если их нет? Или они по какой-то причине недоступны?
В статье Автор разбирает возможные сценарии решения задачи:
🍭 Ingress, поддерживающий аутентификацию. Один из наиболее частых способов, реализуемый, например, с Nginx Ingress Controller
🍭 Reverse-proxy. Использование sidecar-контейнера, например, с Nginx
🍭 Использование RBAC k8s. Да, можно и так!
Как раз последнему способу и посвящена основная часть статьи. Автор описывает подход, реализует его на простом примере и описывает плюсы и минусы подхода.
Всем привет!
Допустим, что есть приложение с опубликованным REST-endpoint в Kubernetes. Как предотвратить несанкционированный доступ к такому Endpoint?
У приложения могут быть собственные механизмы аутентификации. А что, если их нет? Или они по какой-то причине недоступны?
В статье Автор разбирает возможные сценарии решения задачи:
🍭 Ingress, поддерживающий аутентификацию. Один из наиболее частых способов, реализуемый, например, с Nginx Ingress Controller
🍭 Reverse-proxy. Использование sidecar-контейнера, например, с Nginx
🍭 Использование RBAC k8s. Да, можно и так!
Как раз последнему способу и посвящена основная часть статьи. Автор описывает подход, реализует его на простом примере и описывает плюсы и минусы подхода.
Medium
Protecting an Application’s REST Service With Kubernetes RBAC
Suppose you have deployed an application in a Kubernetes cluster, exposing some REST endpoints. The next question often is:
👍2
Security Small Talk
Всем привет!
Вышел новый выпуск Security Small Talk об управлении секретами.
В нём детально объясняется следующее:
• Что такое секреты и в чем отличие «human-to-machine» и «machine-to-machine» секретов
• Управление секретами на всех этапах жизненного цикла
• Как можно защищать секреты, какие практики и средства автоматизации можно использовать
Всем привет!
Вышел новый выпуск Security Small Talk об управлении секретами.
В нём детально объясняется следующее:
• Что такое секреты и в чем отличие «human-to-machine» и «machine-to-machine» секретов
• Управление секретами на всех этапах жизненного цикла
• Как можно защищать секреты, какие практики и средства автоматизации можно использовать
YouTube
#SecuritySmallTalk Об управлении секретами
Зачем смотреть?
🔹 Узнать, что такое секреты и какими они бывают. В чем отличие «human-to-machine» от «machine-to-machine» секретов
🔹 Понять общую проблематику информационной безопасности, связанную с управлением секретами на всех этапах жизненного цикла
🔹…
🔹 Узнать, что такое секреты и какими они бывают. В чем отличие «human-to-machine» от «machine-to-machine» секретов
🔹 Понять общую проблематику информационной безопасности, связанную с управлением секретами на всех этапах жизненного цикла
🔹…
👍14🔥1
Trivy, Cosign и Kyverno: анализ даты последнего сканирования образа контейнера
Всем привет!
Если соединить Trivy, Cosign и Kyverno, то можно реализовать достаточно интересный сценарий. Его демонстрация с примерами всех настроек приведена в статье. Да, там используется GitHub Actions, но сам подход можно реализовать на любой удобной Вам платформе.
Происходит следующее:
🍭 Образ сканируется при помощи Trivy, в результате получаем отчет по уязвимостям
🍭 Результат сканирования проходит аттестацию при помощи Cosign. Про аттестацию (in-toto attestation) можно прочитать тут и тут. «Спецификация» аттестации, генерируемая Cosign описана тут.
🍭 Создается политика Kyverno, которая может «читать» аттестацию и анализировать ее поля. Например, можно проверить, что со времени последнего сканирования прошло не более X дней.
Таким образом можно контролировать, когда образ последний раз был просканирован на уязвимости и, например, заблокировать его запуск или создать событие аудита в соответствии с принятыми требованиями.
Это только небольшой пример возможностей Kyverno по взаимодействию с Cosign, рекомендуем ознакомиться с документацией, чтобы узнать больше!
Всем привет!
Если соединить Trivy, Cosign и Kyverno, то можно реализовать достаточно интересный сценарий. Его демонстрация с примерами всех настроек приведена в статье. Да, там используется GitHub Actions, но сам подход можно реализовать на любой удобной Вам платформе.
Происходит следующее:
🍭 Образ сканируется при помощи Trivy, в результате получаем отчет по уязвимостям
🍭 Результат сканирования проходит аттестацию при помощи Cosign. Про аттестацию (in-toto attestation) можно прочитать тут и тут. «Спецификация» аттестации, генерируемая Cosign описана тут.
🍭 Создается политика Kyverno, которая может «читать» аттестацию и анализировать ее поля. Например, можно проверить, что со времени последнего сканирования прошло не более X дней.
Таким образом можно контролировать, когда образ последний раз был просканирован на уязвимости и, например, заблокировать его запуск или создать событие аудита в соответствии с принятыми требованиями.
Это только небольшой пример возможностей Kyverno по взаимодействию с Cosign, рекомендуем ознакомиться с документацией, чтобы узнать больше!
neonmirrors.net
Attesting Image Scans With Kyverno
Using Sigstore Cosign, Trivy, GitHub Actions, and Kyverno to attest and verify continual vulnerability scans in container images run under Kubernetes.
👍3
Elixir Secure Coding Training
Всем привет!
В repo представлен набор Secure Coding Training, включающий в себя такие разделы как:
🍭 OWASP
🍭 Secure SDLC
🍭 GraphQL, Elixir Security
🍭 Cookie Security
🍭 Security Anti-patterns
🍭 CI/CD Tooling
С описанием того, что внутри можно ознакомиться в соответствующих файлах. А если хочется большей красоты и интерактивности – можно установить Livebook и использовать его в качестве «интерпретатора».
Всем привет!
В repo представлен набор Secure Coding Training, включающий в себя такие разделы как:
🍭 OWASP
🍭 Secure SDLC
🍭 GraphQL, Elixir Security
🍭 Cookie Security
🍭 Security Anti-patterns
🍭 CI/CD Tooling
С описанием того, что внутри можно ознакомиться в соответствующих файлах. А если хочется большей красоты и интерактивности – можно установить Livebook и использовать его в качестве «интерпретатора».
GitHub
GitHub - podium/elixir-secure-coding: An interactive cybersecurity curriculum designed for enterprise use at software companies…
An interactive cybersecurity curriculum designed for enterprise use at software companies using Elixir - podium/elixir-secure-coding
👍4
Ephemeral Containers
Всем привет!
По ссылке доступна ознакомительная статья, которая позволит понять, что такое ephemeral containers и зачем они нужны.
Вкратце, ephemeral container – «рыба-прилипала», которая «присоединяется» к целевому контейнеру и позволяет с ним взаимодействовать. Это может быть нужно, например, для debug.
Представим, что у вас есть distroless образ и вы думаете, что есть проблемы с сетевой связностью. Но как проверить?
Такое возможно благодаря тому, что ephemeral container «разделяет» namespaces
Детали, команды и их результаты представлены в статье. А в конце – пример использования mirrord с Job или через ephemeral containers.
Всем привет!
По ссылке доступна ознакомительная статья, которая позволит понять, что такое ephemeral containers и зачем они нужны.
Вкратце, ephemeral container – «рыба-прилипала», которая «присоединяется» к целевому контейнеру и позволяет с ним взаимодействовать. Это может быть нужно, например, для debug.
Представим, что у вас есть distroless образ и вы думаете, что есть проблемы с сетевой связностью. Но как проверить?
wget, curl – их не будет в таком образе. Как раз вот тут и пригодятся ephemeral containers и это далеко не единственный случай.Такое возможно благодаря тому, что ephemeral container «разделяет» namespaces
(mnt, utc, ipc, user, net и т.д.) с «целевым». Кстати, с pid все несколько иначе.Детали, команды и их результаты представлены в статье. А в конце – пример использования mirrord с Job или через ephemeral containers.
MetalBear 🐻
Getting Started With Ephemeral Containers
Getting started with Ephemeral Containers, and a short case study on how we used them with mirrord
👍7
SSSC_Developers.PDF
1.7 MB
Securing the Software Supply Chain: Recommended Practices for Developers
Всем привет!
Недавно вышли новые рекомендации от NSA, посвященные безопасности Software Supply Chain.
В 64-х страничном документе разобраны такие темы, как:
🍭 Develop Secure Code
🍭 Verify Third-Party Components
🍭 Harden the Build Environment
🍭 Deliver Code
Документ описывает проблематику для каждого «блока» и рекомендации о том, как сделать лучше и безопаснее. Каждая рекомендация описывается достаточно подробно, но без детальных how-to (все-таки это документ, содержащий общие практики). В целом получилось достаточно интересно, на наш взгляд.
Всем привет!
Недавно вышли новые рекомендации от NSA, посвященные безопасности Software Supply Chain.
В 64-х страничном документе разобраны такие темы, как:
🍭 Develop Secure Code
🍭 Verify Third-Party Components
🍭 Harden the Build Environment
🍭 Deliver Code
Документ описывает проблематику для каждого «блока» и рекомендации о том, как сделать лучше и безопаснее. Каждая рекомендация описывается достаточно подробно, но без детальных how-to (все-таки это документ, содержащий общие практики). В целом получилось достаточно интересно, на наш взгляд.
👍2
Risk8s Business: Risk Analysis of Kubernetes Clusters
Всем привет!
По ссылке доступен внушительный guide, посвященный размышлениям на тему безопасности Kubernetes и того, как можно ее улучшить.
Guide состоит из нескольких разделов:
🍭 Introduction. Обзор Kubernetes, рассуждения на тему «что такое безопасный кластер»
🍭 Understanding Your Environment. Как получить необходимую информацию о кластере для последующей «работы» с ним по ИБ
🍭 Understanding Your Risk. Простенький анализ рисков с учетом всей информации, полученной на предыдущих этапах
🍭 Wrapping Up. Заключение, в котором делается обзор всего пути и ключевые выводы
Есть примеры, инструменты, их использование и много всего интересного. Рекомендуем открывать на PC, потому что с телефона отображение информации или навигация могут быть искажены.
Всем привет!
По ссылке доступен внушительный guide, посвященный размышлениям на тему безопасности Kubernetes и того, как можно ее улучшить.
Guide состоит из нескольких разделов:
🍭 Introduction. Обзор Kubernetes, рассуждения на тему «что такое безопасный кластер»
🍭 Understanding Your Environment. Как получить необходимую информацию о кластере для последующей «работы» с ним по ИБ
🍭 Understanding Your Risk. Простенький анализ рисков с учетом всей информации, полученной на предыдущих этапах
🍭 Wrapping Up. Заключение, в котором делается обзор всего пути и ключевые выводы
Есть примеры, инструменты, их использование и много всего интересного. Рекомендуем открывать на PC, потому что с телефона отображение информации или навигация могут быть искажены.
tl;dr sec
Risk8s Business
Risk Analysis of Kubernetes clusters
👍2
Kubernetes resources under the hood — Part 1
Привет!
Если Вам хочется узнать больше про устройство Kubernetes, но хочется, чтобы описание было не слишком общим и не глубоко техническим, то эта статья может Вам подойти.
Автор рассматривает такие вопросы, как:
🍭 Linux namespaces, их назначение и как (для чего) они используются контейнерами
🍭 Можно узнать, сколько pod по умолчанию Kubernetes может разместить на одной node. Да, есть и такое
🍭 Что такое Requests и Limits, как они связаны с cgroups, при чем тут «сompressible» и «incompressible», что такое throttling и от чего он возникает
🍭 Какие есть QoS у Kubernetes и от чего они зависят. И тут есть много своих нюансов. Если кому хочется узнать особенности поведения Guaranteed с использованием целого количества ядер, а не millicores, как обычно, то можно прочитать про Topology Manager
Статья читается просто, дает большее понимание, как и что работает внутри и, как обычно, много-много-много ссылок для более глубокого изучения!
Привет!
Если Вам хочется узнать больше про устройство Kubernetes, но хочется, чтобы описание было не слишком общим и не глубоко техническим, то эта статья может Вам подойти.
Автор рассматривает такие вопросы, как:
🍭 Linux namespaces, их назначение и как (для чего) они используются контейнерами
🍭 Можно узнать, сколько pod по умолчанию Kubernetes может разместить на одной node. Да, есть и такое
🍭 Что такое Requests и Limits, как они связаны с cgroups, при чем тут «сompressible» и «incompressible», что такое throttling и от чего он возникает
🍭 Какие есть QoS у Kubernetes и от чего они зависят. И тут есть много своих нюансов. Если кому хочется узнать особенности поведения Guaranteed с использованием целого количества ядер, а не millicores, как обычно, то можно прочитать про Topology Manager
Статья читается просто, дает большее понимание, как и что работает внутри и, как обычно, много-много-много ссылок для более глубокого изучения!
Medium
Kubernetes resources under the hood — Part 1
Let’s dive into the bits and bytes of how Kubernetes manages its resources.
👍6
Kubernetes resources under the hood — Part 2
Всем привет!
Вторая часть серии посвящена Requests и их роли в жизненном цикле pod, которая заключается не только в scheduling.
Прочитав ее, можно узнать:
🍭 Сколько CPU Shares запрашивает Kubernetes, основываясь на данных, указанных пользователем в Requests
🍭 Completely Fair Scheduler (CFS) Linux – распределение CPU requests между процессами, как он работает и зачем нужен
🍭 Влияние threads и QoS на предоставление ресурсов CPU
Просто, наглядно и с примерами!
Всем привет!
Вторая часть серии посвящена Requests и их роли в жизненном цикле pod, которая заключается не только в scheduling.
Прочитав ее, можно узнать:
🍭 Сколько CPU Shares запрашивает Kubernetes, основываясь на данных, указанных пользователем в Requests
🍭 Completely Fair Scheduler (CFS) Linux – распределение CPU requests между процессами, как он работает и зачем нужен
🍭 Влияние threads и QoS на предоставление ресурсов CPU
Просто, наглядно и с примерами!
Medium
Kubernetes resources under the hood — Part 2
CPU Requests may be more important than you think. Introducing CPU Shares.
👍6
Kubernetes resources under the hood — Part 3
Всем привет!
Третья часть серии начинается достаточно провокационно – Don’t set your CPU limits! Это сильно противоречит большинству рекомендаций по ИБ (и не только) по корректному написанию манифестов (наличие CPU/RAM requests и limits).
Далее начинается нечто! Автор обосновывает свою точку зрения с учетом:
🍭 Информации из предыдущих статей, особенно с использованием CPU Shares
🍭 Чуть больше раскрывается тема throttling, разница поведений контейнеров при использовании single/multi threading
🍭 Математики (да, ее много для статьи не про нее)
🍭 Рассуждений о том, что будет если 1 контейнер будет сильно потреблять ресурсы – пострадает только он или все его «соседи» по node?
🍭 Эксперимент с последовательным запуском двух pods, значения CPU requests/limits которых (не)устанавливаются в разные «положения» и что при этом происходит с учетом тех QoS, которые они получают от Kubernetes.
И все-таки? Нужны ли CPU Limits? Мнение Автора и примеры их (не)использования в реальном мире можно узнать в разделе «When to use CPU Limits» в конце статьи.
Всем привет!
Третья часть серии начинается достаточно провокационно – Don’t set your CPU limits! Это сильно противоречит большинству рекомендаций по ИБ (и не только) по корректному написанию манифестов (наличие CPU/RAM requests и limits).
Далее начинается нечто! Автор обосновывает свою точку зрения с учетом:
🍭 Информации из предыдущих статей, особенно с использованием CPU Shares
🍭 Чуть больше раскрывается тема throttling, разница поведений контейнеров при использовании single/multi threading
🍭 Математики (да, ее много для статьи не про нее)
🍭 Рассуждений о том, что будет если 1 контейнер будет сильно потреблять ресурсы – пострадает только он или все его «соседи» по node?
🍭 Эксперимент с последовательным запуском двух pods, значения CPU requests/limits которых (не)устанавливаются в разные «положения» и что при этом происходит с учетом тех QoS, которые они получают от Kubernetes.
И все-таки? Нужны ли CPU Limits? Мнение Автора и примеры их (не)использования в реальном мире можно узнать в разделе «When to use CPU Limits» в конце статьи.
Medium
Kubernetes resources under the hood — Part 3
A solid explanation of why you need to get rid of your CPU limits!
👍7
False positive/negative при сканировании образов контейнеров
Всем привет!
Одна из самых частых практик, про которую точно слышали все – сканирование образов контейнеров на наличие уязвимостей. Есть большое количество инструментов (как open source, так и enterprise), которые решают эту задачу. Они развиваются, функционал расширяется, например, создание Software Bill of Materials (SBOM) для образа контейнера. Но все ли они видят? И как обстоят дела с наличием ошибок первого и второго рода?
В статье приводятся примеры как первых, так и вторых – можно либо найти лишнее, либо не найти то, что на самом деле важно.
Почему это так?
🍭 Большинство сканеров работают с базой данных пакетных менеджеров (apt, yum, apk и т.д.) и видят только то, что установлено с их использованием
🍭 У некоторых сканеров (например, Snyk) есть «собственные проприетарные практики» обнаружения, например, Node.js, который обычно ставится «напрямую», а не через пакетный менеджер
Если хочется еще примеров – в статье можно посмотреть на Wordpress, который устанавливается через
Что делать? Авторы статьи предлагают перенести созданием SBOM на момент сборки и, по возможности, использовать distroless подход с использованием melange и apko (о которых мы писали тут).
Всем привет!
Одна из самых частых практик, про которую точно слышали все – сканирование образов контейнеров на наличие уязвимостей. Есть большое количество инструментов (как open source, так и enterprise), которые решают эту задачу. Они развиваются, функционал расширяется, например, создание Software Bill of Materials (SBOM) для образа контейнера. Но все ли они видят? И как обстоят дела с наличием ошибок первого и второго рода?
В статье приводятся примеры как первых, так и вторых – можно либо найти лишнее, либо не найти то, что на самом деле важно.
Почему это так?
🍭 Большинство сканеров работают с базой данных пакетных менеджеров (apt, yum, apk и т.д.) и видят только то, что установлено с их использованием
🍭 У некоторых сканеров (например, Snyk) есть «собственные проприетарные практики» обнаружения, например, Node.js, который обычно ставится «напрямую», а не через пакетный менеджер
Если хочется еще примеров – в статье можно посмотреть на Wordpress, который устанавливается через
curl в официальном образе, а потому «пропадает» из поля видимости сканеров.Что делать? Авторы статьи предлагают перенести созданием SBOM на момент сборки и, по возможности, использовать distroless подход с использованием melange и apko (о которых мы писали тут).
www.chainguard.dev
What your scanner doesn't know **Can** hurt you
Everything you need to know about securing the software supply chain.
👍5
Sidecar(less) mTLS от Cilium
Всем привет!
Многие ИБ-специалисты хотят, думают использовать, используют (?) mTLS для повышения безопасности сред контейнерной оркестрации.
Одним из самых популярных подходов является использование sidecar-паттерна, который реализует необходимый функционал. Однако, такой подход может быть избыточным и ребята из Cilium представили свой подход к mTLS, в котором не требуется дополнительных контейнеров.
В статье этот вопрос рассматривается более детально:
🍭 Общее описание того, что такое mTLS и зачем он нужен
🍭 Разница между session based и network based mutual authentication
🍭 Плюсы и минусы описанных выше подходов
Далее поднимается вопрос о том, можно ли совместить 2 подхода (session/network based) и как этого можно достигнуть при помощи Cilium Service Mesh. И, конечно же, тесты на производительность! Куда же без них! Если верить текущим прогнозам, то функционал mutual authentication будет доступен в Cilium v1.13 (текущая версия – 1.12).
Всем привет!
Многие ИБ-специалисты хотят, думают использовать, используют (?) mTLS для повышения безопасности сред контейнерной оркестрации.
Одним из самых популярных подходов является использование sidecar-паттерна, который реализует необходимый функционал. Однако, такой подход может быть избыточным и ребята из Cilium представили свой подход к mTLS, в котором не требуется дополнительных контейнеров.
В статье этот вопрос рассматривается более детально:
🍭 Общее описание того, что такое mTLS и зачем он нужен
🍭 Разница между session based и network based mutual authentication
🍭 Плюсы и минусы описанных выше подходов
Далее поднимается вопрос о том, можно ли совместить 2 подхода (session/network based) и как этого можно достигнуть при помощи Cilium Service Mesh. И, конечно же, тесты на производительность! Куда же без них! Если верить текущим прогнозам, то функционал mutual authentication будет доступен в Cilium v1.13 (текущая версия – 1.12).
Isovalent
Next-Generation Mutual Authentication (mTLS) with Cilium Service Mesh
Learn how Cilium & Cilium Service Mesh provides sidecar-free mTLS based authentication with excellent security and performance characteristics
👍3
Визуализация JSON
Всем привет!
JSON – один из самых часто встречаемых машиночитаемых форматов. В таком формате, например, можно получать результаты работы open source инструментов, обеспечивающих анализ программного обеспечения или защиту сред контейнерных испытаний.
Есть множества библиотек для различных языков, которые упрощают его «обход» и помогают забирать нужно или «перекладывать» данные в другую структуру.
Но сперва надо понять, как он «устроен». Это не то, чтобы сложно, но иногда хочется простой визуализации, а не просто «красивой» формы, которые могут давать
Если Вы согласны, то рекомендуем обратить внимание на проект JSONCrack, которые позволяет построить наглядную диаграмму из JSON-файла. И все это в минималистично-необходимом UI.
JSONCrack доступен как online, так и в качестве контейнеров, которые можно запустить on-premise.
Всем привет!
JSON – один из самых часто встречаемых машиночитаемых форматов. В таком формате, например, можно получать результаты работы open source инструментов, обеспечивающих анализ программного обеспечения или защиту сред контейнерных испытаний.
Есть множества библиотек для различных языков, которые упрощают его «обход» и помогают забирать нужно или «перекладывать» данные в другую структуру.
Но сперва надо понять, как он «устроен». Это не то, чтобы сложно, но иногда хочется простой визуализации, а не просто «красивой» формы, которые могут давать
jq, Notepad++, VSCode и другие системы.Если Вы согласны, то рекомендуем обратить внимание на проект JSONCrack, которые позволяет построить наглядную диаграмму из JSON-файла. И все это в минималистично-необходимом UI.
JSONCrack доступен как online, так и в качестве контейнеров, которые можно запустить on-premise.
GitHub
GitHub - AykutSarac/jsoncrack.com: ✨ Innovative and open-source visualization application that transforms various data formats…
✨ Innovative and open-source visualization application that transforms various data formats, such as JSON, YAML, XML, CSV and more, into interactive graphs. - AykutSarac/jsoncrack.com
👍2
Kubernetes CVE feed
Всем привет!
Небольшая, но интересная новость. У Kubernetes, как и у любого другого программного обеспечения есть уязвимости.
Особенность заключалась в том, что трудно было отслеживать (программно) эти уязвимости из-за отсутствия единого источника.
Команда решила это поправить и запустила «Auto-refreshing Official Kubernetes CVE Feed». Feed будет содержать актуальную информацию по уязвимостям, которую можно извлечь в формате JSON для дальнейшей работы.
Например, можно воспользоваться командой:
Всем привет!
Небольшая, но интересная новость. У Kubernetes, как и у любого другого программного обеспечения есть уязвимости.
Особенность заключалась в том, что трудно было отслеживать (программно) эти уязвимости из-за отсутствия единого источника.
Команда решила это поправить и запустила «Auto-refreshing Official Kubernetes CVE Feed». Feed будет содержать актуальную информацию по уязвимостям, которую можно извлечь в формате JSON для дальнейшей работы.
Например, можно воспользоваться командой:
curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.jsonБольше про feed и то, что сейчас находится внутри можно посмотреть по ссылке. Приятно, что для каждой CVE указывается ссылка на GitHub Issue и можно посмотреть как (не)идут дела.
kubernetes.io
Announcing the Auto-refreshing Official Kubernetes CVE Feed
Author: Pushkar Joglekar (VMware)
A long-standing request from the Kubernetes community has been to have a programmatic way for end users to keep track of Kubernetes security issues (also called "CVEs", after the database that tracks public security issues…
A long-standing request from the Kubernetes community has been to have a programmatic way for end users to keep track of Kubernetes security issues (also called "CVEs", after the database that tracks public security issues…
👍2
Использование Repository Webhook для доступа к CI
Всем привет!
Если задуматься, то Repository Webhook – VIP-персоны, ввиду тех задач, для которых они используются. Сделали commit, хочется, чтобы сборка начиналась автоматически? Webhook! А значит, что они проходят «сквозь», например, межсетевые экраны и иные ограничения ИБ.
А можно ли это как-то использовать для получения доступа к CI? Именно на этот вопрос и попытались ответить Авторы статьи. В целом, все достаточно неплохо – GET-запросы к CI не очень-то и поддерживаются, а при POST-запросах отсутствует возможность контроля тела запроса, да еще и CSRF-токен формируется. Но…
Авторы статьи сделали следующее:
🍭 Создали свой repo и «настроили» webhook на CI-жертву - Jenkins
🍭Подобрали пароли для учетной записи Jenkins с использованием POST-запроса на страницу аутентификации и анализом возвращаемого ответа. Кстати, чтобы этот и дальнейшие опыты сработали был использован GitLab, ввиду его особенности (какой именно - описано в статье)
🍭 Получили доступ к job console output
🍭 Создали reverse-shell для Jenkins instance через эксплуатацию уязвимости платформы (в статье есть отдельное видео, где можно посмотреть пример «в деле»)
Да, для реализации примеров необходимы «входные» данные, например, существующие и актуальные учетные записи, но… это все равно достаточно интересное исследование на наш взгляд, реализуемое через очень своеобразный вектор.
Всем привет!
Если задуматься, то Repository Webhook – VIP-персоны, ввиду тех задач, для которых они используются. Сделали commit, хочется, чтобы сборка начиналась автоматически? Webhook! А значит, что они проходят «сквозь», например, межсетевые экраны и иные ограничения ИБ.
А можно ли это как-то использовать для получения доступа к CI? Именно на этот вопрос и попытались ответить Авторы статьи. В целом, все достаточно неплохо – GET-запросы к CI не очень-то и поддерживаются, а при POST-запросах отсутствует возможность контроля тела запроса, да еще и CSRF-токен формируется. Но…
Авторы статьи сделали следующее:
🍭 Создали свой repo и «настроили» webhook на CI-жертву - Jenkins
🍭Подобрали пароли для учетной записи Jenkins с использованием POST-запроса на страницу аутентификации и анализом возвращаемого ответа. Кстати, чтобы этот и дальнейшие опыты сработали был использован GitLab, ввиду его особенности (какой именно - описано в статье)
🍭 Получили доступ к job console output
🍭 Создали reverse-shell для Jenkins instance через эксплуатацию уязвимости платформы (в статье есть отдельное видео, где можно посмотреть пример «в деле»)
Да, для реализации примеров необходимы «входные» данные, например, существующие и актуальные учетные записи, но… это все равно достаточно интересное исследование на наш взгляд, реализуемое через очень своеобразный вектор.
👍1