DevSecOps Talks

Хоп хэй, ла-ла-лэй! Вот и пятница настала, а вместе с ней предвкушение долгожданного и не менее заслуженного отдыха! 😎 Commit’ы пушатся - приклады крутятся! 😎 А мы рады разбавить ожидание уикенда очередным любопытным постом! Сегодня тема нашего поста *голосом Якубовича* - О-о-обсервабилити! Славная команда талантливых разработчиков из Imhotep Software LLC заботливо представила общественности свою очень простую, но в то же время не менее полезную тулзу под прямо-таки кричащим названием k9s! Утилита представляет собой альтернативное видение управления кластером Kubernetes. В сущности, это простая утилита CLI, и такой бы она и осталась, если бы не чудесный ее баланс возможностей, удобства и простоты. Понятно, что платформа Kubernetes настолько пронизана невидимыми нитями YAML и JSON, а комьюнити настолько большое, что все это в совокупности позволяет лепить какие душе угодно модули для взаимодействие с кластерным API, однако, не всегда итоговый продукт оказывается действительно стоящим внимания. В случае с k9s это внимание вполне оправдано, так как утилита позволяет работать практически со всеми ресурсами кластера при помощи удобного интерфейса с псевдографикой, не только для отображения информации о ресурсах, как например логи или состояние подов деплойметов, но и управления ими «на лету». Теперь можно уйти от постоянного набора длинных команд, а можно просто перемещаться по ресурсам и менять их конфигурацию при помощи простых диалоговых окон! Из коробки утилита умеет: 🍩 удобное отображение различных метрик (выглядит как “$ top”) 🍩 выполнение всех нативных команд kubectl 🍩 наглядное отображение сложных ресурсов вроде манифестов RBAC 🍩 отображение зависимостей ресурсов И наконец, это просто красиво! И главное, утилита, являясь под капотом почти нативным инструментом взаимодействия с Kubernetes, имеет куда более user-friendly интерфейс. Таким образом утилита может быть одинаково полезна как опытным специалистам, не боящимся консоли с kubectl, так и начинающим инженерам, делающим первые шаги в k8s! Утилита бесплатная, распространяется под любимой лицензия Apache 2.0 и доступна по ссылке на сайте и GitHub разработчика (для Windows, Linux и MacOS) 👇Приятного использования! 👇 https://github.com/derailed/k9s

Всем привет! Awesome++. На этот раз он посвящен OPA. Как и во всех Awesome в repo можно найти множество ссылок на полезные и интересные материалы по теме: 🍭 Ссылки на repo проектов (OPA, Gatekeeper, Conftest) 🍭 Документация (включая Styra Academy – курсы, где можно пройти тренинги по OPA) 🍭 Использование OPA совместно с языками программирования (Python, Go, Java и т.д.) 🍭 И, наверное, самое интересное – наборы готовых политик: - Community-owned policy library for OPA - Rego policies from the the Red Hat community of practice - Open Database of rego policies for common Infrastructure as Code files (от Aqua Security) И многое другое! Надеемся, что подборка будет для вас полезной! ☺️

Привет! Тема безопасности software supply chain не прекращает быть актуальной. Недавно GitLab «предоставил» Package Hunter для community. Инструмент разработан GitLab и ранее использовался «внутри» конторы с ноября 2020 года. Package Hunter анализирует зависимости на наличие вредоносного кода и иного нетипичного поведения через установку в изолированной среде (песочнице) с дальнейшим мониторингом активности. Интересно, что для его работы необходим Falco, правила находятся в repo проекта и их достаточно много. На текущий момент поддерживается только NodeJS и Ruby. Подробности (ссылки на документацию, информацию по использованию, код) можно найти в статье по ссылке P.S. Важно - This is beta software. Don't run on production servers.

Всем привет! В статье автор описывает подход к созданию и управлению Network Policy. Материал разбит на несколько частей: 🍭 Основы. Что такое Network Policy и зачем они нужны (мы писали об этом тут и вот тут): ingress/egress, использование matchExpression, online-редактор политик от Cilium 🍭 Governance. Использование git для управления политиками, например: 1. Разработчику предоставляется доступ к repo, где описана Network Policy 2. Разработчик делает отдельный branch, вносит изменения при необходимости 3. Создается pull request 4. ИБ-специалисты либо принимают, либо не принимают request разработчика. Если НЕ принимают, то описывают почему именно, что не понравилось 5. В случае «успешного» принятия request изменения применяются на кластер 🍭 Автоматизация. Использование OPA для частичного автоматизации процесса внесения изменений в Network Policy 🍭 Debug. Как и откуда получать информацию для отладки политик P.S. В статье много ссылок на полезные материалы по теме, включая ссылки на repo с «готовыми» Network Policies

Привет! Визуализация помогает упростить восприятие информации, особенно, если «уровней абстракции» очень много, а возможностей «тонкой настройки» - еще больше! По ссылке доступен проект – rback – который позволяет визуализировать RBAC в Kubernetes. В независимости от сложности реализованной структуры, rback проанализирует все созданные сущности и построит граф, на котором будут отображены Service Accounts/(Cluster) Roles, соответствующие bindings и возможности ☺️

Всех с пятницей! Если вы хотите поближе познакомиться с eBPF, то рекомендуем посмотреть видео от Liz Rice: «A Beginner's Guide to eBPF Programming with Go». В видео: 🍭 Приводится краткий обзор того, что такое eBPF 🍭 Как написать простое «Hello world» приложение 🍭 Множество demo, кода и примеров! Желаем отличных выходных и прекрасного отдыха!

Всем привет! Если сказать: «Подпись образов», то большинство подумает про проект «Notary». Однако, Notary не единственный способ реализации, есть альтернатива – «Cosign»! Подход очень похож – использование Cosign для подписи и OPA для последующей ее валидации перед deploy в кластер. С небольшим примером можно ознакомиться по ссылке. Принцип работы Cosign достаточно прост: 🍭 Генерация ключевой пары 🍭 Подпись образа контейнера при помощи закрытого ключа, помещение подписи в registry 🍭 Проверка наличия подписи у образа при помощи открытого ключа На текущий момент Cosign поддерживает реестры: AWS Elastic Container Registry, GCP's Artifact, Registry and Container Registry, Docker Hub, Azure Container Registry, JFrog Artifactory Container Registry, The CNCF distribution/distribution Registry, GitLab Container Registry, GitHub Container Registry, The CNCF Harbor Registry, Digital Ocean Container Registry, Sonatype Nexus Container Registry P.S. Последний release Notary был в 2018 году, возможно в скором времени будет обновление v2, с большим количеством нововведений. Очень советуем посмотреть видео по ссылке целиком

Приглашаем на цикл вебинаров DevSecOps, 2-й сезон! Уже в этот четверг стартует 2-й сезон вебинаров DevSecOps для всех интересующихся. Наша команда Jet DevSecOps Team, включающая спецов по разработке, эксплуатации и безопасности поделится «боевыми» примерами и лайфхаками, полученными в реальных проектах: от мониторинга k8s и организации конвейера GitOps до резервного копирования в Kubernetes и управления «секретами». На всех вебинарах будет live demo решений! Как всегда вас ждут минимум слайдов, максимум хардкора и полное погружение. Участие будет интересно DevOps инженерам, разработчикам, ИТ и ИБ специалистам, ИТ-менеджменту. Расписание вебинаров: 🔹 22 июля, 16:00–17:30 Мониторинг/аудит k8s. Что такое Audit Policy и как ей пользоваться? 🔹 29 июля, 16:00–17:30 Зачем GitOps в Enterprise 🔹 5 августа, 16:00–17:30 Управление «секретами»: основы 🔹 12 августа, 16:00–17:30 Persistent данные и резервное копирование в кластере Регистрируйтесь и зовите друзей)

Привет! Управление RBAC не самая простая задача, а зачастую около-избыточная (например, когда требуется создавать несколько RoleBinding, которые практически ничем не отличаются). Для того, чтобы упростить жизнь был разработан RBAC-manager. Он переопределяет подход к созданию RBAC через дополнительную сущность – RBACDefinition, которая описывает целевое (желаемое) состояние: «Instead of managing role bindings or service accounts directly, you can specify a desired state and RBAC Manager will make the necessary changes to achieve that state». RBAC-manager может быть полезен в таких случаях как: 🍭 Обновление прав: не надо удалять/создавать новый RoleBinding, необходимо только обновить RBACDefinition и утилита сделает все остальное 🍭 Удаление RoleBinding: аналогично, необходимо лишь удалить интересующую сущность из RBACDefinition 🍭 И что очень приятно - можно задавать права доступа к нескольким namespace в едином конфигурационном файле С документацией можно ознакомиться по ссылке. Также можно быстро "познакомиться" с решением и пользой от него в небольшом примере.

Привет! Что общего у статического анализа исходного кода и Elasticsearch? Например, проект BugHound! Простой SAST, анализирующий PHP и Java (в будущем планируется расширение перечня поддерживаемых языков). Принцип работы BugHound достаточно прост: 🍭 Построение дерева файлов, находящихся в проекте 🍭 Анализ файлов для идентификации небезопасных функций/методов (в большей степени реализовано через regex) 🍭 Сбор результатов с последующей передачей в Kibana для отображения на преднастроенных dashboard Полноценным SAST назвать такое решение нельзя, но проект интересен тем, как автор связал несколько технологий. Возможно, такой подход будет кому-то интересен для реализации у себя. Больше про BugHound можно почитать по ссылке.

Всех с пятницей!!! Kubernetes-external-secrets – проект, основная задача которого состоит в извлечении секрета из стороннего хранилища и передачи его сущностям кластера в качестве Secret. Состоит из двух частей: 🍭 ExternalSecret – CRD – описывает какие данные необходимо извлечь 🍭 Controller – «конвертирует» ExternalSecret в Secret K8S На текущий момент поддерживаются следующие внешние хранилища: AWS Secrets Manager, AWS System Manager, Akeyless, Hashicorp Vault, Azure Key Vault, Google Secret Manager and Alibaba Cloud KMS Secret Manager. P.S. Больше информации - архитектура, настройка, примеры использования и т.д. находится в самом repo

Всем привет! ThreatMapper – проект, который позволяет анализировать состояние ИБ кластера: 🍭 Визуализирует workloads кластера для упрощения восприятия 🍭 Идентифицирует уязвимости в образах контейнеров 🍭 Интегрируется с registry, CI/CD для сканирования образов 🍭 Анализирует запущенные контейнеры Отличие ThreatMapper, например, от Trivy в том, что у первого есть приятный интерфейс, который может быть использован для последующей аналитики и запуска сканирований. Помимо этого, присутствует интеграция с SIEM P.S. Для просмотра demo можно воспользоваться ссылкой: https://deepfence.io/community-demo-form/ (требуется электронная почта)

Всем привет! В 18-19 августа 2021 года пройдет eBPF Summit! Зарегистрироваться можно по ссылке. Программа пока что не утверждена окончательно, но можно ознакомиться с темами, на которые будут разговоры: 🍭 Introduction & Getting Started with eBPF 🍭 eBPF-based Networking, Load-Balancing, & Network Security 🍭 Securing Systems, CI/CD pipelines, Networks, ... with eBPF 🍭 eBPF Projects (bpftrace, Cilium, Falco, ...) и многое другое Множество интересных спикеров, среди которых будет и Liz Rice (эксперт по контейнеризации и автор множества интересных книг и статей по обеспечению их безопасности), которая является частью команды Isovalent (Cilium) P.S. Регистрация бесплатная ☺️

Привет! Еще один инструмент, который можно использовать для анализа RBAC – Krane! Утилита позволяет анализировать текущую RBAC-модель, идентифицировать потенциальные риски и предлагать меры по их устранению. Основные функции: 🍭 RBAC Risk Rules – риски идентифицируются на основе существующих правил, которые можно добавлять 🍭 Portability – работает локально (в качестве CLI или docker-container), в CI/CD pipeline (для анализа потенциального RBAC-изменения до его применения на prod) или в качестве непрерывного мониторинга кластера на наличие «RBAC-рисков» 🍭 Reporting – предоставляет отчетность в машиночитаемом формате 🍭 Dashboard – наглядное изображение RBAC, возможность проведения дополнительного анализа 🍭 Alerting – реализован через интеграцию с Slack 🍭 RBAC in the Graph – Krane формирует граф из RBAC, который впоследствии можно анализировать CypherQL запросами Подробную информацию, как обычно, можно прочесть в описании repo ☺️ Ранее мы уже писали о инструментах, выполняющих задачи по схожей тематике: KubiScan и kubectl-who-can

Всем привет! Иногда спрашивают – «С чего начать, если хочется погрузиться в мир контейнеризации? Какие бывают технологии?». Ответом на этот вопрос могут стать awesome-подборки, посвященные отдельным классам решений и подходам. Существуют даже awesome подборки awesome подборок (да, чтобы понять рекурсию надо понять рекурсию). «Проблема» таких awesome, как правило, заключается в том, что они перечисляют инструменты не всегда предоставляя их обзор, пусть и минималистичный. Недавно наткнулись на «альтернативный вариант». В статье автор собрал наиболее интересные, на его взгляд, инструменты и технологии по Dev(Sec)Ops, на которые стоит обратить внимание. Подборка получилась достаточно интересной: 🍭 Helm 🍭 ArgoCD 🍭 Istio 🍭 Kyverno 🍭 Velero и не только Кроме перечисления инструментария, автор дает небольшие комментарии о том, что это такое и зачем оно нужно. А если есть аналогичные решения – автор предоставляет ссылку на них ☺️

Всем привет! По ссылке доступна статья, в которой приводится 5 Admission Control Policy, которые могут оказаться полезными для повышения уровня ИБ кластера среды контейнеризации. 🍭 Trusted Repo. Контроль реестров, из которых извлекается образ. Например, необходимо использовать только внутренний реестр 🍭 Label Safety. Контроль наличия необходимых Label. Например, Label используются для группировки ресурсов, они должны быть определенного формата 🍭 Prohibit (or Specify) Privileged Mode. Контроль Privileged 🍭 Define and Control Ingress. Контроль использования Ingress 🍭 Define and Control Egress. Контроль intra и extra взаимодействий применительно к Egress трафику Помимо краткого описания политик в статье приводятся небольшие примеры, которые помогут разобраться

Привет! По ссылкам ниже доступен небольшой цикл постов про использование STRIDE применительно к Kubernetes. Автор разбирает каждую из «букв» в отдельности и дает некоторые рекомендации относительно того, как можно сделать лучше: 🍭 Spoofing. Аутентификация, использование Service Accounts 🍭 Tampering. Ограничение доступа к Nodes, шифрование ETCD 🍭 Repudiation. Использование Audit Policy, логирование Kubelet, Falco 🍭 Information Disclosure. Безопасность взаимодействия ETCD peers, использование Vault-подобных решений, шифрование 🍭 Denial of Service. Resource Quotas и Limits, Pod Autoscaler, HA конфигурация 🍭 Elevation of Privileges. Управление Linux Capabilities, использование Security Context, использование Gatekeeper/Kyverno, Network Policies Посты достаточно емкие, есть примеры и ссылки на полезные материалы, про которые рассказывается в самих постах