Статья по безопасности Kubernetes (Kubernetes Security Cheat Sheet)

Обзор

Эта Статья — отправная точка для защиты кластера Kubernetes. Структура:

• Уведомления об обновлениях Kubernetes
• Введение: что такое Kubernetes
• Защита хостов Kubernetes
• Защита компонентов Kubernetes
• Использование веб-интерфейса (Dashboard)
• Практики безопасности: этап сборки (Build)
• Практики безопасности: этап развёртывания (Deploy)
• Практики безопасности: этап эксплуатации (Runtime)

Дополнительные материалы по Kubernetes — в разделе «Ссылки» в конце.

Уведомления об обновлениях безопасности и сообщение об уязвимостях

Подпишитесь на рассылку kubernetes-announce и следуйте официальной странице безопасности Kubernetes для отчётов об уязвимостях.

Введение: что такое Kubernetes?

Kubernetes — открытая система оркестрации контейнеров для автоматизации развёртывания, масштабирования и управления приложениями в контейнерах. Проект входит в CNCF.

После развёртывания вы получаете кластер: набор рабочих узлов (nodes), на которых выполняются поды с контейнерами, и control plane, управляющий узлами и подами.

Компоненты control plane

Компоненты плоскости управления принимают глобальные решения по кластеру и реагируют на события: kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager.

kube-apiserver — публикует Kubernetes API; точка входа в control plane.

etcd — согласованное высокодоступное key-value хранилище; бэкенд данных кластера.

kube-scheduler — назначает узел новым подам без привязки к ноде.

kube-controller-manager — процессы контроллеров (в одном бинарнике для упрощения).

cloud-controller-manager — связывает кластер с API облачного провайдера, отделяя облачную интеграцию от остальной логики.

Компоненты узла

На каждом узле: kubelet (агент, следит за контейнерами в подах), kube-proxy (сетевой прокси для сервисов), container runtime (запуск контейнеров).

Раздел 1. Защита хостов Kubernetes

Kubernetes разворачивают на «железе», on-prem и в облаке (свой кластер на ВМ или managed-сервис). Гибкость повышает поверхность атаки — команда должна понимать векторы угроз для своей модели.

Рекомендации по хостам: актуальная ОС, укрепление (hardening), патч- и конфигурационный менеджмент, фаервол, меры безопасности ЦОД/облака.

Обновление Kubernetes

Лучшая базовая защита — стабильная актуальная версия Kubernetes. При уязвимостях в образах обновляйте исходный образ и пересоздавайте контейнеры; избегайте правок «на лету» внутри работающих контейнеров, чтобы не ломать связь образ–контейнер.

# Пример обновления пакетов на узле (иллюстрация)
apt-get update

Rolling updates Kubernetes позволяют постепенно обновлять приложение, подменяя образы на новые версии.

График релизов

Проект поддерживает ветки для трёх последних минорных релизов и бэкпортит исправления безопасности. Держите кластер на последней стабильной версии; см. политику версионного сдвига. Используйте rolling update, миграции node pool и т.п., чтобы снизить простой.

Раздел 2. Защита компонентов Kubernetes

• Безопасность Dashboard
• Ограничение доступа к etcd
• Сетевой доступ к чувствительным портам
• Доступ к Kubernetes API
• RBAC
• Ограничение доступа к Kubelet

Безопасность Kubernetes Dashboard

Dashboard — отдельное веб-приложение; часто в туториалах создают service account с чрезмерными правами. Из-за публично доступного Dashboard пострадали в том числе Tesla (Ars Technica).

• Не выставляйте Dashboard в интернет без дополнительной аутентификации.
• Включите RBAC и ограничьте права service account Dashboard.
• Выдавайте права по пользователям, принцип наименьших привилегий.
• Сетевые политики могут блокировать доступ к Dashboard из подов (не мешает kubectl proxy).
• До версии 1.8 у Dashboard был широкий доступ — проверьте отсутствие привязок роли cluster-admin.
• Развёртывайте Dashboard за reverse proxy с MFA и OIDC / impersonation вместо привилегированного ServiceAccount.

Ограничение доступа к etcd (важно)

etcd хранит состояние и секреты. Запись в etcd API-сервера эквивалентна root в кластере; даже чтение часто позволяет эскалировать привилегии. Планировщик читает etcd; прямой обход API-сервера ломает политики вроде PodSecurityPolicies.

Используйте сильную аутентификацию между apiserver и etcd (например, mTLS), изолируйте etcd за фаерволом, доступ только с API-серверов.

Доступ к основному etcd

Доступ других компонентов кластера к полному keyspace основного etcd сопоставим с cluster-admin. Разделяйте экземпляры etcd или применяйте ACL по подмножеству ключей.

Сетевой доступ к чувствительным портам

Включайте аутентификацию и авторизацию; кластеры слушают характерные порты — их проще найти атакующим. Ограничьте доступ; API-сервер по возможности только из доверенных сетей.

Control plane:

Рабочие узлы:

Доступ к Kubernetes API

Первая линия защиты — ограничение и защита запросов к API. См. документацию.

Как устроена авторизация

Сначала аутентификация, затем авторизация. По умолчанию запросы запрещены, пока политика явно не разрешит все части запроса.

Внешняя аутентификация API (рекомендуется)

Для продакшена предпочтительны внешние механизмы: OpenID Connect, IAM в GKE/EKS/AKS, Impersonation. Для привилегированного доступа к API используйте MFA.

Подробнее: Authentication.

Встроенная аутентификация API (не рекомендуется для продакшена)

• Static Token File — токены в CSV; смена без перезапуска apiserver невозможна.
• X509 client certs — слабое отзывание (issue).
• Service account tokens — в основном для подов; как учётные записи пользователей — осторожно.

RBAC в Kubernetes

RBAC сопоставляет пользователей/группы с ролями (глаголы + ресурсы, область namespace или кластер). Включайте Node и RBAC authorizers вместе с admission plugin NodeRestriction.

Пример флага apiserver:

kube-apiserver --authorization-mode=Example,RBAC --other-options ...

Детали: RBAC.

Ограничение доступа к Kubelet

Kubelet предоставляет мощный HTTPS API. По умолчанию возможен неаутентифицированный доступ — в продакшене включайте аутентификацию и авторизацию: Kubelet authn/authz.

Раздел 3. Практики безопасности: этап сборки (Build)

На этапе сборки закрепляйте безопасные образы и сканируйте их на уязвимости.

Что такое образ контейнера

Образ — неизменяемый пакет с кодом, рантаймом, библиотеками и конфигурацией. Собирайте на утверждённой базе, сканируйте базу и производные образы, храните артефакты в доверенных реестрах.

Актуальность образов

Обновляйте собственные и сторонние компоненты в образах.

Только разрешённые образы

Запуск образов из неизвестных источников опасен. Разрешайте только образы, соответствующие политике организации.

CI/CD и сканирование

Используйте приватный реестр одобренных образов; в пайплайн встройте SAST/сканирование уязвимостей (например Trivy, Grype). Блокируйте публикацию при находках. См. также CI/CD Security Cheat Sheet и обсуждение плагинов авторизации образов.

Минимизация содержимого образов

Уменьшайте поверхность атаки: по возможности distroless или scratch для статически слинкованных бинарников. Не включайте пакетные менеджеры и shell без необходимости. distroless, scratch.

Distroless и пустые образы

Distroless снижает набор пакетов и отсутствие shell; scratch — минимальная база для Go и подобных случаев.

Раздел 4. Практики безопасности: этап развёртывания (Deploy)

До выката нагрузок настройте инфраструктуру и обеспечьте наблюдаемость: что деплоится, куда, как (привилегии, сеть, securityContext), к чему есть доступ (секреты, тома, API), соответствие политикам.

Пространства имён (namespaces)

Namespaces дают логическое разделение и границы для RBAC.

Флаг namespace

kubectl run nginx --image=nginx --namespace=<имя-ns>
kubectl get pods --namespace=<имя-ns>

Контекст по умолчанию

kubectl config set-context --current --namespace=<имя-ns>
kubectl config view --minify | grep namespace:

Документация по namespaces.

ImagePolicyWebhook

Admission controller ImagePolicyWebhook отклоняет поды с неодобренными образами (несканированные, неразрешённая база, небезопасный реестр). Документация.

Непрерывное сканирование уязвимостей

Регулярно сканируйте перво- и сторонние образы в продакшене. Инструменты: ThreatMapper и др.

Security context подов и контейнеров

Задавайте в манифестах: runAsNonRoot, capabilities, readOnlyRootFilesystem, podSecurityContext и т.д.

Пример Pod

apiVersion: v1
kind: Pod
metadata:
  name: hello-world
spec:
  containers:
  # ...
  securityContext:
    readOnlyRootFilesystem: true
    runAsNonRoot: true

Security context.

Pod Security Standards и Pod Security admission

Профили: Privileged, Baseline, Restricted — см. детали. Режимы admission: enforce, audit, warn.

Пример namespace с уровнем restricted:

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Для тонкой настройки — OPA Gatekeeper, Kyverno, Validating Admission Policy (GA с 1.30).

Pod Security Policies (устарело)

Внимание. PSP удалены в Kubernetes 1.25. Используйте Pod Security Standards и Pod Security admission.

Типовые требования к политикам: не root, запрет privilege escalation, read-only root FS, маскированный /proc, не использовать hostNetwork: true без необходимости (NetworkPolicies не применяются к host network), урезать capabilities, SELinux, отдельный ServiceAccount на приложение, не монтировать credentials API, если они не нужны. Историческая документация PSP.

Service mesh

Mesh даёт наблюдаемость, mTLS между сервисами, контроль ingress/egress, единые политики и RBAC на уровне mesh; но добавляет сложность, требует экспертизы и может замедлять внедрение. Оценивайте TCO и риски.

Централизованные политики

OPA, Kyverno, Validating Admission Policy — единая точка для admission и (частично) для приложений и mesh.

Квоты ресурсов

По умолчанию лимиты CPU/памяти не заданы — риск DoS и «шумных соседей». Используйте ResourceQuota.

Пример compute-resources.yaml:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4"
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

kubectl create -f ./compute-resources.yaml --namespace=myspace

Сетевые политики

По умолчанию поды могут общаться друг с другом и выходить наружу — сегментируйте трафик NetworkPolicy. В оригинале приведён пример JSON для раннего API; в актуальных версиях используйте манифесты NetworkPolicy с podSelector и ingress/egress.

Защита данных

Секреты

Монтируйте секреты в read-only тома, по возможности не через переменные окружения. Не смешивайте секреты с образами. См. Secrets Management Cheat Sheet и документацию Secret.

Шифрование секретов в покое

etcd содержит всё, доступное через API — шифруйте бэкапы и используйте encryption at rest для Secret в etcd.

Внешние хранилища секретов

Рассмотрите внешний secret manager для ротации и кросс-кластерных сценариев.

Поиск утечек

Сканируйте ФС образов: SecretScanner, ThreatMapper.

Раздел 5. Практики безопасности: этап эксплуатации (Runtime)

В runtime контролируйте процессы, сеть и аномалии; чем лучше build/deploy, тем меньше инцидентов в продакшене.

Pod Security admission

PSP заменены на Pod Security admission. Минимум — профиль baseline; цель — restricted. Настройка.

Безопасность рантайма контейнеров

Мониторинг syscalls (например Falco): shell в контейнере, монтирование чувствительных путей хоста, чтение /etc/shadow, неожиданные исходящие соединения.

Песочницы

• Kata Containers — лёгкие ВМ для изоляции.
• gVisor — userspace-ядро между контейнером и хостом.
• Firecracker — минимальные ВМ с жёсткой поверхностью syscalls.

Загрузка модулей ядра

Заблокируйте ненужные модули (пример /etc/modprobe.d/kubernetes-blacklist.conf):

# DCCP — редко нужен, были уязвимости
blacklist dccp
# SCTP — часто не нужен в K8s
blacklist sctp

SELinux и др. LSM могут запретить module_request из контейнеров.

Сравнение поведения реплик

Реплики одного Deployment должны вести себя схоже; отклонения — сигнал для расследования. Интегрируйте алерты со Slack/PagerDuty/SIEM.

Мониторинг сети

Сравнивайте фактический трафик с NetworkPolicy; сужайте разрешённое. Инструменты: Inspektor Gadget, PacketStreamer.

При компрометации

Масштабируйте подозрительные поды в ноль или перезапускайте приложения средствами Kubernetes.

Ротация учётных данных

Короткий срок жизни сертификатов и токенов, автоматическая ротация, отзыв bootstrap-токенов после инициализации узлов.

Логирование

Собирайте stdout/stderr (Fluentd/Fluent Bit → Elasticsearch/OpenSearch и т.д.).

Audit API

Включите аудит apiserver и храните логи на защищённом сервере; отслеживайте ответы Forbidden. Уровни: None, Metadata, Request, RequestResponse. Флаг --audit-policy-file.

Пример записи аудита (фрагмент)

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1beta1",
  "level": "Metadata",
  "verb": "list",
  "user": { "username": "user@example.org" },
  "requestURI": "/api/v1/namespaces/default/persistentvolumeclaims"
}

Логи контейнера

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: example
      image: busybox
      args: [/bin/sh, -c, 'while true; do echo $(date); sleep 1; done']

kubectl apply -f example.yaml
kubectl logs <container-name>

Логи узла

Логи контейнеров часто в /var/log/containers; ротация на узле. Для systemd: journalctl -u ….

Логи кластера

Собирайте логи компонентов control plane и события кластера.

События

kubectl get events -n <namespace>
kubectl describe pod <pod-name>

Раздел 6. Управляемый Kubernetes у облачного провайдера

Для AWS EKS полезны инструменты вроде hardeneks и MKAD (DataDog).

Раздел 7. Безопасность цепочки поставки

Защищайте базовые образы, CI/CD, реестры, Helm-манифесты и зависимости. Примеры инцидентов: SolarWinds, Codecov и др.

Практики

1. Доверенные минимальные базовые образы.
2. Сканирование образов (Clair, Trivy, Aqua и др.).
3. Защита пайплайнов и контроль доступа.
4. Подпись и верификация образов (Notary, Cosign).
5. Приватные реестры с ACL.
6. Мониторинг новых CVE в зависимостях.
7. Runtime-наблюдение и детекция аномалий.

Раздел 8. Итоги

Встройте безопасность рано

Согласуйте цели Security и DevOps; безопасность должна помогать выкатывать готовые к продакшену сервисы.

Нативные механизмы Kubernetes

По возможности используйте встроенные NetworkPolicy, RBAC, admission — меньше конфликтов с оркестратором, чем у «прокладок» поверх.

Контекст для приоритизации

Уязвимость с CVSS ≥ 7 в привилегированном поде с выходом в интернет важнее, чем та же в тестовом окружении.

Ссылки

• kubernetes.io — документация control plane
• Securing a Cluster
• Security Checklist
• 11 Ways (Not) to Get Hacked
• CNCF: 9 security best practices
• Docker Security Cheat Sheet