Kubernetes Security Hardening: от основ до продвинутых техник

Кластеры Kubernetes, будучи основой современной облачной инфраструктуры, часто становятся привлекательной мишенью для атак. Согласно данным от NSA и CISA, Kubernetes обычно атакуют с тремя основными целями: кража данных, использование вычислительных ресурсов (например, для майнинга криптовалюты) и организация DDoS-атак. В этой статье мы разберем комплексный подход к настройке безопасности Kubernetes от простых базовых мер до продвинутых техник защиты.

Уровни безопасности Kubernetes

Прежде чем начать настройку безопасности, важно понимать, что защита Kubernetes должна осуществляться на нескольких уровнях:

1. Безопасность на уровне хоста (Host Level Security)

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

2. Безопасность на уровне кластера (Cluster Level Security)

Этот уровень включает настройку безопасности компонентов управления Kubernetes, API-сервера, etcd и других критических компонентов.

3. Безопасность на уровне рабочих нагрузок (Workload Level Security)

Этот уровень относится к безопасности развертываемых приложений, контейнеров и объектов Kubernetes.

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

Физическая изоляция и сетевая сегментация

Один из важнейших аспектов безопасности — правильная настройка сетевой инфраструктуры. Рекомендуется:

Нет публичным IP: Ноды кластера Kubernetes (как мастер, так и рабочие) не должны иметь прямого внешнего IP-адреса и должны находиться в выделенной сети.
Использование Bastion-хостов: Доступ к кластеру лучше организовать через балансировщик нагрузки или специальные Bastion-ноды с настроенным VPN.

# Пример настройки iptables для защиты kubelet порта
iptables -A INPUT -p tcp --dport 10250 -s 192.168.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 10250 -j DROP

Защита компонентов Control Plane

API-сервер

API-сервер является ядром Kubernetes, и его защита критически важна:

Отключение незащищенных портов: Убедитесь, что API-сервер работает только через HTTPS и не доступен через незащищенные HTTP-порты (8080).
Настройка TLS: Все компоненты управляющей плоскости должны использовать сертификаты TLS для аутентификации и шифрования коммуникаций.

# Проверка настроек API-сервера 
kubectl get pods -n kube-system -l component=kube-apiserver -o jsonpath='{.items[0].spec.containers[0].command}' | grep secure-port

Etcd

Etcd хранит всю информацию о кластере, включая секреты:

Ограничение доступа к etcd: Сервер etcd должен быть сконфигурирован так, чтобы доверять только сертификатам API-серверов.
Шифрование данных: Включите шифрование данных в etcd, особенно для секретов.

# Проверка шифрования в etcd
kubectl get pod -n kube-system -l component=etcd -o jsonpath='{.items[0].spec.containers[0].command}' | grep encryption-provider-config

Kubelet

Kubelet — это агент, работающий на каждой ноде кластера:

Аутентификация и авторизация: Убедитесь, что анонимный доступ отключен, и используется правильный режим авторизации.
Защита портов: Блокируйте доступ к портам kubelet (10250, 10255) извне кластера.

Контроль доступа и авторизация

RBAC (Role-Based Access Control)

RBAC — это механизм, который позволяет ограничить доступ к ресурсам Kubernetes на основе ролей пользователей:

Минимальные привилегии: Создавайте роли с минимально необходимыми правами для выполнения задач.
Отдельные роли для разных команд и систем: Не используйте общие учетные записи для разных команд или систем.

# Пример RBAC роли с минимальными правами для чтения подов
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: 
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
# Привязка роли к пользователю
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

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

Сетевые политики позволяют контролировать трафик между подами в кластере:

Изоляция по умолчанию: Устанавливайте политику запрета всего трафика по умолчанию, а затем добавляйте исключения.

# Пример сетевой политики, запрещающей весь входящий трафик для пространства имен
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

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

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

Непривилегированные контейнеры

Запуск контейнеров от имени root увеличивает риск компрометации:

Непривилегированные пользователи: Создавайте контейнеры с непривилегированными пользователями.

FROM alpine:3.12
# Создание пользователя и установка прав
RUN adduser -D myuser && chown -R myuser /myapp-data
COPY myapp /myapp
USER myuser
ENTRYPOINT ["/myapp"]

SecurityContext в Pod: Используйте SecurityContext для установки дополнительных ограничений.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: myapp
    image: myapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

Сканирование образов на уязвимости

Регулярное сканирование контейнеров на уязвимости — критически важная практика:

Интеграция в CI/CD: Добавьте сканирование в конвейер CI/CD и блокируйте развертывание уязвимых образов.
Использование инструментов сканирования: Trivy, Clair, Anchore и другие инструменты могут сканировать образы на известные уязвимости.

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

Pod Security Standards

Pod Security Standards (ранее известные как Pod Security Policies) позволяют устанавливать правила безопасности для подов:

Baseline/Restricted профили: Используйте built-in профили безопасности подов для обеспечения минимальных стандартов безопасности.

# Пример применения Pod Security Standards
apiVersion: v1
kind: Namespace
metadata:
  name: restricted-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Защита секретов

Секреты в Kubernetes по умолчанию хранятся в незашифрованном виде в etcd:

Шифрование данных в покое: Настройте шифрование секретов в etcd.

# Пример конфигурации для шифрования секретов
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: 
    - identity: {}

Хранение секретов вне Kubernetes: Рассмотрите использование внешних систем управления секретами, таких как HashiCorp Vault.

Аудит и мониторинг

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

Включение аудита в Kubernetes: Настройте аудит API-операций для мониторинга подозрительной активности.

# Пример конфигурации аудита
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["pods"]
  omitStages:
  - "RequestReceived"
- level: Request
  verbs: ["create", "update", "patch", "delete"]
  resources:
  - group: ""
    resources: ["secrets", "configmaps", "serviceaccounts"]

Ротация ключей и сертификатов: Регулярно обновляйте ключи шифрования и сертификаты для минимизации последствий в случае компрометации.

CIS Kubernetes Benchmark

Center for Internet Security (CIS) предоставляет набор рекомендаций по настройке безопасности Kubernetes:

Использование инструментов для проверки CIS: Используйте инструменты вроде kube-bench для проверки соответствия рекомендациям CIS.

# Запуск kube-bench для проверки соответствия CIS
kubectl run kube-bench --image=aquasec/kube-bench:latest \
  --restart=Never -it --rm -- --version 1.24

Автоматическое применение рекомендаций: В MicroK8s v1.28+ доступен addon cis-hardening для автоматического применения рекомендаций CIS.

# Для MicroK8s
microk8s enable cis-hardening

Руководство NSA по защите Kubernetes

Агентство национальной безопасности США (NSA) в сотрудничестве с CISA выпустило руководство по защите Kubernetes, которое содержит рекомендации в нескольких ключевых областях:

Сканирование контейнеров и подов на уязвимости и неправильные конфигурации.
Минимизация привилегий везде, где это возможно, особенно для контейнеров.
Сетевое разделение и укрепление для ограничения потенциального ущерба при компрометации.
Строгая аутентификация и авторизация для всех компонентов.
Аудит и логирование для обнаружения и анализа подозрительной активности.

# Пример настройки hardened ОС для нод кластера
# Используйте одну из рекомендованных ОС:
# - CoreOS
# - Google Container Optimized OS
# - Fedora Atomic Host

Практические рекомендации

Регулярное обновление Kubernetes: Поддерживайте ваш кластер в актуальном состоянии, чтобы устранять обнаруженные уязвимости.
Liveness, Readiness, Startup пробы: Правильно настроенные пробы помогают поддерживать стабильность и быстро реагировать на проблемы.

# Пример настройки liveness пробы
apiVersion: v1
kind: Pod
metadata:
  name: app-with-probes
spec:
  containers:
  - name: myapp
    image: myapp:1.0
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

Валидирующие admission webhooks: Используйте admission webhooks для проверки ресурсов перед их созданием в кластере.
Immutable файловая система: По возможности используйте контейнеры с неизменяемой файловой системой для предотвращения внесения изменений во время выполнения.

Топ инструментов для обеспечения безопасности Kubernetes

Для поддержки безопасности Kubernetes-кластеров существует целый арсенал специализированных инструментов. Вот ключевые решения, которые стоит внедрить в ваш workflow:

1. Trivy

Для чего: Сканирование образов контейнеров на уязвимости, мисконфиги и секреты в YAML-файлах.
Фишка: Интеграция в CI/CD с автоматической блокировкой уязвимых образов.
Пример использования:

trivy image --severity CRITICAL myapp:1.0

2. Falco

Для чего: Система runtime-мониторинга для обнаружения аномалий в реальном времени.
Фишка: eBPF-фильтры для отслеживания подозрительных системных вызовов (например, несанкционированный доступ к файлам).
Кейс: Обнаружение попыток эскалации привилегий в подах.

3. Kube-bench

Для чего: Проверка соответствия кластера стандартам CIS Kubernetes Benchmark.
Фишка: Автоматизированные тесты для control plane и worker nodes.
Запуск:

kube-bench --benchmark cis-1.24

4. Kube-hunter

Для чего: Penetration testing кластера с имитацией атак.
Фишка: Обнаружение открытых портов API-сервера и уязвимостей в network policies.
Сценарий: Тестирование безопасности публичных Kubernetes API[10].

5. Kubescape

Для чего: Комплексный аудит безопасности по стандартам NSA и MITRE ATT&CK.
Фишка: Визуализация attack vectors и автоматическая генерация сетевых политик.
Интеграция: Проверка Helm-чартов перед деплоем.

KubeLinter: Must-Have для профилактики мисконфигов

Для чего: Статический анализ YAML-манифестов и Helm-чартов.
Фишки:

19+ встроенных проверок (привилегированные контейнеры, root-пользователи)
Кастомизация правил через конфиг-файлы
Интеграция в pre-commit хуки и CI/CD

Пример использования:

kube-linter lint my-deployment.yaml --add-all-built-in

Что ловит:

Отсутствие liveness-проб
Незашифрованные секреты в etcd
Контейнеры с readOnlyRootFilesystem: false

Важно: KubeLinter предотвращает 67% инцидентов, вызванных человеческим фактором, проверяя конфиги ещё до деплоя.

Заключение

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

Kubernetes Security Hardening: от основ до продвинутых техник защиты