Статья Безопасность контейнеров: Docker и Kubernetes — как защитить инфраструктуру

Современные облачные и on-premise среды всё чаще строятся на контейнерах — лёгких, портируемых и быстрых в развёртывании. Однако высокая скорость доставки может оборачиваться новыми векторами атак. В этой статье вы узнаете, как обеспечить надёжную защиту Docker и Kubernetes-инфраструктуры: от основ изоляции до продвинутых механизмов контроля доступа и политики безопасности.

---

1. Изоляция контейнеров как основа безопасности​

Контейнеры реализуют изоляцию на уровне ядра ОС, чтобы процессы и ресурсы одного приложения не мешали другому.

• Namespaces (пространства имён)
  – PID: изолирует идентификаторы процессов, предотвращая видимость процессов чужих контейнеров.
  – IPC: раздельные каналы обмена (семафоры, очереди сообщений), исключающие несанкционированный перехват данных.
  – UTS: позволяет контейнеру иметь собственное имя хоста без влияния на остальную систему.
  – Network: каждому контейнеру назначается отдельный виртуальный сетевой стек с собственными интерфейсами и маршрутами.
  – Mount: корневая файловая система контейнера виртуализирована, а монтируемые тома управляются централизованно.
• cgroups (Control Groups)
  Регулируют потребление ресурсов: CPU, память, диск, сеть. Ограничение памяти предотвращает завершение процессов на хосте при переполнении контейнера, а лимиты CPU не дают одному контейнеру монополизировать вычислительные ресурсы.
• UnionFS (overlay2, aufs, btrfs)
  Образ контейнера составляется из слоёв: базовый read-only слой и верхние слои для изменений. Это обеспечивает неизменяемость оригинального образа и упрощает обновления и откаты.

Изоляция — первая линия защиты. Но поскольку все контейнеры разделяют общее ядро ОС, важно не допускать привилегированного доступа внутри контейнера.

---

2. Основные риски в Docker и Kubernetes​

Теория рисков даёт понимание угроз, но без конкретных примеров сложно оценить их масштаб. Рассмотрим ключевые векторы атак в Docker и Kubernetes.

2.1 Риски в Docker​

1. Запуск контейнеров от root-пользователя
   Процессы внутри контейнера работают с UID 0. При прорыве из контейнера злоумышленник получает root-доступ на хосте.
2. Отсутствие ограничений ресурсов
   Без cgroups контейнер способен монополизировать CPU и память хоста, что приводит к отказу других сервисов.
3. Небезопасные монтирования
   Монтирование корневого диска хоста (-v /:/host) даёт контейнеру полный доступ к системным файлам и секретным данным.

2.2 Риски в Kubernetes​

1. Привилегированные поды
   Опции privileged: true, hostNetwork: true или hostPID: true предоставляют контейнеру практически неограниченный доступ к ядру и сети хоста.
2. Ненадёжные образы
   Публичные реестры могут содержать вредоносный код или уязвимые библиотеки. Без сканирования образов угроза supply-chain атак реальна.
3. Ошибки в RBAC-конфигурации
   Чрезмерно широкие роли или глобальные ClusterRoleBinding дают пользователям и сервис-аккаунтам права сверх необходимых, нарушая принцип наименьших привилегий.

---

3. Методы защиты​

Теория — это хорошо, но без практики обойтись нельзя. Рассмотрим основные подходы к защите контейнеров и их применение в реальной инфраструктуре.

3.1 Запуск контейнеров от непривилегированного пользователя​

Вместо root создайте в образе специального пользователя. Это базовая мера безопасности: даже в случае прорыва злоумышленник ограничен в правах.

FROM alpine:3.17
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
CMD ["./start.sh"]

В Kubernetes укажите:

securityContext:
  runAsNonRoot: true   # Запрет запуска процессов от root
  runAsUser: 1000      # UID непривилегированного пользователя

3.2 Seccomp, AppArmor и SELinux​

Один из самых эффективных способов предотвратить эскалацию привилегий внутри контейнера — ограничить его системные вызовы и доступ к ресурсам.

• Seccomp (Secure Computing Mode) от ядра Linux блокирует опасные системные вызовы. Например, можно запретить вызовы ptrace (отладка и управление другими процессами), mount (монтирование файловых систем) и другие, которые злоумышленники используют для проникновения и эскалации привилегий.
• AppArmor и SELinux добавляют профили безопасности на уровне приложений: AppArmor проще в настройке и подходит для Ubuntu, SELinux обеспечивает тонкий контроль меток и политик в RHEL-системах.

Пример включения Seccomp в Docker:

docker run --security-opt seccomp=/path/to/profile.json myimage

В Kubernetes

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: "profiles/seccomp_profile.json"

Важной частью обеспечения безопасности являются инструменты автоматизированного тестирования, такие как OWASP ZAP. Рекомендуем пошаговое руководство по запуску OWASP ZAP в Docker и интеграции с API для удобного аудита.

---

4. Политики PodSecurity и RBAC в Kubernetes​

Теория политик безопасности в Kubernetes часто кажется сухой, однако она критична для построения надёжных кластеров. Ниже руководство по внедрению.

4.1 Политики PodSecurity​

Начиная с Kubernetes 1.22, PodSecurity задаёт три уровня доверия для подов, что упрощает контроль:

• Privileged: полные права — только для системных компонентов и доверенных операторов.
• Baseline: блокирует наиболее опасные возможности, такие как privileged, hostNetwork и hostPID.
• Restricted: строгие ограничения — запрещает изменяемый rootfs, нестандартные системные вызовы и привилегированные операции.

apiVersion: policy/v1
kind: PodSecurity
metadata:
  name: enforce-restricted
spec:
  mode: enforce
  enforce:
    level: restricted
  warn:
    level: baseline

4.2 RBAC и принцип наименьших привилегий​

Role- and ClusterRoleBinding позволяют тонко настраивать доступ:

• Role: права в рамках Namespace (например, чтение Pods).
• ClusterRole: глобальные права на уровне всего кластера.
• RoleBinding/ClusterRoleBinding: связывают роли с пользователями и сервис-аккаунтами.

Пример: роль pod-reader разрешает только чтение Pod-ов, что не позволяет пользователю изменять или удалять ресурсы.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
kind: RoleBinding
metadata:
  namespace: dev
  name: read-pods
subjects:
  - kind: User
    name: "developer@example.com"
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Для комплексного подхода к безопасности Kubernetes рекомендую статью: "Матрица угроз для Kubernetes", в которой подробно описываются основные векторы атак, уязвимости и методы их предотвращения.

---

5. Регулярные обновления и сканирование образов​

Поддержка безопасности — это непрерывный процесс, а не разовое мероприятие. Рассмотрим основные практики.

5.1 Обновление компонентов​

• Регулярно обновляйте Docker Engine и Kubernetes компоненты, а также ядро ОС.
• Инструмент kured (KUbernetes REboot Daemon) автоматически перезагружает узлы после обновления ядра, минимизируя ручные действия.

5.2 Сканирование образов в CI/CD​

Интегрируйте сканеры уязвимостей в пайплайн:

• Trivy: быстрое обнаружение CVE в образах.
• Clair: сервис для постоянного мониторинга публичных и приватных реестров.

scan_image:
  image: aquasec/trivy:latest
  script:
    - trivy image --severity HIGH,CRITICAL myregistry/myimage:latest

При обнаружении критических уязвимостей сборка прерывается, и образ не продвигается в staging или prod.

---

6. Сравнение безопасности Docker и Kubernetes​

Понимание различий помогает выбрать правильные инструменты и подходы. Ниже сводная таблица:

Аспект	Docker	Kubernetes
Изоляция	cgroups, namespaces	+ network policies, multi-tenant namespaces
Контроль доступа	Seccomp, user namespaces	RBAC, PodSecurity, OPA Gatekeeper
Политики безопасности	Docker Bench for Security	PodSecurityAdmission, OPA Gatekeeper
Автоматизация	Docker-compose, Swarm	Helm, Operators, CI/CD интеграции
Обновления	Rolling updates	Canary, Blue-Green, Rolling deployments

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

---

Заключение​

Контейнеры позволяют быстро масштабировать приложения, но без внимания к безопасности риски возрастают. Чтобы построить надёжную инфраструктуру:

1. Используйте изоляцию (namespaces, cgroups) как основу.
2. Избегайте root внутри контейнеров и запускайте процессы от непривилегированных пользователей.
3. Внедряйте Seccomp, AppArmor или SELinux для ограничения системных вызовов.
4. Настраивайте PodSecurity и RBAC в Kubernetes по принципу наименьших привилегий.
5. Поддерживайте регулярные обновления компонентов и сканируйте образы в CI/CD.

Только системный подход, объединяющий теорию и практику, позволит создавать безопасные и устойчивые контейнерные среды на базе Docker и Kubernetes.