Защищаем контейнеры с нуля: практическое руководство по Docker security и Kubernetes security contexts

Привет, Кореша! Вы когда-нибудь задумывались о безопасности контейнеров, работающих в продакшене? Docker и Kubernetes предоставляют широкий набор инструментов, которые могут быть использованы плохими людьми. Безопасность контейнеров — это не просто волшебная защита, а многослойная система, охватывающая весь процесс от сборки до запуска в кластере.

В этой статье мы разберем практические шаги по защите ваших контейнеров, от написания безопасного Dockerfile до настройки политик безопасности в Kubernetes.

Этап 1: Безопасность на этапе сборки (Dockerfile)

Безопасность начинается с образа. Ваша цель — создать минимальный, неизменяемый и безопасный артефакт.

1. Используйте минимальные базовые образы
Чем меньше пакетов внутри, тем меньше шанс для атаки.

Нельзя:

dockerfile

FROM ubuntu:latest  # Полноценная ОС со всеми утилитами и уязвимостями RUN apt update && apt install -y python3 COPY app.py . CMD ["python3", "app.py"]

Можно:

dockerfile

FROM python:3.11-slim-bookworm  # Урезанный официальный образ на основе Debian slim COPY app.py . CMD ["python3", "app.py"]

Идеально (для Go, Java, Node.js):

dockerfile

# Multi-stage build - идеальный вариант FROM golang:1.21 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -o myapp .  # Финальный образ на основе "scratch" (абсолютно пустой) или distroless FROM gcr.io/distroless/static-debian12 COPY --from=builder /app/myapp / CMD ["/myapp"]

Образ distroless от Google содержит только ваше приложение и его минимальные зависимости, без shell, package manager и других стандартных утилит. Взломщику просто нечем будет воспользоваться.

2. Не запускайте процессы от root
Это золотое правило контейнерной безопасности.

Плохо:

dockerfile

FROM node:20 COPY . . RUN npm install CMD ["node", "index.js"] # Запускается от root!

Хорошо:

dockerfile

FROM node:20-slim  # Создаем непривилегированного пользователя и группу RUN groupadd -r appgroup && useradd -r -g appgroup appuser  # Меняем владельца файлов приложения COPY --chown=appuser:appgroup . /app WORKDIR /app RUN npm install  # Переключаемся на непривилегированного пользователя USER appuser  CMD ["node", "index.js"]

3. Сканируйте образы на уязвимости
Интегрируйте сканирование в CI/CD пайплайн.

bash

# Пример с Trivy (бесплатный и открытый сканер) trivy image my-app:latest  # Или с Docker Scout docker scout quickview my-app:latest

Этап 2: Безопасность на этапе выполнения (Kubernetes Security Contexts)

Kubernetes предоставляет мощный инструмент — securityContext, который позволяет fine-grained настройку прав контейнера.

1. Запрещаем запуск от root
Даже если в образе забыли указать USER.

yaml

apiVersion: v1 kind: Pod metadata:   name: security-demo spec:   containers:   - name: sec-ctx-demo     image: node:20-slim     securityContext:       runAsNonRoot: true # Kubernetes не даст запустить pod, если он работает от root       runAsUser: 1000 # Явно указываем UID       runAsGroup: 3000 # Явно указываем GID

2. Ограничиваем возможности (Capabilities)
По умолчанию контейнер получает множество ненужных привилегий. Отзовите всё и дайте только необходимое.

yaml

securityContext:   capabilities:     drop: ["ALL"] # Отзываем ВСЕ возможности     add: ["NET_BIND_SERVICE"] # Добавляем только одну: возможность занять порт ниже 1024

3. Запрещаем эскалацию привилегий
Важная настройка, которая не позволяет процессу внутри контейнера получить больше прав, чем у него есть.

yaml

securityContext:   allowPrivilegeEscalation: false

4. Режим только для чтения (ReadOnlyRootFilesystem)
Идеальная практика для неизменяемых контейнеров. Если вашему приложению не нужно ничего писать на диск — включайте.

yaml

securityContext:   readOnlyRootFilesystem: true # Но если нужно писать логи во временную папку volumeMounts: - name: temp-vol   mountPath: /tmp   readOnly: false  volumes: - name: temp-vol   emptyDir: {}

Этап 3: Системные политики (Pod Security Standards)

SecurityContext — это хорошо для одного пода. Но что если нужно применить политики ко всему кластеру? Здесь на помощь приходят Pod Security Admission (встроено в K8s с v1.25+) или более старый PodSecurityPolicy (устарел).

Уровни политик PSA:

• Privileged: Без ограничений, для системных workloads.

• Baseline: Минимальные ограничения, блокирующие известные эскалации привилегий.

• Restricted: Жесткие ограничения, следующие best practices.

Пример Namespace с политикой Restricted:

yaml

apiVersion: v1 kind: Namespace metadata:   name: my-app   labels:     pod-security.kubernetes.io/enforce: restricted     pod-security.kubernetes.io/enforce-version: v1.29

Теперь при попытке создать под без securityContext в этом неймспейсе он будет отвергнут.

Этап 4: Следующий уровень — AppArmor и seccomp

Для параноиков и тех, кому нужна максимальная защита

Seccomp — ограничивает системные вызовы, которые может делать процесс.

yaml

securityContext:   seccompProfile:     type: RuntimeDefault # Используем профиль по умолчанию, предоставленный container runtime

Можно создавать и свои кастомные профили, чтобы запрещать опасные вызовы вроде execve.

Практический чеклист для внедрения

1. Сборка: Используйте multi-stage сборку и distroless/scratch образы.

2. Запуск: Всегда запускайте контейнеры от непривилегированного пользователя (USER в Dockerfile + runAsNonRoot: true в K8s).

3. Политики: Настройте Pod Security Admission на уровне неймспейсов как минимум с baseline уровнем.

4. Сканирование: Встройте сканирование образов на уязвимости (Trivy) в CI/CD.

5. Сетевые политики: Не забывайте про NetworkPolicy для изоляции трафика между подами.

Заключение

Безопасность контейнеров — это не продукт, а процесс и правильная конфигурация. Начиная с минимального образа и заканчивая строгими политиками в кластере, вы выстраивайте многоуровневую защиту, которая серьезно усложнит жизнь злоумышленнику.

Если нужен шаблон правильных контейнеров, конфиг PSS, загляните на bfd cards, где эти вопросы разбираются регулярно.

А какие практики безопасности используете вы? Делитесь в комментариях!