Безопасность контейнеров — как не запустить «троянского коня» в своё облако

Когда технология Docker только появилась, её полюбили за лозунг: «Build once, run anywhere» (Собери один раз, запускай везде). Разработчики перестали слышать фразу «на моей машине всё работает, а на сервере — нет». Но вместе с удобством пришла и новая угроза.

Контейнер — это не просто ваше приложение. Это целая мини-операционная система (ОС) со своими библиотеками, утилитами и системными вызовами. И если вы не следите за этой ОС, вы оставляете хакерам огромную дверь, открытую настежь.

Проблема «слоёного пирога»

Docker-образ строится слоями. Каждый раз, когда вы пишете FROM, RUN или COPY в своём Dockerfile, вы добавляете новый слой.

В чём подвох?

Большинство новичков начинают с команды FROM ubuntu:latest или FROM python:3.9.

• Вес: базовый ubuntu сам по себе сравнительно небольшой, но как только вы начинаете ставить пакеты и зависимости, образ очень легко раздувается до сотен мегабайт. А «полные» языковые/SDK-образы действительно часто оказываются тяжёлыми.
• Мусор: в таких образах могут оказаться (или быстро появиться) утилиты вроде curl, wget, пакетный менеджер, shell и прочие инструменты, которые вашему приложению на самом деле не нужны для работы.
• Уязвимости: чем больше пакетов в системе, тем больше в ней дыр. Хакеру не нужно взламывать ваш код на Python — он может использовать уязвимость в старой версии curl, которая просто «лежала рядом» в контейнере.

Линия обороны №1: переход на «золотые образы» (Alpine и Distroless)

Первое правило безопасности контейнеров: выбрасывайте всё лишнее. Если вашему приложению не нужен bash, его не должно быть в контейнере.

1) Alpine Linux

Это сверхлёгкий дистрибутив Linux. Базовый образ весит всего около 5 МБ. В нём нет почти ничего, кроме самого необходимого.

• Плюс: минимум места для атаки.
• Минус: использует библиотеку musl вместо стандартной glibc, что иногда вызывает проблемы с некоторыми специфическими бинарными зависимостями и сборкой отдельных библиотек.

2) Distroless (выбор профессионалов)

Это образы, в которых нет вообще ничего, кроме вашего приложения и его зависимостей. Там нет даже командной строки (shell).

Почему это круто? Если хакер взломает ваше приложение, ему банально сложнее «жить» внутри контейнера: он не сможет просто выполнить ls или curl, чтобы скачать вредоносный софт, потому что привычных инструментов внутри контейнера может не быть.

Линия обороны №2: Multi-stage builds (многоэтапная сборка)

Это техника, которая позволяет использовать тяжёлые инструменты (компиляторы, SDK) для сборки приложения, но не тащить их в финальный образ.

Плохой пример (всё в одном)

FROM python:3.9
COPY . /app
RUN pip install -r /app/requirements.txt  # Здесь остаются кэши и инструменты сборки
CMD ["python", "/app/main.py"]

Хороший пример (Multi-stage)

# Этап 1: Сборка
FROM python:3.9-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt

# Этап 2: Финальный образ (только запуск)
FROM python:3.9-slim
WORKDIR /app
# Копируем только установленные библиотеки из первого этапа
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
# Запускаем от обычного пользователя (см. ниже)
USER 1001
CMD ["python", "main.py"]

Линия обороны №3: никогда не работайте под root

По умолчанию многое в контейнерах запускается от имени root (суперпользователя). Это опасно: если злоумышленник получит выполнение команд внутри контейнера, права root резко расширяют спектр возможных атак, а при наличии дополнительных условий (ошибки конфигурации, привилегированный контейнер, уязвимости ядра) могут усилить ущерб.

Что делать?

Всегда создавайте в Dockerfile пользователя с ограниченными правами и переключайтесь на него через команду USER.

Золотое правило: приложению внутри контейнера почти никогда не нужны права root для обычной работы.

Линия обороны №4: сканирование образов (Trivy возвращается)

Помните инструмент Trivy из прошлой статьи? Он умеет сканировать не только код, но и готовые Docker-образы.

Как это сделать

trivy image my-app:latest

Trivy проверит слои вашего образа и покажет уязвимости в пакетах/компонентах, пришедших вместе с базовым образом и установленными зависимостями, а также подскажет, какие версии считаются исправленными.

Резюме: чек-лист безопасности для ваших контейнеров

Чтобы ваш «сейф» был действительно надёжным, следуйте этим четырём пунктам:

Заключение цикла DevSecOps

Мы разобрали четыре мощных инструмента:

• Git-хуки (Gitleaks): чтобы ключи не покидали ваш компьютер.
• SAST (Semgrep): чтобы ваш код не содержал логических дыр.
• SCA (Trivy): чтобы чужие библиотеки не стали вашей проблемой.
• Container Security: чтобы ваша инфраструктура была лёгкой и защищённой.

Безопасность — это не конечная точка, а процесс. Начните внедрять эти инструменты по одному, и уже через месяц вы заметите, как выросла культура разработки в вашей команде. Теперь вы не просто «пишете код», вы создаёте надёжные системы.