Security+ Academy · Урок

Безопасность контейнеров: усиление образов и защита во время выполнения

Урок 1 из 413 шагов

«Безопасность контейнеров: усиление образов и защита во время выполнения» — бесплатный урок Security+ Academy на CoddyKit. Это урок 1 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Security+ Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Security+ Academy содержит 4 уроков всего.

Основы безопасности контейнеров

Контейнеры объединяют код приложения и его зависимости в изолированные единицы, совместно использующие ядро OS хоста, в отличие от виртуальных машин, которые включают полноценную гостевую OS. Благодаря этому контейнеры легковесны и работают быстро, но используют другую модель безопасности: уязвимость, позволяющая выйти из контейнера, может дать атакующему возможность вырваться из него и получить прямой доступ к ядру хоста, затронув все остальные контейнеры. Безопасность контейнеров сосредоточена на трёх уровнях: образе (что в него встроено), среде выполнения (что контейнер может делать во время работы) и платформе оркестрации (как управляются контейнеры).

Минимальные базовые образы: уменьшение поверхности атаки

Каждый пакет, установленный в образ контейнера, потенциально расширяет поверхность атаки. Принцип минимальных базовых образов предполагает использование в качестве основы самого небольшого варианта: Alpine Linux (5 МБ, минимальный набор пакетов), образов без дистрибутива (образов Google, содержащих только среду выполнения и приложение, без оболочки и менеджера пакетов) или scratch (полностью пустого образа для статически скомпилированных двоичных файлов). Если в контейнере нет оболочки, атакующий, получивший возможность выполнять код, не сможет легко запустить wget, curl или другие инструменты для расширения атаки — этот принцип называется защитой за счёт минимальной открытости.

# Bad: starts from a full OS image
FROM ubuntu:22.04

# Better: minimal Alpine base
FROM alpine:3.18

# Best: distroless for Java apps
FROM gcr.io/distroless/java17-debian11

Работа без прав root: первое правило

По умолчанию контейнеры Docker работают с правами root (UID 0). Если атакующий воспользуется уязвимостью в приложении, работающем в контейнере, он получит права root внутри контейнера. Если контейнер совместно использует том или подключённые каталоги хоста, права root внутри контейнера могут означать права root на хосте. Решение простое: создайте отдельного пользователя в Dockerfile и переключитесь на него с помощью директивы USER перед последней командой CMD/ENTRYPOINT. Многие инструменты сканирования безопасности контейнеров помечают любой образ без пользователя, не являющегося root, как проблему.

FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --chown=appuser:appgroup app /app/app
USER appuser
CMD ["/app/app"]

Неизменяемые контейнеры и файловые системы только для чтения

Неизменяемые контейнеры — это контейнеры, файловую систему которых нельзя изменять во время работы. Включение параметра --read-only в Docker (или readOnlyRootFilesystem: true в Kubernetes) не позволяет атакующим записывать вредоносные программы на диск, изменять файлы конфигурации или устанавливать инструменты в работающий контейнер. Приложениям, которым действительно нужно записывать данные (журналы, временные файлы), можно подключить отдельные тома tmpfs для временной записи. Неизменяемые контейнеры закрепляют принцип, согласно которому состояние во время работы должно поступать только из образа и конфигурации, а не из изменений внутри контейнера, обходящих Ваш конвейер безопасности CI/CD.

# Run container with read-only root filesystem
docker run --read-only \
  --tmpfs /tmp \
  --tmpfs /var/run \
  myapp:latest

Сканирование образов: поиск CVE до развёртывания

Инструменты для сканирования образов контейнеров анализируют пакеты, установленные в образе Docker, и сопоставляют их с базами данных уязвимостей (NVD, CVE), сообщая об известных уязвимостях CVE. К ведущим средствам сканирования относятся Trivy (Aqua Security, быстрое и бесплатное), Grype (Anchore), Snyk Container и сканирование образов AWS ECR. Сканирование следует интегрировать в конвейер CI/CD, чтобы любой образ с критическими уязвимостями CVE или уязвимостями высокого уровня приводил к сбою конвейера до отправки образа в реестр. Сканеры также должны проверять наличие секретов (ключей API, паролей), случайно встроенных в слои образа.

# Scan a Docker image with Trivy
trivy image --severity HIGH,CRITICAL myapp:latest

# Fail CI pipeline if vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL myapp:latest

Управление секретами: никогда не храните их в слоях образа

Распространённая и опасная ошибка — встраивать секреты (ключи API, пароли баз данных, сертификаты TLS) в образы Docker: либо в переменные среды, сохранённые в образе, либо в файлы, добавленные с помощью COPY. Эти секреты видны всем, у кого есть доступ к образу, через docker history или при извлечении слоёв образа. Даже если последующий слой удаляет файл, он всё равно сохраняется в истории образа. Секреты следует передавать во время работы приложения через переменные среды из менеджера секретов, с помощью секретов Docker или секретов Kubernetes, подключённых как тома.

# Never bake secrets into images
# Bad: ENV DATABASE_PASSWORD='supersecret'

# Good: inject at runtime via environment
docker run -e DATABASE_PASSWORD=$(vault read -field=password secret/db) myapp:latest

# Or use Docker secrets in Swarm/K8s

Защита во время выполнения: Falco и мониторинг системных вызовов

Инструменты защиты во время выполнения отслеживают поведение контейнеров во время работы и предупреждают о подозрительной активности или блокируют её. Falco (проект CNCF) подключается к ядру Linux с помощью eBPF или модулей ядра, перехватывает системные вызовы и сопоставляет их с правилами. Например, правило может выдавать предупреждение, если контейнер запускает оболочку (execve('/bin/sh')), открывает сетевое соединение на неожиданном порте или читает /etc/shadow. Такие поведенческие признаки часто указывают на активную атаку, даже если ни одна известная уязвимость CVE не была использована. Sysdig Secure и Aqua Security предоставляют коммерческие платформы защиты во время выполнения.

# Example Falco rule: alert on shell execution in container
# - rule: Shell Spawned in Container
#   desc: A shell was spawned in a container
#   condition: container and proc.name in (bash, sh, zsh)
#   output: Shell spawned (user=%user.name container=%container.name)
#   priority: WARNING

Возможности Linux и профили Seccomp

Контейнеры Docker по умолчанию отключают многие возможности Linux, но всё же сохраняют больше прав, чем требуется большинству приложений. Возможности разделяют привилегии root на отдельные компоненты (например, CAP_NET_ADMIN, CAP_SYS_ADMIN). Рекомендуется отключить все возможности и добавить только необходимые с помощью --cap-drop=ALL --cap-add=NET_BIND_SERVICE. Профили Seccomp (Secure Computing Mode) задают белый список системных вызовов, которые разрешено выполнять контейнеру; Docker включает профиль Seccomp по умолчанию, блокирующий около 44 опасных системных вызовов. Пользовательские профили Seccomp для конкретных приложений позволяют ужесточить ограничения, блокируя все системные вызовы, которые приложение не использует легитимным образом.

# Drop all capabilities, add only what's needed
docker run \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --security-opt seccomp=/etc/docker/seccomp-custom.json \
  myapp:latest

Реестры контейнеров и подписание образов

Реестры контейнеров (Docker Hub, AWS ECR, Google Artifact Registry) хранят и распространяют образы. Защита реестра включает: включение сканирования уязвимостей при отправке, ограничение доступа к отправке только для служебных учётных записей CI/CD, включение подписания образов с помощью Sigstore/Cosign или Docker Content Trust (Notary), чтобы среды выполнения загружали только криптографически подписанные образы из доверенных источников, а также настройку неизменяемости образов, чтобы теги нельзя было перезаписать (это устраняет атаки с подменой тегов, при которых злоумышленник заменяет доверенный тег :latest вредоносным образом).

# Sign a container image with Cosign
cosign sign --key cosign.key myregistry.io/myapp:v1.2.3

# Verify signature before deployment
cosign verify --key cosign.pub myregistry.io/myapp:v1.2.3

Методы выхода из контейнера и защита от них

Злоумышленники, получившие возможность выполнять код внутри контейнера, могут попытаться осуществить выход из контейнера и получить доступ к узлу. Распространённые методы включают: эксплуатацию уязвимых привилегированных контейнеров (--privileged предоставляет почти неограниченный доступ к узлу), злоупотребление открытыми сокетами Docker (подключённый к контейнеру /var/run/docker.sock предоставляет полный доступ к API Docker, включая создание привилегированных контейнеров), а также эксплуатацию уязвимостей ядра с помощью небезопасно настроенных возможностей. Меры защиты: не используйте привилегированный режим без крайней необходимости, никогда не подключайте сокет Docker к контейнерам приложений, своевременно устанавливайте исправления для ядра узла и используйте gVisor или Kata Containers для рабочих нагрузок, требующих сильной изоляции.

# DANGEROUS: never do this in production
# docker run --privileged -v /:/host myapp:latest

# Check if a container is running privileged
docker inspect mycontainer | grep -i privileged

Соответствие эталону CIS Docker

Эталон Center for Internet Security (CIS) для Docker содержит подробные рекомендации по настройке безопасности узлов и контейнеров Docker, включая конфигурацию службы, гигиену образов, параметры среды выполнения контейнеров и сетевые средства управления. Такие инструменты, как Docker Bench for Security, автоматизируют проверку соответствия эталону CIS и формируют оценочный отчёт с пройденными и непройденными пунктами. Периодический запуск этого эталона и его интеграция в CI/CD позволяют быстро обнаруживать отклонения в конфигурации безопасности. Кандидатам на Security+ следует знать, что эталоны CIS являются основным справочным материалом по усилению защиты OS и платформ в контексте экзамена.

# Run Docker Bench for Security
docker run -it --net host --pid host --userns host --cap-add audit_control \
  -v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc:/etc docker/docker-bench-security

Быстрая проверка

Проверьте понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.

Ответь в интерактивном уроке

Итоги урока

В этом уроке Вы узнали, что минимальные базовые образы и пользователи без прав root уменьшают поверхность атаки и уровень привилегий рабочих нагрузок в контейнерах, инструменты защиты во время выполнения, такие как Falco, обнаруживают характерные для активных атак аномальные шаблоны системных вызовов внутри контейнеров, а привилегированные контейнеры нельзя использовать, как и нельзя подключать сокет Docker к контейнерам приложений, поскольку такие конфигурации позволяют выйти из контейнера. Далее мы рассмотрим безопасность Kubernetes, включая RBAC, сетевые политики и стандарты безопасности Pod.

Можно начать бесплатно

Изучай Security+ Academy с ИИ-репетитором — бесплатно

Пиши и запускай код прямо в браузере, получай мгновенную помощь от ИИ-репетитора 24/7 и продолжи учиться на сайте или в приложении.

Курсы: 30
Уроки: 120

Начать учиться бесплатно Посмотреть полный курс

Часто задаваемые вопросы

Урок «Безопасность контейнеров: усиление образов и защита во время выполнения» бесплатный?

Да — полный текст урока «Безопасность контейнеров: усиление образов и защита во время выполнения» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Security+ Academy, подпишись на CoddyKit PRO. Курс Security+ Academy содержит 4 уроков всего.

Чему я научусь в уроке «Безопасность контейнеров: усиление образов и защита во время выполнения»?

Усиливайте образы Docker, удаляя ненужные пакеты и запуская их без прав суперпользователя, а также используйте средства защиты во время выполнения (Falco, Sysdig) для обнаружения аномального поведени… Ты практикуешь Security+ Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Security+ Academy?

Предыдущий опыт не требуется. Security+ Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 1 из 4.

Сколько времени занимает урок «Безопасность контейнеров: усиление образов и защита во время выполнения»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Security+ Academy?

Да. Каждый урок Security+ Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

Безопасность контейнеров: усиление образов и защита во время выполнения
Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов
Безсерверные системы и безопасность функций
Сканирование безопасности инфраструктуры как кода

← Назад к Security+ Academy