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

Question

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

Тип вопроса: Kubernetes Вероятность: 23% Категория: Devops Инженер

Ответ

Etcd хранит состояние всего кластера Kubernetes, поэтому его безопасность критически важна. В production-среде я настраиваю многоуровневую защиту:

1. Шифрование трафика (TLS): Все коммуникации с etcd должны использовать TLS. В конфигурации etcd (часто в /etc/kubernetes/manifests/etcd.yaml) указываю:

   - --client-cert-auth=true
   - --cert-file=/etc/kubernetes/pki/etcd/server.crt
   - --key-file=/etc/kubernetes/pki/etcd/server.key
   - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
   - --peer-client-cert-auth=true
   - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
   - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
   - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

2. Сетевая изоляция:

Размещаю etcd-поды/ноды в отдельной, изолированной подсети.
Настраиваю сетевые политики (Network Policies) или security groups в облаке, чтобы разрешать входящий трафик только с control-plane нод Kubernetes на порты 2379 (клиентский) и 2380 (пиринговый).

3. Регулярное резервное копирование: Автоматизирую создание снапшотов с помощью etcdctl и храню их в защищенном объектном хранилище (например, S3 с шифрованием).

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 
   --cacert=/etc/kubernetes/pki/etcd/ca.crt 
   --cert=/etc/kubernetes/pki/etcd/server.crt 
   --key=/etc/kubernetes/pki/etcd/server.key 
   snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

4. RBAC и аутентификация: Использую встроенную в etcd RBAC-систему для тонкого управления доступом, если к кластеру etcd имеют доступ приложения помимо Kubernetes API-сервера.

5. Мониторинг и аудит: Настраиваю сбор метрик etcd (например, через Prometheus) и алерты на высокую задержку запросов, рост размера базы или частые перевыборы лидера. Включаю аудит логов (--log-level=debug для отладки).

6. Выделенные ресурсы и обновления: Запускаю etcd на выделенных нодах с гарантированными ресурсами (CPU, RAM, низколатентный SSD). Регулярно планирую обновления etcd в рамках жизненного цикла кластера, следуя официальной документации Kubernetes.

Ответ 18+ 🔞

Слушай, а давай про etcd поговорим? Эта штука — ебать мои старые костыли — самый главный свидетель в твоём кластере. Вся подноготная, все секретики, кто каким подом управляет — всё лежит там. Если эту базу упрут или накроют, твой Kubernetes превратится в тыкву, причём моментально. Поэтому тут доверия ебать ноль, только паранойя и многоуровневая оборона.

1. Шифрование (TLS): Первое и самое очевидное — чтобы все разговоры с etcd были под замком. Это не тот случай, где можно сказать «да похуй». В его конфиге (часто это /etc/kubernetes/manifests/etcd.yaml) надо впендюрить кучу ключей и сертификатов, чтобы любой чих был зашифрован.

   - --client-cert-auth=true
   - --cert-file=/etc/kubernetes/pki/etcd/server.crt
   - --key-file=/etc/kubernetes/pki/etcd/server.key
   - --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
   - --peer-client-cert-auth=true
   - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
   - --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
   - --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

Без этого — ты просто вывешивашь состояние всего кластера на всеобщее обозрение, как будто на дворе 2002-й год.

2. Сетевая изоляция: Это хитрая жопа. Нельзя, чтобы etcd болтался в общей сети. Сажаешь его либо на отдельные ноды, либо в такую подсеть, куда могут зайти только control-plane ноды твоего куба. Настраиваешь политики или security groups, чтобы на порты 2379 и 2380 стучались только свои. Если откроешь это всё миру — считай, пригласил гомосеков налететь на твои данные.

3. Резервное копирование: Вот тут без вариантов — снапшоты делать надо регулярно, иначе в один прекрасный день сам от себя охуеешь. Автоматизируешь этот цирк через etcdctl и скидываешь бекапы в защищённое хранилище.

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 
   --cacert=/etc/kubernetes/pki/etcd/ca.crt 
   --cert=/etc/kubernetes/pki/etcd/server.crt 
   --key=/etc/kubernetes/pki/etcd/server.key 
   snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

Если этого не делать, а база вдруг накроется медным тазом — восстанавливать будет нечего, и тебе останется только материться и разворачивать всё с нуля.

4. RBAC и доступ: В самой etcd есть своя система ролей и прав. Если кроме Kubernetes API-сервера к ней кто-то ещё лезет (что само по себе подозрение ебать чувствую), надо настроить эти политики дотошно. Чтобы каждый левый скрипт не мог всё прочитать и поменять.

5. Мониторинг и аудит: За этой сукой нужно следить в оба. Настраиваешь Prometheus на сбор её метрик: задержки запросов, размер базы, как часто выбирается новый лидер. Если что-то пошло не так — алерты должны прилететь сразу. Логи аудита тоже включаешь, чтобы если что — было что посмотреть. Без этого ты летишь вслепую.

6. Ресурсы и обновления: И последнее — etcd жрёт ресурсы, как не в себя, особенно если кластер большой. Запускать её нужно на мощных нодах с быстрыми SSD, иначе производительность будет пиздец. И да, обновлять её тоже нужно по графику, не откладывая в долгий ящик. Запустил и забыл — это верный путь к тому, чтобы всё ебанько развалилось в самый неподходящий момент.

В общем, относишься к etcd как к самой ценной вещи в кластере. Потому что так оно и есть.