DevSecOps Talks

Способы балансировки north-south трафика в Kubernetes, или зачем в кубере может быть нужен BGP?.. ;) Всем привет! В предыдущем посте мы познакомились с терминами north-south и east-west применительно к кластеру Kubernetes. Давайте разберём подробнее как может быть организована балансировка north-south трафика. Для многих, наверное, уже является привычной связка haproxy+keepalived, в которой поднимается 2 экземпляра haproxy (обычно в режиме L4), а его отказоустойчивость обеспечивается средствами протокола VRRP, который реализуется с помощью keepalived. Но для всех ли случаев может подходить такое решение и в чём могут заключаться основные минусы такого подхода?.. 🤔 Связка haproxy+keepalived - это классический и наипростейший пример балансировки трафика на уровне L4 в режиме Active-Backup, при которой весь трафик проходит только через один экземпляр haproxy, а на второй экземпляр трафик переключается только в том случае, если основной экземпляр haproxy выходит из строя. То есть haproxy является узким горлышком при передаче трафика. Помимо этого, есть также и ещё одно ограничение вследствие использования протокола VRRP: все экземпляры haproxy должны находиться в одном L2-сегменте. Можно ли как-то устранить данные проблемы?.. 🤔 Да, можно! Для этого необходима другая связка, которая умеет работать в режиме Active-Active, например технология BGP ECMP! 🤓 Более подробно о способах балансировки north-south трафика в k8s можно почитать на примере решения loxilb. Сайт содержит описание для конкретного решения, но, на наш взгляд, схемы можно адаптировать под любое решение. Схемы дают общее представление о разных способах балансировки north-south трафика в k8s-кластере на примере балансировщика loxilb, а также даёт общее представление о том в чём отличие между Active-Active и Active-Backup режимами балансировки ;)

Что общего у Kubernetes и у архитектуры дата-центров? Всем привет! Ни для кого не секрет, что  Kubernetes - это достаточно сложная для освоения Платформа. Чего только стоит разобраться в том как организована сеть в кубере!.. 😱 Вот как раз о ней сегодня и поговорим, в частности поговорим о том что может быть общего в организации сети в кубере и в современном дата-центре. 🤓 В дата-центрах принято разделять трафик в зависимости от того в каком направлении он идёт: north-south и east-west, где 🍉 north-south - это так называемый "вертикальный трафик", то есть тот трафик, который поступает в дата-центр из внешних источников или наоборот выходит наружу из дата-центра 🍉 east-west - это "горизонтальный трафик", который не выходит за пределы дата-центра, а возникает вследствие обмена данными между серверами, которые находятся в пределах одного дата-центра. Если проводить аналогию в Kubernetes, то north-south соответствует ingress-egress трафик, а east-west - это трафик между подами и сервисами внутри кластера Kubernetes. Более подробно об этом можно почитать по ссылкам ниже (не смотря на то, что по ссылкам ниже указано описание конкретных решений, тем не менее, это даст общее представление о различиях в разных потоках трафика): 1. https://learn.microsoft.com/en-us/archive/blogs/tip_of_the_day/tip-of-the-day-demystifying-software-defined-networking-terms-the-cloud-compass-sdn-data-flows 2. https://docs.openshift.com/container-platform/4.14/networking/ovn_kubernetes_network_provider/ovn-kubernetes-architecture-assembly.html

Поиск Compromised Cookies, опыт Slack Всем привет! Компрометация Cookie не самая приятная вещь, которая может быть использована для доступа к данным пользователя. Одной из практик противодействия является контроль времени жизни сессии пользователя. Но всегда ли этого достаточно? У ребят из команды Slack свое мнение на этот счет и свои подходы к реализации защиты. Ознакомиться с ними можно в статье. Основная идея Slack заключается в поиске «Session Forking» (т.е. когда один и тот же Cookie используется одновременно на разных устройствах). Для этого они используют Last Access Timestamp – дату «установки» Cookie, которая постоянно обновляется (как в самой Cookie, так и в БД). Сценарий примерно следующий: 🍭 Злоумышленник получил Cookie и пытается с помощью нее получить доступ. Временная метка, скорее всего будет старой и Session Forking будет найден 🍭 Злоумышленник получил «свежий» Cookie и запросил доступ. Last Access Timestamp обновился. Session Forking будет найден уже когда легитимный пользователь запросит доступ (его метка будет старее) Однако, такая логика привела к наличию большого количества False Positive и False Negative при тестировании. И решение… было найдено! Какое? Ответ в статье 😊 Кроме этого, там есть еще несколько интересных рассуждений на тему производительности полученного решения. Рекомендуем!

Как оптимизировать образ контейнера? Всем привет! По ссылке доступна статья, в которой Автор описывает путь, который он проделал, решая задачу по оптимизации образа контейнера. Под оптимизацией в статье, в большей степени, понимается сокращение размера итогового образа. Это может быть полезно, как для ИТ, так и для ИБ (например, для сокращения поверхности атаки, «противодействия» LotL-атакам и т.д.) В итоге Автор прошел путь: 🍭 Обычная сборка образа, использование Alpine в качестве базового 🍭 Multi-stage сборка. Удаление всего, что не требуется для корректной работы ПО, помещенного в контейнер 🍭 Идентификация транзитивных зависимостей, которые надо поместить в образ 🍭 Использование Docker Slim и неожиданный результат 🍭 Использование Docker Squash и не тот результат, который должен был получиться Статья достаточно базовая и может подойти тем, кто только «втягивается». Но в ней весьма неплохо разбираются основные концепты работы с образами, что помогает лучше разобраться, как это все устроено. Помимо самих шагов Автор описывает сложности, с которыми можно столкнуться, впервые реализуя подобное и способы их решения.

Global DevSecOps Report от GitLab (2024) Всем привет! Команда GitLab выпустила очень интересный объемный отчёт аж на 78 листов! Хорошие новости! Согласно результатам опроса более 5 000 специалистов интерес к ИБ растет. Среди основных приоритетов выделяются: Security, AI, DevSecOps Platform, Automation, Cloud Computing. И, конечно, много аналитики-графиков и всего такого по темам: 🍭 Приоритеты инвестиций в IT 🍭 Использование AI в жизненном цикле разработке ПО 🍭 Количество инструментов, которые используются при разработке ПО 🍭 Среднее время onboarding новых специалистов и много другой интересной информации Особенно интересно то, что статистика ответов «разбита» отдельно для разных стран: Австралия, Канада, Франция, Франция, Индия, Япония и т.д.

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 – можно скачать и хоть на стену вешай. Красиво и содержательно!

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, известным уязвимостям, проблемах с лицензиями, сведения о секретах и общий статус «здоровья» пакета. Почитать детальнее про то, как создавался ресурс можно по ссылке, а ознакомиться с ним можно вот тут.

Istio AuthN/Z политики и Otterize! Всем привет! Service Mesh – достаточно популярный ответ, когда появляется вопрос про контроль сетевого трафика в Kubernetes. А одной из самых часто вспоминаемых реализаций Service Mesh является Istio. Нюанс в том, что порог входа в работу с ней может быть высок. Чтобы сделать его чуть проще предлагаем вам ознакомиться со статьей. Авторы рассматривают основные концепты: 🍭 Authorization Policies и их «компоненты» 🍭 Логика «вычисления» политик, если их несколько 🍭 Использование внешних ресурсов для аутентификации и не только В завершении Авторы рассматривают как их собственные наработки могут оптимизировать управление сетевым трафиком в Kubernetes. Про Otterize Network Mapper и Intents Operator мы писали тут и тут. Для этого они рассматривают небольшое приложение, состоящее из нескольких сервисов и сценарии, которые позволяют упростить создание Istio Authorization Policy за счет автоматизации.

Чем плохи 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.

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. Кстати, примерно так может выглядеть внутренняя база знаний по безопасной разработке, о которой так часто упоминают на различных конференциях