Безпека образів, підписування та секрети

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Огляд

Безпека контейнерів починається до запуску робочого навантаження. Образ визначає, які бінарні файли, інтерпретатори, бібліотеки, стартові скрипти та вбудовані конфігурації потраплять у продуктивне середовище. Якщо образ містить backdoor, застарілий або збудований із вшитими секретами, подальше укріплення середовища виконання вже працюватиме з компрометованим артефактом.

Ось чому встановлення походження образу, сканування вразливостей, перевірка підписів та обробка секретів належать до тієї ж розмови, що й namespaces і seccomp. Вони захищають іншу фазу життєвого циклу, але невдачі тут часто визначають поверхню атаки, яку середовище виконання пізніше має стримувати.

Реєстри образів та довіра

Образи можуть надходити з публічних реєстрів, таких як Docker Hub, або з приватних реєстрів, керованих організацією. Питання безпеки — не лише де зберігається образ, а чи може команда встановити його походження та цілісність. Завантаження непідписаних або погано відстежуваних образів з публічних джерел підвищує ризик потрапляння шкідливого або підробленого вмісту в продуктивне середовище. Навіть внутрішні реєстри потребують чіткого володіння, перегляду та політики довіри.

Docker Content Trust історично використовував концепції Notary і TUF для вимоги підписаних образів. Конкретна екосистема еволюціонувала, але незмінний урок залишається корисним: ідентичність та цілісність образу повинні бути перевірюваними, а не прийматися як належне.

Приклад історичного робочого процесу Docker Content Trust:

export DOCKER_CONTENT_TRUST=1
docker pull nginx:latest
tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private

Суть прикладу не в тому, що кожна команда має використовувати одні й ті самі інструменти, а в тому, що підписування і управління ключами — це операційні завдання, а не абстрактна теорія.

Сканування вразливостей

Сканування образів допомагає відповісти на два різні питання. По-перше, чи містить образ відомі вразливі пакети або бібліотеки? По-друге, чи містить образ непотрібне програмне забезпечення, що розширює поверхню атаки? Образ, заповнений налагоджувальними інструментами, оболонками, інтерпретаторами та застарілими пакетами, легше експлуатувати і складніше аналізувати.

Приклади поширених сканерів включають:

docker scan hello-world
trivy -q -f json alpine:3.19
snyk container test nginx:latest --severity-threshold=high
clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5

Результати цих інструментів слід інтерпретувати обережно. Уразливість у невикористаному пакеті не еквівалентна за ризиком відкритому шляху для RCE, але обидві є релевантними для рішень щодо зміцнення безпеки.

Секрети під час збірки

Одна з найстаріших помилок у конвеєрах збірки контейнерів — вбудовування секретів безпосередньо в образ або передача їх через змінні оточення, які згодом стають видимими через docker inspect, журнали збірки або відновлені шари. Секрети під час збірки слід монтувати тимчасово під час збірки, а не копіювати у файлову систему образу.

BuildKit покращив цю модель, дозволивши спеціалізовану обробку секретів під час збірки. Замість того, щоб записувати секрет у шар, крок збірки може тимчасово його використовувати:

export DOCKER_BUILDKIT=1
docker build --secret id=my_key,src=path/to/my_secret_file .

Це важливо, оскільки шари образу є стійкими артефактами. Як тільки secret потрапляє до закоміченого шару, подальше видалення файлу в іншому шарі насправді не видаляє початкового розкриття з історії образу.

Runtime Secrets

Secrets, необхідні для працюючого робочого навантаження, по можливості також слід уникати ad hoc патернів, таких як прості змінні середовища. Volumes, спеціалізовані інтеграції для secret-management, Docker secrets і Kubernetes Secrets — це поширені механізми. Жоден із них не усуває всіх ризиків, особливо якщо зловмисник уже має code execution у робочому навантаженні, проте вони все ж кращі за постійне зберігання облікових даних в образі або випадкове їх показування через інструменти інспекції.

Просте оголошення secret у стилі Docker Compose виглядає так:

version: "3.7"
services:
my_service:
image: centos:7
entrypoint: "cat /run/secrets/my_secret"
secrets:
- my_secret
secrets:
my_secret:
file: ./my_secret_file.txt

У Kubernetes Secret objects, projected volumes, service-account tokens і cloud workload identities створюють ширшу й потужнішу модель, але вони також створюють більше можливостей для ненавмисного розкриття через host mounts, широкі RBAC або слабкий дизайн Pod.

Зловживання

Під час перегляду цілі мета — виявити, чи були секрети вбудовані в image, leaked into layers або змонтовані в передбачувані runtime locations:

env | grep -iE 'secret|token|key|passwd|password'
find / -maxdepth 4 \( -iname '*.env' -o -iname '*secret*' -o -iname '*token*' \) 2>/dev/null | head -n 100
grep -RniE 'secret|token|apikey|password' /app /srv /usr/src 2>/dev/null | head -n 100

Ці команди допомагають відрізнити три різні проблеми: application configuration leaks, image-layer leaks, and runtime-injected secret files. Якщо секрет з’являється під /run/secrets, у projected volume або за шляхом cloud identity token, наступним кроком буде з’ясувати, чи надає він доступ лише до поточного workload або до значно ширшого control plane.

Повний приклад: вбудований секрет у файловій системі образу

Якщо конвеєр збірки скопіював .env файли або облікові дані в фінальний образ, post-exploitation стає простим:

find / -type f -iname '*.env*' 2>/dev/null
cat /usr/src/app/.env 2>/dev/null
grep -iE 'secret|token|jwt|password' /usr/src/app/.env 2>/dev/null

Вплив залежить від застосунку, але вбудовані ключі підпису, JWT-секрети або облікові дані хмари можуть легко перетворити компрометацію контейнера на компрометацію API, lateral movement або підробку довірених токенів застосунку.

Повний приклад: перевірка витоку секретів під час збірки

Якщо існує побоювання, що image history зафіксував шар, який містить секрети:

docker history --no-trunc <image>
docker save <image> -o /tmp/image.tar
tar -tf /tmp/image.tar | head

Цей тип перевірки корисний, оскільки secret міг бути видалений із фінального вигляду filesystem, але все ще залишатися в попередньому layer або в build metadata.

Перевірки

Ці перевірки покликані встановити, чи ймовірно, що image і secret-handling pipeline збільшили attack surface до runtime.

docker history --no-trunc <image> 2>/dev/null
env | grep -iE 'secret|token|key|passwd|password'
find /run /var/run /var/lib/kubelet -type f -iname '*token*' 2>/dev/null | head -n 50
grep -RniE 'secret|token|apikey|password' /etc /app /srv /usr/src 2>/dev/null | head -n 100

What is interesting here:

  • Підозріла історія збірок може виявити скопійовані облікові дані, SSH-матеріали або небезпечні кроки збірки.
  • Secrets під шляхами projected volume можуть дозволити доступ до кластера або хмари, а не лише до локального застосунку.
  • Велика кількість файлів конфігурації з обліковими даними у відкритому тексті зазвичай свідчить про те, що образ або модель розгортання містять більше матеріалів довіри, ніж потрібно.

Runtime Defaults

Runtime / platformDefault stateDefault behaviorCommon manual weakening
Docker / BuildKitПідтримує безпечні build-time secret mounts, але не автоматичноСекрети можна тимчасово монтувати під час build; підписування та сканування образів вимагають явного вибору робочого процесукопіювання секретів в образ, передача секретів через ARG або ENV, відключення перевірок provenance
Podman / BuildahПідтримує OCI-native builds та робочі процеси, що враховують секретиДоступні надійні робочі процеси збірки, але оператори повинні свідомо їх обиративбудовування секретів у Containerfiles, широкі build contexts, дозволяючі bind mounts під час збірки
KubernetesНативні об’єкти Secret та projected volumesДоставка секретів у runtime є першокласною, але експозиція залежить від RBAC, дизайну pod і host mountsнадмірно широкі монтування Secret, неправильне використання service-account token, hostPath доступ до kubelet-managed volumes
RegistriesЦілісність опціональна, якщо її явно не забезпечено політикоюПублічні та приватні registries залежать від політик, підписування та рішень admissionвільне витягування непідписаних образів, слабкий admission control, погане управління ключами

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks