Как обезопасить etcd в Kubernetes

Защита etcd в Kubernetes: Комплексный подход

Etcd — это сердце Kubernetes, хранящее состояние всего кластера (поды, сервисы, секреты, конфигурации). Его компрометация ведет к полному контролю над кластером. Защита etcd — многоуровневая задача, требующая комбинации мер на сетевом, транспортном, аутентификационном и процедурном уровнях. Я разделю рекомендации на ключевые категории.

1. Сетевая изоляция и контроль доступа

Первая линия обороны — минимизация точек входа к etcd.

• Разделение сетей: Размещайте etcd-кластер в отдельной, строго контролируемой подсети (management network), недоступной напрямую из интернета и из рабочих нагрузок (Pods).
• Брандмауэрные правила: Настройте брандмауэр (например, с помощью iptables, nftables или облачных Security Groups) так, чтобы порты etcd (по умолчанию 2379 для клиентского доступа, 2380 для пиринга) были доступны только:

    *   Control Plane компонентам (kube-apiserver) с их конкретных IP-адресов.
    *   Другим членам etcd-кластера для пиринга.
    *   Административным jump-хостам для управления.

• Пример iptables для ограничения доступа к порту 2379:

  # Разрешить доступ только с IP kube-apiserver (например, 10.0.1.10) и других etcd-нод
  iptables -A INPUT -p tcp --dport 2379 -s 10.0.1.10 -j ACCEPT
  iptables -A INPUT -p tcp --dport 2379 -s 10.0.1.11 -j ACCEPT  # другая etcd-нода
  iptables -A INPUT -p tcp --dport 2379 -s 10.0.1.12 -j ACCEPT  # и еще одна
  iptables -A INPUT -p tcp --dport 2379 -j DROP
  

2. Шифрование транспорта (TLS)

Обязательное использование TLS для аутентификации и шифрования всего трафика.

• Сертификаты клиент/сервер: Настройте etcd на использование отдельных сертификатов для сервера и каждого клиента (kube-apiserver, etcdctl). Отключайте небезопасные протоколы.
• Типичные флаги запуска etcd:

  # В манифесте systemd или в аргументах контейнера
  --client-cert-auth=true
  --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
  --cert-file=/etc/kubernetes/pki/etcd/server.crt
  --key-file=/etc/kubernetes/pki/etcd/server.key
  --peer-client-cert-auth=true
  --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
  --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
  --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
  

• Автоматическая ротация сертификатов: Используйте kubeadm с флагом --feature-gates=RotateKubeletServerCertificate=true или такие инструменты, как cert-manager, для автоматического обновления сертификатов до их истечения.

3. Аутентификация и авторизация (RBAC для etcd)

Etcd имеет собственную, довольно простую систему RBAC.

• Включение RBAC: Запустите etcd с флагом --auth-enabled (в версиях v3) и создайте пользователей/роли.
• Минимальные привилегии для kube-apiserver: Создайте отдельного пользователя для apiserver с правами только на префиксы, которые он использует (обычно /registry).

  # Пример настройки через etcdctl
  etcdctl --cacert=ca.crt --cert=client.crt --key=client.key user add kube-apiserver
  etcdctl --cacert=ca.crt --cert=client.crt --key=client.key role add kube-apiserver-role
  etcdctl --cacert=ca.crt --cert=client.crt --key=client.key role grant-permission kube-apiserver-role --prefix=true readwrite /registry
  etcdctl --cacert=ca.crt --cert=client.crt --key=client.key user grant-role kube-apiserver kube-apiserver-role
  

• Регулярный аудит ролей и пользователей.

4. Шифрование данных на отдыхе (Encryption at Rest)

Даже при получении доступа к дискам, данные должны оставаться нечитаемыми.

• Шифрование дисков (OS/Infrastructure level): Используйте LUKS (Linux), BitLocker (Windows) или зашифрованные тома облачного провайдера (AWS EBS Encryption, GCP PD Encryption).
• Шифрование на уровне Kubernetes (Kubernetes Secrets): Включите Kubernetes Data Encryption Configuration (EncryptionConfiguration) для прозрачного шифрования ресурсов (в первую очередь Secrets) перед их записью в etcd. Это критически важно, так как секреты часто хранятся в открытом виде по умолчанию.

  # /etc/kubernetes/encryption-config.yaml
  apiVersion: apiserver.config.k8s.io/v1
  kind: EncryptionConfiguration
  resources:
    - resources:
        - secrets
      providers:
        - aescbc:
            keys:
              - name: key1
                secret: <base64-encoded-32-byte-key> # Генерируем, например, head -c 32 /dev/urandom | base64
        - identity: {} # Резервный провайдер для чтения старых данных
  

    Настройте kube-apiserver с флагом `--encryption-provider-config`.

5. Безопасность окружения и операционные практики

• Регулярное обновление: Своевременно применяйте патчи безопасности для etcd и ОС.
• Бег etcd от непривилегированного пользователя: Не запускайте etcd от root.
• Логирование и мониторинг (Audit Logging): Включите и настройте аудит etcd (--audit-log-path, --audit-policy-file). Мониторьте логи на предмет подозрительных запросов (частые операции записи, доступ с неизвестных IP).
• Регулярные бэкапы: Это не опция, а обязанность. Регулярно создавайте и тестируйте снапшоты etcd. Храните их зашифрованными и отдельно от кластера.

  etcdctl --cacert=ca.crt --cert=client.crt --key=client.key snapshot save /var/backups/etcd-snapshot-$(date +%Y%m%d).db
  

• Избегание размещения на Master-нодах в продакшене: В высоконагруженных или строгих средах выделяйте отдельный набор нод для etcd, чтобы изолировать его от нагрузки и рисков, связанных с apiserver, scheduler и controller-manager.
• Использование внешнего etcd: Для повышения отказоустойчивости и изоляции используйте внешний управляемый кластер etcd (например, от облачного провайдера) или развернутый независимо от Kubernetes.

Заключение

Безопасность etcd — это не единовременная настройка, а непрерывный процесс. Начните с TLS, сетевой изоляции и бэкапов — это базовый минимум. Затем внедрите RBAC и шифрование данных на отдыхе для защиты от внутренних угроз и компрометации носителей. Завершите картину мониторингом, аудитом и строгими операционными процедурами. Регулярно проводите пентесты и аудиты конфигурации, используя такие инструменты, как kube-bench (для проверки соответствия CIS Benchmark), чтобы убедиться, что ваша защита остается актуальной и эффективной.