OpenSource - это круто, говорили они. Нас попросили для POC из грязи и прутиков собрать storage на bare-metal Kubernetes кластере. Ниже выдержка из чата, как есть, с сохранением авторской орфографии и пунктуации.
Дисклеймер: сообщения вырваны из контекста. Предлагаю определить "Индусы" = "Разработчики разного уровня квалификации", национальная принадлежность разработчиков не имеет значения.

Архитектор
Так, у меня фиговые новости - отказ storage на storage node несовместим с дальнейшей нормальной жизнью. Индусы из OpenEBS - это сборище непуганых идиотов. И они еще это пытаются продавать.

Инженер
Эмм каким образом оно отказало?

Архитектор
у вас никак. А на стенде я убил себе storage на 1 ноде
и раскрылись бездны индусского слабоумия

Инженер
Какими действиям хоть убил?

Архитектор
взял и на VM диск грохнул

Архитектор
tbe commented on 22 May 2019
I just wonder why this is not a blocker or at least mentioned in the docs: "WARNING! You can not remove a broken disk from a custom pool"

Disks break. A "Leading Open Source" software should be able to handle this.

We lost one of your disks on one node yesterday. After replacing it the according pool was still fucked up, so restartet it. And at this point the whole thing broke ... many volumes in state "Recreating", the pool itself didn't start anymore, all iscsi targets for volumes that hat a replica on that pool staled, because missing quorum ( in a two replica setup, wtf? )

Yeah, this went a little bit offtopic. Sry for that. Just wanted to illustrate what happens if you put a "not so fancy, but essential feature" at the end of the roadmap.

Архитектор
https://github.com/openebs/openebs/issues/2258
они потом привернули костылей, и я даже вернул pool к жизни, но реплики не ожили

Привет!

По ссылке можно найти материалы от Geoffrey Hill (автора проекта по автоматизации моделирования угроз Tutamantic) и его размышления на тему Rapid Threat Modelling Prototyping. Одна из ключевых идей автора строится на том, что «классическое» моделирование угроз не применимо в DevSecOps, хотя бы потому что:

🍭 Его трудно сделать быстро (или потеряется качество)
🍭 Как правило оно более детальное, чем требуется
🍭 Не подходит для CI pipeline (или потребуется сильная адаптация)

Поэтому автор предлагает свой подход, который представлен в материалах: общие презентации (обзоры, примеры step by step), небольшие how2 guides ☺️

Всем привет!

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

🍭 Namespace breakout через некорректный mount hostPath
🍭 Lateral movement в cloud на примере GKE (Google Kubernetes Environment)

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

И снова привет!

Если хочется погрузиться в мир «практической» безопасности, связанной с Docker, то мы рекомендуем обратить внимание на подборку материалов, доступных по ссылке. Автор начинает с азов – Что такое Docker (даже есть отсылки к истории контейнеров, как таковых) и «повышает градус» от урока к уроку. Все наглядно, с примерами, командами и описанием необходимого минимума, который потребуется, чтобы все это реализовать самостоятельно. Всего доступно 6 уроков:

🍭 Lesson 1: Understand Docker from a security perspective
🍭 Lesson 2: Docker Images, Docker Layers, and Registry
🍭 Lesson 3: Container reconnaissance techniques for beginners
🍭 Lesson 4: Hacking Containers Like A Boss
🍭 Lesson 5: Hacking Containers Like A Boss – Part 2
🍭 Lesson 6: Defending container Infrastructure

Надеемся, что вам понравится!

Контейнеры в России популярны, в этом нет сомнений; их применение растет – в этом тоже. Нам стало интересно, как этот тренд выглядит в цифрах, и вот.

По данным свежего исследования о применении контейнеров в России 2020, проведенного нами совместно с CNews Analytics:

56% крупных компаний сегодня используют контейнеры для своих приложений и 7% собираются. Подавляющее большинство! Но:

Всего 8% компаний размещают в контейнерах более 60% своих приложений. А 58% только начинают осваиваться с этой технологией, доля их приложений в контейнерах < 20%.

Интересно, какие технологии предпочитают отечественные компании. В основном on-premise, так сказали 57%. В тройке лидеров:

🍫Kubernetes on-premise
🍫Различные публичные облачные решения
🍫Red Hat OpenShift

Также в исследовании:

❓с какими сложностями стакиваются компании при внедрении
❓как организуют защиту сред контейнеризации
❓какие получают преимущества от внедрения контейнеров

Получить отчет можно по ссылке https://jet.su/devsecops/#research

Всем привет!

Огромный шар, летящий в пучине беззвучного вакуума сделал семь оборотов вокруг своей оси и снова наступила она, пятница!
А как мы знаем, пятница - время вкусненьких расслабленных постов! 🍩

Сегодня мы с удовольствием делимся приятной новостью из мира container security! Недавно вышла новая версия платформы контейнерной защиты Aqua Container Security Platform, которая теперь называется Aqua Enterprise версии 5.3.
Новая версия получила новый кастомизируемый веб интерфейс, концептуально похожий на старый, но элегантно переработанный с большой оглядкой на удобство и usability.
Помимо прочего, не обошлось и без новых фич. Самые броские:

🍩 Масштабирование модуля Gateway позволяет подключить несколько instance системы в разных кластерах к одному control-plane
🍩 Multi-App RBAC, благодаря которому пользователи могут видеть события аудита только в своей зоне ответственности
🍩 Раздельные БД для хранения конфигураций системы и событий аудита
🍩 Сканирование локальных docker образов в .tar архиве
🍩 Возможность автоматического добавления sidecar контейнера защиты PodEnforces для новых подов в кластере.
🍩 Расширен список поддерживаемых систем оркестрации

И многое другое!
А еще, можно смотреть бесконечно на огонь, как выдают зарплату и новый login screen Aqua Enterprise!!! 😂

Больше информации можно найти на сайте вендора

Всем хороших выходных!

Привет!

Pod Security Policy (PSP) – достаточно удобный механизм, который позволяет контролировать запуск privileged контейнеров, останавливать запуск из под root, управлять mount’ами и реализовать иные функции, полезные с точки зрения безопасности.

Однако, многие слышали новость о том, что Pod Security Policy могут быть убраны/переработаны/заменены в новых версиях Kubernetes (предположительно в версии 1.22). В статье автор описывает свой взгляд на происходящее с точки зрения предпосылок:

🍭 Неявные/неочевидные bindings
🍭 Вопросы поддержки различных runtime
🍭 Ограничение границ применения (только pods)
🍭 Сложности, связанные с test coverage при создании PSP

И некоторых рекомендаций относительно того, что можно сделать в рассматриваемой ситуации (если вы их используете):

🍭 Custom Admission Controllers
🍭 Open Policy Agent (OPA)
🍭 Использование сторонних решений

P.S. Информация про изменения Kubernetes: https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta

Привет!

Иногда хочется, чтобы все было просто и понятно, чтобы кто-то взял и «на пальцах» объяснил что-то, без сложных слов и «страшных» терминов! Если вам это знакомо, и вы хотели понять, что именно происходит в наиболее популярных web-атаках, то эта подборка видео может вас заинтересовать. Просто и понятно объясняются такие вещи как:

🍭 Open Redirect
🍭 HTTP parameter pollution
🍭 Insecure Direct Object Reference (IDOR)
🍭 XSS
🍭 CSRF и другие

Надеемся, что это видео помогут разобраться и станут первым шагом для дальнейшего изучения ☺️

И снова привет!

По ссылке доступен отчет, созданный по результатам прохождения интернатуры в AppSecco (мы уже писали о подобной работе в канале, и вот появилась еще одна!). Отчет описывает cоздание secure pipeline на основе Jenkins:

🍭 Использование SAST
🍭 Использование DAST
🍭 Использование SCA
🍭 Анализ качества исходного кода

В завершении приводится полностью описанный Jenkins pipeline: сперва в качестве блок схемы, а далее – в качестве pipeline noscript. Работы ребят в целом похожи, но есть и отличия.

Опять ловим себя на мысли, что такой формат отчетов по прохождению испытательного срока/стажерской программы – просто отличная идея! ☺️

P.S. Как и в прошлый раз preview не работает, поэтому дублируем ссылку сюда: https://intern-appsecco.netlify.app/

Всем привет! syscall2seccomp – это open source утилита, написанная на python, которая предназначена для создания собственных профилей Docker seccomp.

Работает она достаточно просто:
🍡Собирает информацию о системных вызовах, используя различные инструменты (sysdig или strace)
🍡Конвертирует полученные данные в формат JSON, используемый для создания собственных seccomp-профилей

Пример использования:
🍡Запустить sysdig (или strace)
🍡Запустить docker-контейнер
🍡Совершить необходимые действия в контейнере и погасить его
🍡Сконвертировать полученный файл с помощью python-скрипта в файл формата JSON
🍡Запустить контейнер с новым профилем

Более детальную информацию, а также ответы на дополнительные вопросы («Зачем использовать собственный seccomp-профиль?», «Зачем этот инструмент?» и пр) можно найти по ссылке.

Только ленивый не писал в последние месяцы про dockershim depratation в Kubernetes 1.20, релиз которого запланирован на 8 декабря.
Если кто вдруг пропустил или не в курсе, что такое dockershim - стоит заглянуть в свежий FAQ от комьюнити: https://kubernetes.io/blog/2020/12/02/dockershim-faq/
У нас есть несколько вопросов, ответьте, плиз.

Всем привет!

Сегодня опять за инструмент. Бесплатная утилита kubectl-who-can от Aqua Security выводит перечень RBAC разрешений для "глаголов" Kubernetes, что бывает полезным, когда надо посмотреть перечень сущностей, которые могут выполнять конкретное действие. Удобно получать информацию о том, "кто" может "что" и с "чем" в масштабах кластера, чтобы не делать много ручной работы. Кроме того утилита позволяет подсветить потенциально опасные права для сущности (например, delete psp)

Пример использования:
kubectl-who-can create pods выведет список ClusterRoleBinding, Subject, Type и Namespace с перечнем сущностей, у которых есть разрешение на выполнение создание подов.

Установка:
Установить утилиту можно с использованием krew, вручную или из собрать из source-ов. По ссылке описана как процедура установки, так и примеры использования

Привет!

Исследователи из компании Prevasio проанализировали 4 000 000 образов контейнеров, размещенных на Docker Hub на предмет наличия уязвимостей. Результат показал, что 51% из них содержит уязвимости различных уровней критичности. Распределение Malicious / Potentially Harmful Container Images получилось следующим:

🍭 44% - Coinminers
🍭 23% - Flatmap Stream, Malicious npm package(Bitcoin wallet stealer)
🍭 20% - Hacking tools
🍭 6,6% - Other
🍭 6,4% - Windows Malware

Не думаем, что результаты станут/стали откровением для ИБ-специалистов, однако, отчет запросто можно использовать в качестве reference при подготовке обоснования необходимости защиты контейнеров, чтобы наглядно показать что может «пойти не так» на достаточно большой выборке данных.

P.S. Сам отчет можно посмотреть по ссылке: https://prevasio.com/static/web/viewer.html?file=/static/Red_Kangaroo.pdf

Привет!

В статье автор наглядно демонстрирует примеры использования Amazon CodeGuru. Согласно информации с официальной страницы "Amazon CodeGuru – is a developer tool that provides intelligent recommendations to improve your code quality and identify an application’s most expensive lines of code. CodeGuru Reviewer uses machine learning to identify critical issues, security vulnerabilities, and hard-to-find bugs during application development to improve code quality". Трудно сказать, сколько тут правды, а сколько – маркетинга, но в статье рассмотрены примеры:

🍭 AWS API security best practices //на примере идентификации hardcoded credentials
🍭 Java crypto library best practices //на примере идентификации недостаточно криптостойкого алгоритма
🍭 Secure web applications //на примере идентификации некорректной обработки cookie
🍭 AWS Security best practices //на примере идентификации небезопасного хранения данных

Более полное описание инструмента и его возможностей можно найти на официальном сайте

Привет!

Иногда слышишь фразу «Ну DevSecOps это же S-SDLC, да?». И тут уже можно развести не один holy war, но мы не будем этого делать ☺️ Наткнулись на интересные статьи (один, два), в которых наглядно показаны ключевые термины, используемые при разработке:

🍭 ALM, Application Lifecycle Management
🍭 ADLM, Application Development Lifecycle Management
🍭 SDLC, Software Development Lifecycle
🍭 EAP/EAPT, Enterprise Agile Planning / Tool
🍭 DevOps, Development and Operations

В статьях представлена общая таксономия терминов, их взаимосвязь, описано что является чем, зачем используется и чем не является. Наглядно, с удобными схемами! Надеемся, что этот материал позволит структурировать картинку и ответит на вопрос «Ну DevSecOps это же S-SDLC, да?» ☺️

Всем привет! Ранее мы уже упоминали Falco в одном из своих постов. Сегодня расскажем немного подробнее.

Falco (а точнее Falco Project) – это open source инструмент, который реализует мониторинг поведенческой активности, позволяя выявлять аномальные действия в приложениях. Он выполняет контроль событий на уровне ядра операционной системы и собирает данные о контейнерах, приложениях, хосте и сетевой активности.

Что именно делает Falco?
Инструмент использует системные вызовы для реализации защиты и мониторинга системы:
🍡Разбор используемых системных вызовов Linux на уровне ядра
🍡Проверка потока данных на соответствие заданным правилам
🍡Оповещение в случае срабатывания правила

Что Falco проверяет?
Инструмент использует набор правил по умолчанию для выявления нестандартного поведения, например:
🍡Эскалация привилегий
🍡Изменение namespace с использованием утилиты setns
🍡Чтение/запись в известные директории (например, /etc, /usr/bin и пр)
🍡Выявление сетевых аномалий
🍡Запуск различных shells (sh, bash, csh и пр)
🍡Запуск ssh (ssh, scp и пр)
🍡И пр.

Что такое правила Falco?
Правила – это набор элементов, которые можно проверить на уровне системы. Они задаются в конфигурационном файле, который представляет собой YAML-файл, содержащий 3 типа элементов:
🍡Правила (Rules) – условия, в соответствии с которыми генерируется событие ИБ
🍡Макросы (Macros) – шаблоны условий правил, которые могут повторно использоваться в правилах или других макросах
🍡Lists (Списки) – наборы данных, которые могут быть включены в правила, макросы или другие списки

Пример правила:

- rule: program_accesses_file
  desc: track whenever a set of programs opens a file
  condition: proc.name in (cat, ls) and evt.type=open
  output: a tracked program opened a file (user=%user.name command=%proc.cmdline file=%fd.name)
  priority: INFO

Куда отправляются события ИБ от Falco?
Инструмент генерирует набор событий ИБ, которые могут быть направлены в разные источники, такие как:
🍡STDOUT
🍡Файл
🍡Syslog
🍡Сторонняя программа
🍡HTTP/S end point
🍡Клиент, работающий через gRPC API

Информация задается на уровне конфигурационного YAML-файла.

Пример вывода события (stdout):

10:20:05.408091526: Warning Sensitive file opened for reading by non-trusted program (user=root command=cat /etc/shadow file=/etc/shadow)

Дополнительную информацию можно найти в документации и здесь.