Тестування безпеки мікросервісів і контейнерів
Для команд, що експлуатують платформи на контейнерах, 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 на інʼєктовані кроки й надмірно привілейованих раннерів — бо в мікросервісах пайплайн часто виявляється найм’якшим шляхом у продакшн.