Тестирование безопасности микросервисов и контейнеров
Для команд, эксплуатирующих платформы на контейнерах, service mesh или Kubernetes, где одна ошибочная привязка RBAC или неаутентифицированный east-west вызов способны раскрыть весь кластер. Мы тестируем слои, до которых пентест веб-приложения не доходит: доверие между сервисами, control plane, цепочку поставки образов и управление секретами — и доказываем, по каким путям злоумышленник реально может продвинуться.
Что мы проверяем
AuthN/authZ между сервисами (mTLS и zero-trust)
Проверяем, что east-west трафик требует взаимный TLS (PeerAuthentication STRICT), отклоняет plaintext, а AuthorizationPolicy действительно блокирует по умолчанию — а не работает в режиме permissive без allow-правил и без отката к подделываемой идентичности через X-Forwarded-For / без JWT.
Захват идентичности workload и злоупотребление токенами
Пытаемся извлечь токены ServiceAccount из подов, воспроизвести их против API-сервера и тестируем проверку audience/issuer у SPIFFE/JWT — выявляя избыточно широкие токены и отсутствие валидации `aud`/`exp` (NIST SP 800-204B, ABAC).
Повышение привилегий в RBAC Kubernetes
Картируем каждый Role/ClusterRoleBinding на wildcard-глаголы, права `escalate`/`bind`/`impersonate`, листинг секретов, `pods/exec` и node-proxy, позволяющие идентичности в пределах namespace дойти до cluster-admin.
Network policies и сегментация east-west
Default-deny обычно отсутствует — доказываем плоскую сеть подов, продвигаясь из одного скомпрометированного пода в несвязанные namespace, к kubelet (10250), etcd (2379) и метаданным облака (169.254.169.254) для кражи учётных данных IMDS.
CVE в образах и целостность SBOM
Генерируем SBOM (Syft/CycloneDX), сканируем эксплуатируемые CVE в зависимостях ОС и приложения, отмечаем образы под root/privileged, секреты в слоях, а также неприкреплённые `:latest` и неподписанные образы (без аттестации cosign/Notation).
Харденинг подов (Pod Security Standards)
Ищем privileged поды, монтирования hostPath/hostNetwork/hostPID, `allowPrivilegeEscalation`, отсутствие seccomp/AppArmor и CAP_SYS_ADMIN — примитивы побега из контейнера, измеряемые по CIS и Pod Security Standards `restricted`.
Экспозиция управления секретами
Проверяем секреты в открытом виде (base64 — не шифрование), секреты в переменных окружения и манифестах, отсутствие шифрования at-rest для etcd и то, действительно ли внешние хранилища (Vault, KMS/CSI) ограничивают доступ, а не монтируют всё в каждый под.
API gateway и цепочка поставки (CI/CD)
Тестируем ingress/API gateway на обход аутентификации, header smuggling и пробелы rate-limit, а также ревьюим CI/CD на инъектируемые пайплайны, избыточно привилегированных раннеров и непроверенные артефакты (OWASP Top 10 CI/CD, provenance SLSA).
Методология
- 1
Определение объёма и разведка архитектуры
Совместно картируем границы доверия: namespace, service mesh (Istio/Linkerd), ingress, реестры, CI/CD и облачный IAM. Модель доступа согласуем заранее — внешний black-box, под-плацдарм в кластере и/или read-only kubeconfig — с правилами работы в общем кластере (PTES pre-engagement).
- 2
Внешнее тестирование и API gateway
Извне кластера перечисляем открытые сервисы, ingress и случайно опубликованные внутренние панели (Kubelet, etcd, Dashboard, реестры) и тестируем API gateway на обход authN/authZ — парадный вход злоумышленника, сопоставленный с OWASP API Security Top 10.
- 3
Оценка конфигурации кластера
Аутентифицированный обзор RBAC, network policies, Pod Security, admission control (OPA/Gatekeeper/Kyverno), флагов API-сервера и шифрования etcd, сверенный с CIS Kubernetes Benchmark и NIST SP 800-190 — отделяя теоретические находки от эксплуатируемых.
- 4
East-west продвижение и эскалация
С пода-плацдарма в модели assumed-breach отслеживаем реальные пути атаки: кражу токенов, доступ к учётным данным node/metadata, побег из контейнера, латеральное движение между namespace и путь к cluster-admin, сопоставленные с MITRE ATT&CK for Containers.
- 5
Анализ цепочки поставки и образов
Генерация SBOM, сканирование CVE и секретов в образах, обзор базовых образов и provenance, проверка подписей/аттестаций (cosign/Notation, SLSA) и пути злоупотребления пайплайном CI/CD, позволяющие коду попасть в прод без проверки.
- 6
Отчёт, разбор и ретест
Каждая находка содержит точный манифест/команду для воспроизведения, контекст кластера, оценку CVSS v3.1 и конкретную рекомендацию (конкретная политика, а не «усильте RBAC»). Живой разбор с платформенной командой и бесплатный ретест исправленных уязвимостей.
Стандарты и ссылки
Что вы получаете
- Технический отчёт с воспроизводимыми PoC — Каждая находка с манифестом, командой kubectl/curl и выводом для воспроизведения, оценкой CVSS v3.1, затронутым namespace/workload и конкретным исправлением.
- Нарратив пути атаки — Kill chain в модели assumed-breach — от пода-плацдарма до cluster-admin или данных — сопоставленный с MITRE ATT&CK for Containers, чтобы вы видели последовательность, а не отдельные флаги.
- Список пробелов конфигурации CIS и Pod Security — Приоритизированные отклонения от бенчмарка по RBAC, network policy, Pod Security Standards и состоянию образов, помеченные как эксплуатируемые vs. рекомендованные к харденингу.
- Инвентарь SBOM и уязвимостей образов — SBOM CycloneDX для каждого сканируемого образа плюс дедуплицированный, ранжированный по эксплуатируемости список CVE — а не сырой шум сканера.
- Резюме для руководства и аттестация ретеста — Одностраничное резюме рисков для руководства/compliance, а также раунд ретеста и письмо, подтверждающее, какие находки закрыты.
Частые вопросы
Нужен ли вам доступ cluster-admin для тестирования?+
Нет. Доступ подбираем под ваш аппетит к риску. Наиболее реалистичный сценарий — assumed-breach: вы даёте нам под-плацдарм с низкими привилегиями и/или read-only kubeconfig, а мы доказываем, куда доберётся злоумышленник, захвативший один контейнер. Доступны и чисто внешний black-box, и полный обзор конфигурации — модель согласуем при определении объёма.
Не нарушит ли тест работу нашего продакшн-кластера?+
Тестирование по умолчанию неразрушающее. Мы избегаем исчерпания ресурсов, не удаляем workload, а любое потенциально нарушающее действие (например, контролируемый PoC побега из контейнера) заранее объявляется и запускается только на согласованном вами namespace или staging-кластере. Правила работы и план отката согласуются до того, как мы что-либо трогаем.
Сколько это занимает и сколько стоит?+
Сфокусированный тест одного кластера — обычно 5–8 рабочих дней; крупные multi-cluster или multi-mesh среды — 2–3 недели. Стоимость зависит от числа кластеров, объёма namespace/сервисов и того, входят ли в объём цепочка поставки образов и CI/CD. Фиксированную смету вы получаете после короткого звонка по объёму — без открытого биллинга.
Что нужно предоставить для старта?+
Заметки об архитектуре/модели угроз, если есть, объём цели (кластеры, namespace, реестры, адреса gateway), согласованный артефакт доступа (спецификация пода-плацдарма или kubeconfig) и подписанную авторизацию. Если в объём входит облачный IAM, попросим read-only роль. Этого обычно достаточно, чтобы начать в течение нескольких дней.
Это отчёт сканера или ручное тестирование?+
И то, и другое, в правильном порядке. Автоматические инструменты (Trivy/Grype, kube-bench, kube-hunter, Syft) дают охват, но каждая находка вручную верифицируется и связывается тестировщиком — мы отбрасываем false positive и, что важнее, соединяем по отдельности незначительные ошибки конфигурации в реальный путь к cluster-admin. Вы получаете эксплуатируемость, а не сырой вывод сканера.
Вы покрываете образы контейнеров и CI/CD или только работающий кластер?+
И то, и другое, если входит в объём. Мы генерируем SBOM и сканируем образы на CVE и встроенные секреты, ревьюим базовые образы и подписи/аттестации (cosign, provenance SLSA) и оцениваем пайплайн CI/CD на инъектируемые шаги и избыточно привилегированных раннеров — потому что в микросервисах пайплайн часто оказывается самым мягким путём в продакшн.