Что такое контейнеры и Docker в частности?

Всем привет!

Это виртуальные машины. Это емкость, в которую кладут еду на работу. Это сокращенное название портовых работников. Это набор Linux Namespaces. Это… Есть много версий ответов на этот вопрос.

Если вам хочется детально разобраться расставить точки над «i», то предлагаем ознакомиться со статьей. Примерное время чтения – 35 минут.

Статья структурирована по разделам
🍭 Введение в контейнеризацию и Docker – предпосылки реализации, решаемая проблематика
🍭 Постепенное погружение – от общей архитектуры Docker до взаимодействия dockerd с containerd, runc и ядром Linux
🍭 Детальный разбор основных терминов (Image, Dockerfile, Docker manifest)
🍭 Контейнеры! Linux Namespaces, Control Groups, Linux Kernel и не только

Крайне рекомендуем к прочтению! Автор проделал просто колоссальную работу по структурированию и описанию информации, за что ему огромнейшее спасибо! 😊

P.S. В статье очень много ссылок на полезные материалы и средства автоматизации, которые помогут еще лучше разобраться в происходящем

Автостопом по HashiCorp Vault

Всем привет!

Если вы начинаете свое знакомство с HashiCorp Vault и количество сущностей, терминов, возможностей, настроек и т.д. кажется вам ошеломляющим, и вы не знаете «с чего начать», то рекомендуем обратить внимание на статью.

В ней Автор описывает:
🍭 Общая информация о том, что есть «секрет» и какие системы управления бывают
🍭 Базовые концепты Vault (API, Storage, (Un)seal, Secret Engine и т.д.)
🍭 Способы доставки Token (Response Wrapping, AppRole)
🍭 Управление политиками доступа к секретам
🍭 Интеграции с приложениями (SDK, Agent) и многое другое

В статье много практических примеров и объяснений. Также в ней можно найти советы о том, «как лучше приготовить Vault» от практиков, которые занимаются его внедрением и эксплуатацией.

Привет!

Мы проводим небольшое исследование и нам нужна ваша помощь. Далее будет 3 маленьких опроса, на которые просим вас ответить.

Все анонимно :) Интересует статистика. Спасибо! ☺️

Шифрование и подпись образов контейнеров

Всем привет!

В статье рассматриваются возможные способы контроля целостности и конфиденциальности «содержимого» образов контейнеров с использованием двух механизмов – шифрования и использования электронной подписи.

Авто рассматривает следующие примеры
🍭 Подпись образов с использованием Cosign
🍭 Размещение подписанного образа в Registry с использованием Podman
🍭 Создание политики контроля подписи для Podman с последующим тестированием
🍭 Шифрование образа контейнера с использованием возможностей Podman

В статье приводятся примеры всех необходимых команд и комментарии к ним.

Для того, чтобы контролировать подпись образов в кластерах Kubernetes можно использовать, например, Kyverno. Подробнее об этом можно прочесть в документации.

А если вам хочется больше узнать про шифрование образов контейнеров, то рекомендуем ознакомиться с этим видео.

Mini-hardening-guides от Hadess

Всем привет!

Материал с немного обманчивым названием – «DevSecOps Checklist». Однако, внутри можно найти ~86 страниц, на которых описаны способы hardening для разнообразный технологий.

В выборку попали: Apache, ArgoCD, Auth0, AWS, Ceph, Consul, CouchDB, Docker, eBPF, ElasticSearch, etcd, git, GitLab, GlusterFS, Gradle, IIS, Jenkins, Kubernetes, Memcached, MongoDB, MySQL, Nginx, OpenShift, Redis, SaltStack, Terraform, Tomcat, Weblogic

Каждой отдельно взятой технологии уделено «не очень много временим», ввиду их общего количества.

Однако, материал все равно может пригодиться для составления собственных стандартов безопасной конфигурации

OpenCRE: mapping ИБ-стандартов

Всем привет!

По ссылке доступен проект OpenRCE. Его задача в том, чтобы сделать mapping практик между различными ИБ-стандартами.

Если вы изучали некоторые, то, вероятно, замечали: на первый взгляд они кажутся разными, но пересечений бывает очень много.

Возможно, вы делаете свой собственный набор, собирая информацию из различных стандартов и обогащая ее собственным видением. Рано или поздно захочется сделать mapping на источники. Как раз тут вам может помочь проект OpenCRE.

На текущий момент в нем есть:
🍭 OWASP (Top 10, ASVS, SAMM и т.д.)
🍭 CWE
🍭 CAPEC
🍭 NIST 800 53
🍭 NIST SSDF

Пользоваться им просто – переходите в раздел «Map Analysis», выбираете 2 интересующих вас стандарта – готово!

Из недостатков – результаты сравнения нельзя выгрузить и использовать в дальнейшей работе. Более подробно про проект и его возможности можно узнать в видео.

История Kubernetes

Всем привет!

Пятница – самое время для интересного и приятного чтения чего-то не очень сложного, а даже наоборот, расслабляющего!

Думаем, что статья Brian Grant подойдет! В ней он описывает долгий и интересный путь создания того, что мы знаем, как Kubernetes.

Материал разделен на этапы:
🍭 Lessons from Borg and Omega: 2009–2013
🍭 Early Container Product API Design: 2H2013
🍭 Ramp to Launch: 1H2014
🍭 Finishing the Implementation of the Design: 2H2014
🍭 The Home Stretch: 1H2015

Началось все с того, что нужно было оптимизировать производительность за счет параллельной обработки запросов…

Потрясающий Путь, в котором можно найти предпосылки появления некоторых функций, наброски архитектуры, причины инженерных решений и ответы на некоторые вопросы архитектуры Kubernetes.

А еще можно поиграть в игру – «угадай как эта %сущность% теперь называется в Kubernetes» 😊

Подпись артефактов: необходимое и/или достаточное условие?

Всем привет!

В статье приведены интересные мысли Автора по вопросу: «Является ли подпись артефактов достаточным механизмом контроля целостности и мерой противодействия supply chain атакам?»

С его точки зрения – нет. Да, она подтверждает авторство, но на ряд вопросов она ответить не сможет.

Например:
🍭 Как был собран артефакт?
🍭 Какой исходный код использовался?
🍭 Какие параметры сборки передавались и т.д.?

По этой причине Автор считает, что лучше (вместе с подписью) формировать provenance – набор metadata о процессе сборке. Например: информация об используемом исходном коде, процессе сборке, реализованных ИБ-проверках и вообще все, что вам кажется важным. Данные подписываются электронной подписью, формируя аттестацию.

В завершении Автор рассказывает про slsa-github-generator – набор GitHub Actions, которые позволяют создавать те самые provenance в соответствии с рекомендациями SLSA.

А что вы думаете по этому поводу? Нужны ли эти metadata или это «перебор» и привычной подписи вполне хватает?

Mindmap на все случаи жизни!

Всем привет!

Многие, для структурирования информации, любят использовать mind map. Выглядит наглядно, красиво и всегда можно «подсмотреть» что и как.

Если вы разделяете этот взгляд, то вот этот ресурс может быть вам интересен. В нем собрано очень-очень-очень большое количество различных mind map.

Безопасную разработку и DevSecOps тоже не обошли стороной:
🍭 DevOps Roadmap
🍭 DevOps Tools
🍭 MITRE ATT&CK Container Matrix
🍭 Vulnerability Scanners и другие

Из приятного – все красиво оформлено и может пригодиться для изучения новых областей или повышения существующий компетенций.

Однако, картинки не являются интерактивными и перейти по ссылке на интересующую «ветку» карты не получится.

Идентификация Broken Access Control с использованием Semgrep

Всем привет!

Если упростить, то Broken Access Control можно описать примерно так: уязвимость, которая появляется за счет отсутствия/недостаточности проверок на стороне сервера того, что некоторый субъект (subject) может реализовывать определенные действия (operation) над некоторым объектом (object).

Такие уязвимости достаточно часто встречаются и найти их не так просто, в том числе и потому, что сканеры не всегда могут понять нужный «контекст».

В статье Автор предлагает свой подход к идентификации указанных недостатков. В качестве tech stack он использует NestJS и Semgrep, как SAST-инструмент.

«Вымышленное» приложение представляет из себя набор микросервисов, обладает ролевой моделью, а авторизация реализуется с использованием JWT Token. Для контроля действий пользователей предлагается использовать NestJS Guards.

Автор предлагает следующий набор правил Semgrep, чтобы убедиться, что все реализовано "как надо":
🍭 Поиск endpoints у которых отсутствуют Guards
🍭 Использование «нестандартных» Guards
🍭 Идентификация случаев некорректного использования Guards
🍭 Поиск IDOR, где стандартных Guards может быть недостаточно и не только

Каждое правило содержит его YAML-код, описание с комментариями и ссылку на Semgrep-playground.

Статья затрагивает интересный момент: не стоит «слепо» полагаться на SAST-решение. Что оно само все найдет и само предложит, как можно устранить дефект. Альтернативным сценарием использования SAST может быть поиск определенных конструкций. Но только надо знать, что искать 😊

Linx Cloud предлагает потестировать Штурвал и Deckhouse в своем облаке.

Всем привет!

Если у вас стоит вопрос выбора коммерческой версии кубер-платформы, но нет ресурсов на то, чтобы их развернуть, - это можно сделать в облаке Linx Cloud https://linx.ru/cloud/kubernetes-clusters. Сейчас в нем развернуты два решения от российских производителей: Штурвал от компании “Лаборатория Числитель” и Deckhouse от компании “Флант”.

Trail of Bits Testing Handbook, Web!

Всем привет!

Trail of Bits продолжает радовать отличными материалами и развивать свой проект – «Testing Handbook».

К Static Analysis и Fuzzing (о которых мы писали тут и тут) добавилась новая «глава» Web Application Security, посвященная Burp Suite Professional.

Внутри можно найти:
🍭 Step-by-step guide по первому запуску
🍭 «Ручная» работа с HTTP-запросами
🍭 Работа с Burp Repeater, Intruder, Collaborator
🍭 Общие советы по работе с Burp и не только

Материал будет полезен как и тем, кто только начинает знакомство с Burp, так и тем, кто с ним работает. Если хочется чего-то еще – можно обратить внимание на Web Security Academy.

P.S. Кстати, примерно так может выглядеть внутренняя база знаний по безопасной разработке, о которой так часто упоминают на различных конференциях

Чем плохи Long Lived Service Account Tokens в K8S?

Всем привет!

Многие риски ИБ Kubernetes связаны с некорректными конфигурациями ресурсов, включая настройки прав доступа и повышенные привилегии у некоторых ролей (включая роли системных сервисов).

В статье команда GitGuardian рассматривает близкую проблематику, связанную с проблемами использования Long Lived Service Accounts Tokens

В статье рассматривается:
🍭 Что из себя представляют Service Account Tokens
🍭 Зачем они нужны, как используются
🍭 Риски ИБ, связанные с использованием Long Lived Service Account Tokens и другие вопросы

Помимо этого, в статье разбираются причины того, что в некоторых версиях Kubernetes все устроено именно так (хотя практика ограничения времени жизни подобных сущностей является правильной и рекомендуемой).

Завершают статью рекомендации о том, как можно управлять Long Lived Service Account Tokens более безопасно – от использования Service Mesh до TokenRequest API и контроля монтирования Tokens в Pod.

Istio AuthN/Z политики и Otterize!

Всем привет!

Service Mesh – достаточно популярный ответ, когда появляется вопрос про контроль сетевого трафика в Kubernetes.

А одной из самых часто вспоминаемых реализаций Service Mesh является Istio. Нюанс в том, что порог входа в работу с ней может быть высок. Чтобы сделать его чуть проще предлагаем вам ознакомиться со статьей.

Авторы рассматривают основные концепты:
🍭 Authorization Policies и их «компоненты»
🍭 Логика «вычисления» политик, если их несколько
🍭 Использование внешних ресурсов для аутентификации и не только

В завершении Авторы рассматривают как их собственные наработки могут оптимизировать управление сетевым трафиком в Kubernetes. Про Otterize Network Mapper и Intents Operator мы писали тут и тут.

Для этого они рассматривают небольшое приложение, состоящее из нескольких сервисов и сценарии, которые позволяют упростить создание Istio Authorization Policy за счет автоматизации.

Spectra Assure Community: анализ open source!

Всем привет!

Тема безопасности open source не перестает быть актуальной и даже наоборот – все больше и больше набирает обороты. Вспомнить хотя бы то, что было недавно - xz, Polyfill. И это не говоря о том, что «следы» Log4Shell нет-нет, да найдутся.

Поэтому важно получать как можно больше информации о том, насколько тот или иной пакет «здоров». Есть множество ресурсов, которые помогают получить информацию: БДУ ФСТЭК,  NVD, OpenSSF Scorecard, OSV, SCALIBR, Vet, CVEMap, Trusty и много-много-много чего еще.

Сегодня хотим рассказать про еще один такой ресурс – Spectra Assure Community. При помощи него можно проверять более 5 миллионов пакетов из NPM, PyPi и RubyGems.

Он позволяет получить информацию о: вредоносном ПО, code tampering, известным уязвимостям, проблемах с лицензиями, сведения о секретах и общий статус «здоровья» пакета.

Почитать детальнее про то, как создавался ресурс можно по ссылке, а ознакомиться с ним можно вот тут.

Cloud Threat Landscape!

Всем привет!

Команда Wiz подготовила отличный сюрприз для всех, кто любит Cloud Native технологии и их безопасность! Интерактивный Threat Landscape!

Внутри можно найти:
🍭 Incidents. Информация по реальным инцидентам в мире Cloud Native
🍭 Actors. Информация о hack-группировках и инцидентах, совершенных ими
🍭 Techniques. Набор атакующих техник, характерных для Cloud Native
🍭 Tools. Перечень наиболее часто используемых средств автоматизации злоумышленниками
🍭 Targeted Technologies. Наиболее частые «цели», на которые совершают атаки
🍭 Defenses. Набор мер по противодействию Cloud Native Attack

Каждый из разделов интерактивен и содержит дополнительную информацию. Видно, что Wiz подошли к делу со стилем и любовью 😊

P.S. А еще там есть офигенная периодическая таблица Cloud Security – можно скачать и хоть на стену вешай. Красиво и содержательно!

Global DevSecOps Report от GitLab (2024)

Всем привет!

Команда GitLab выпустила очень интересный объемный отчёт аж на 78 листов!

Хорошие новости! Согласно результатам опроса более 5 000 специалистов интерес к ИБ растет. Среди основных приоритетов выделяются: Security, AI, DevSecOps Platform, Automation, Cloud Computing.

И, конечно, много аналитики-графиков и всего такого по темам:
🍭 Приоритеты инвестиций в IT
🍭 Использование AI в жизненном цикле разработке ПО
🍭 Количество инструментов, которые используются при разработке ПО
🍭 Среднее время onboarding новых специалистов и много другой интересной информации

Особенно интересно то, что статистика ответов «разбита» отдельно для разных стран: Австралия, Канада, Франция, Франция, Индия, Япония и т.д.

Как оптимизировать образ контейнера?

Всем привет!

По ссылке доступна статья, в которой Автор описывает путь, который он проделал, решая задачу по оптимизации образа контейнера.

Под оптимизацией в статье, в большей степени, понимается сокращение размера итогового образа. Это может быть полезно, как для ИТ, так и для ИБ (например, для сокращения поверхности атаки, «противодействия» LotL-атакам и т.д.)

В итоге Автор прошел путь:
🍭 Обычная сборка образа, использование Alpine в качестве базового
🍭 Multi-stage сборка. Удаление всего, что не требуется для корректной работы ПО, помещенного в контейнер
🍭 Идентификация транзитивных зависимостей, которые надо поместить в образ
🍭 Использование Docker Slim и неожиданный результат
🍭 Использование Docker Squash и не тот результат, который должен был получиться

Статья достаточно базовая и может подойти тем, кто только «втягивается». Но в ней весьма неплохо разбираются основные концепты работы с образами, что помогает лучше разобраться, как это все устроено.

Помимо самих шагов Автор описывает сложности, с которыми можно столкнуться, впервые реализуя подобное и способы их решения.