DevSecOps Talks

Kubernetes: networking, основные термины Привет! В интернете много статей, посвященных основам сетевого взаимодействия в Kubernetes. Некоторые были и на нашем канале. Особенностью их, зачастую, является то, что рассматриваются различные виды Service и их назначение. Отличие сегодняшнего материала в том, что затрагивается большее количество терминов: 🍭 Ingress. Контроль внешнего трафика к приложению и обратно 🍭 DNS (и CoreDNS в частности). Обнаружение и взаимодействие pods через resolve Services 🍭 Probes (Liveness, Readiness, Startup). Контроль состояния pod на различных этапах его жизненного цикла 🍭 Netfilter и IPTables. Контроль сетевого трафика с использованием Network Policy 🍭 IPVS. Возможности балансировки, предоставляемые ядром Linux 🍭 Proxy (Kubectl, Kube). Создание туннеля между рабочей станцией и kube-apiserver; управление Kubernetes Services 🍭 Envoy. «Продвинутые» возможности по контролю трафика и балансировке 🍭 Container Network Interface (CNI). Управление сетью Kubernetes В статье все описано простым и понятным языком. Материал может помочь в понимании концептов тем, кто только начинает знакомство с этой потрясающей технологией!

Monokle: работа с YAML Всем привет! Monokle – решение, которое упрощает работу с YAML и позволяет ускорить подготовку манифестов и/или найти ошибки. При помощи Monokle можно: 🍭 Просматривать существующие манифесты. Доступна интеграция с git и с кластерами k8s 🍭 Preview ресурсов, сгенерированных при помощи Helm и Kustomize 🍭 Применять изменения для обновления ресурсов в кластере k8s 🍭 «Сравнивать» конфигурацию ресурсов, в том числе с той, что есть в кластере k8s 🍭 Создавать ресурсы из предустановленных шаблонов и не только Monokle обладает интерактивным web-интерфейсом, в котором удобно осуществлять описанные выше операции. Больше подробностей можно посмотреть в небольшом overview (ссылка на ролик есть в repo) или в документации.

Curio: анализ sensitive data Всем привет! Герой сегодняшнего поста – Curio! Это статический анализатор, который помогает идентифицировать sensitive data в исходном коде. Поддерживается 122 типа данных: пароли, pin, email, номера кредитных карт, информация о сертификациях и т.д. Анализ происходит с использованием регулярных выражений. На текущий момент поддерживается Ruby, SQL, OpenAPI, GraphL и Protobuf. В планах – PHP, Java, C#, Go и Python. В Curio есть набор правил, которые используются для анализа. Например: 🍭 Указание email в логах 🍭 Наличие проверки длины пароля 🍭 Использование шифрования при использовании cookie и многие другие Больше информации можно найти в документации. В repo есть небольшой demo ролик, где показаны результаты работы утилиты.

Building Kubernetes Operator: Awesome Всем привет! Бывает так, что при работе с Kubernetes возникает мысль о написании собственного operator. Например, если чего-то не хватает или тот функционал, что есть не совсем решает задачу и хочется большего. Тема, безусловно, интересная и не самая простая. Возможно, что не будет понятно «за что браться». Предлагаем Вам awesome-подборку, которая может стать опорой в освоении Kubernetes Operators за счет структурирования данных. Она включает в себя: 🍭 Courses and Tutorials 🍭 Books (платные) 🍭 Videos 🍭 Operator Frameworks Надеемся, что этот материал хотя бы немного упростит для Вас погружение в этот интересный мир ☺️

User namespaces и безопасность k8s Всем привет! В Kubernetes v1.25 была добавлена поддержка (alpha) user namespaces. Их можно использовать, например, для уменьшения последствий при «побеге из контейнера» или более безопасно предоставлять полномочия конкретному pod. В статье приводится общая информация, которая поможет начать погружение в тематику. В ней рассматривается: 🍭 Mapping между UID на узлах кластера и в контейнерах 🍭 «Разграничение» полномочий между контейнером и узлами кластера 🍭 Перечень ограничений, которые присутствуют в v1.25 (все еще alpha feature) В завершении статьи (приложениях) приводится информация о user namespaces в Docker и “decision tree” – графическое пояснение того, когда user namespaces могут применяться, а когда могут возникнуть сложности.

Kured: «перезагрузка» Kubernetes Всем привет! Kured – DaemonSet, который позволяет управлять перезагрузкой узлов кластера. Например, когда такое действие диктуется потребностями операционной системы. Работает по следующему принципу: 🍭 Наблюдает за флагом, определяющим потребность в перезагрузке 🍭 Контролирует перезагрузку – one node at a time 🍭 Cordon, drain, reboot, uncordon Доступна поддержка различных версий k8s и большое количество параметров конфигурации. Больше информации (установка, настройка, использование и т.д.) можно найти в документации на проект.

GitOps

Learning CodeQL Всем привет! По мнению Автора статьи, CodeQL – не просто инструмент, которым надо научиться пользоваться. Это язык программирования, инструмент и экосистема, которые вместе позволяют создать нечто очень мощно в плане анализа кода. Чтобы научиться его использовать Автор собрал собственный learning path и материалы, которые в этом помогут. Они содержат: 🍭 Language tutorials 🍭 Public Workshops 🍭 Staging Workshops 🍭 CTFs 🍭 Blogs 🍭 GitHub Security Lab Slack В каждом разделе приводятся ссылки на материалы, где можно получить дополнительную информацию или попрактиковаться в лабораторных работах или playgrounds.

Service Account Token: что это и зачем? Во многих рекомендациях по ИБ можно встретить фразу о том, что надо отключать auto mount для Service Account Token. Но зачем и что это такое? Если просто, то это token, который используется при аутентификации запросов в kube-apiserver. В статье хорошо структурирован материал, посвященный этой теме: 🍭 Формат Service Account Token, какую информацию он в себе содержит 🍭 Важные поля token, как их можно использовать при проведении аналитики 🍭 Как они генерируются, кто это делает? 🍭 Как менялся «срок жизни» такого token от версии к версии k8s А в завершении статьи можно узнать, что поменялось в версии 1.24 и почему это только «плюс» для информационной безопасности. Статья небольшая и крайне наглядная, рекомендуем!

Trivy: анализ k8s на соответствие CIS и NSA Всем привет! Trivy – проект от Aqua Security, который смело можно назвать швейцарским ножом в мире контейнерной защиты. Не самый редкий гость в нашем канале, мы неоднократно рассказывали о его возможностях. Начиналось все со сканера образов контейнеров на наличие уязвимостей и постепенно «обрастало» функционалом. Сейчас Trivy умеет: 🍭 Анализировать образы контейнеров на наличией уязвимостей 🍭 Анализировать бинарные файлы на наличие уязвимостей 🍭 Генерировать SBoM 🍭 Анализировать RBAC k8s 🍭 Анализировать манифесты k8s на соответствие лучшим практикам и это еще не все В декабре 2022 года Trivy и чуть позже Trivy Operator получили еще одну «способность» - анализировать кластеры k8s на соответствие CIS и NSA. Тот самый функционал, который был в Kube-Bench (еще одном проекте Aqua Security). Подробнее о запуске и возможностях Trivy и Trivy Operator по анализу конфигураций кластеров k8s можно прочесть в статье.

Capital: приложение с уязвимым API Всем привет! В repo можно найти Capital – приложение, разработанное Checkmarx, обладающее уязвимым API (в соответствии с OWASP Top-10 для API). В приложении можно найти: 🍭 Broken Function Level Authorization 🍭 Broken Object Level Authorization 🍭 Broken User Authentication 🍭 Improper API Management 🍭 Excessive Data Exposure 🍭 Improper Assets Management 🍭 Lack of Resources and Rate Limiting 🍭 Security Misconfigurations 🍭 Injection 🍭 Mass Assignment 🍭 Security Misconfiguration 🍭 Insufficient Logging Подробнее об истории разработки, примерах атак и о приложении в целом можно прочесть в статье.

(Не) использование Sealed Secrets Всем привет! Если Вы читали про управление секретами, то скорее всего сталкивались с подходом/решением Sealed Secrets. Суть проста – не хранить секреты в git в открытом виде. Вместо этого – шифруем данные и voila! Теперь, даже если что-либо компрометируют, то все равно данные зашифрованы. У такого подхода есть свои плюсы, но есть и недостатки, которые Автор приводит в статье. Например: 🍭 Сложности/неудобства управления структурой repo при большом количестве разных окружений, каждое из которых обладает своими секретами 🍭Секреты все равно «там». Да, зашифрованы, но все равно «что-то смущает» 🍭Secret 0. Ключ от всех остальных ключей все равно остается ключом 🍭Есть опции получше! Причины, которые стоят за каждым из тезисов описаны Автором в статье. А что Вы думаете по поводу Sealed Secrets: нормальное решение или и правда – есть опции получше?

HashiCorp Hermes: управление документацией Всем привет! И без того не маленький портфель решений HashiCorp дополнил еще один инструмент – Hermes! Его назначение в том, чтобы управлять документацией: искать, изучать, согласовывать, «архивировать» и т.д. Пока что поддерживается только работа с Google Workspace. Решение позволяет: 🍭 Просматривать недавние и/или недавно обновленные документы 🍭 Искать документы, получать информацию о статусе (WIP, In Review, Approved, Archived) 🍭 Фильтровать документы (Тип, Статус, Продукт/Область, Владелец) 🍭 Формировать запрос(ы) на согласование (Request Review) и не только Небольшой обзор решения можно посмотреть в youtube-ролике, прикрепленному к статье. И, что самое классное – решение open source! Ознакомиться с GitHub Repo проекта можно по ссылке.

Kubernetes Load Testing Всем привет! В статье собран набор open source инструментов, которые могут пригодиться для нагрузочного тестирования кластеров k8s. Есть удобная сортировка – от basic да advanced. Примеры рассматриваемых в статье решений: 🍭 k6s. Позволяет писать тестовые скрипты на JS, что может сократить порог входа 🍭 kube-burner. Stress-testing. Отличается от многих аналогов тем, что не ставится в кластер, а стоит «сбоку» 🍭 hey. Небольшая утилита, которая может генерировать запросы к web-приложению 🍭 kube-monkey. «Реализация» Chaos Monkey (Netflix) Для Kubernetes 🍭 JMeter. Java-проект, обладающий не только CLI, но и web-интерфейсом. Позволяет, в том числе, «записывать» действия пользователей для последующего создания тестов Описание инструментов, не попавших в preview, ссылки на их GitHub, больше информации и примеров можно найти непосредственно в статье.

Метрики k8s Всем привет! В статье собран набор из 18 метрик, которые можно собирать с кластера и его узлов для troubleshooting и оптимизации производительности. Метрики сгруппированы по разным уровням абстракции: Node, Namespace, Deployment, Pod, Control Plane. Примеры: 🍭 Node. Memory/Disk Pressure, NotReady 🍭 Namespace. Number of expected pods 🍭 Deployment. Pod creation/deletion rate 🍭 Pod. OOMKilled pods, Too many restarts, Pod running on right node 🍭 Control Plane. Latency in pod creation, Kubelet state Для каждой метрики Автор дает описание почему это нужно и какие выводы относительно метрики можно сделать.

Платформа "Штурвал": вебинар и live demo Всем привет! Уже совсем скоро, 2 февраля, «Лаборатория Числитель» - разработчик, проведет вебинар, посвященный новой Платформе для контейнерной оркестрации «Штурвал» На вебинаре расскажут: 🔹о целевой архитектуре решения и ее ключевых компонентах, которые учитывают высокие требования к вычислительной инфраструктуре и информационной безопасности 🔹о функционале «из коробки» и преимуществах использования для инженера эксплуатации и ИБ 🔹об уровнях сервисной поддержки и политике лицензирования Также в программе будет показано live-demo решения. Мероприятие будет интересно руководителям по цифровизации, ИТ-инфраструктуре и эксплуатации крупных компаний, а также DevOps-специалистам, администраторам, ИБ-специалистам. Подробности и регистрация здесь 👈

Пример моделирования угроз с использованием Systemic Approach Всем привет! В статье Автор рассматривает пример создания модели угроз с использованием Systemic Approach. В качестве примера выбрано абстрактное микросервисное приложение, которое взаимодействует с облачными сервисами. Подход оперирует следующими терминами: 🍭 Boundary. Определение той части/компонентов системы, для которых будет реализовано моделирование. В примере Автор «привязывает» их к user story – отправка уведомлений – и рассматривает угрозы, применительно лишь к этому сценарию 🍭 Abstraction levels. Постепенное «погружение» в систему. Сперва – общий взгляд и все большая детализация при дальнейшем анализе. Применяется к выбранному boundary 🍭 Perspectives. Рассмотрение системы с точки зрения защищающегося или атакующего. В примере Автор берет STRIDE и расписывает возможные сценарии Получается нечто вроде моделирования угроз «по спирали» - от общих абстракций до вполне себе конкретных мер. Рекомендуем прочесть статью, если Вам интересно ознакомиться с концептом Systemic Approach подробнее. Важно – там будет описание идеологии и подхода, но никак не детальный how to. Ведь как видно из примера выше – сделать такое универсальным вряд ли получится.

Как происходит удаление pod? Всем привет! Есть много разных статей в стиле «what happens when…». Например, что происходит при использовании команды kubectl apply -f smth.yaml. Сегодняшняя статья рассказывает про то, что происходит при kubectl delete pod. Например, как k8s понимает, что надо ограничить трафик к «умирающему» pod? Как реализовать graceful shutdown и т.д. Процесс выглядит следующим образом: 🍭 Обновление записи в etcd: добавление deletionTimestamp, deletionGracePeriodSeconds. Pod получает статус terminating 🍭Удаление endpoint pod из соответствующих services 🍭kubelet останавливает pod, api-server удаляет запись о pod’е из etcd В статье все расписано более детально, уточнены нюансы: например, зачем нужен grace period. В завершении статьи представлены эксперименты с различными параметрами процесса удаления pod’a.