Легко решить, что при работе с контейнерами безопасность хоста перестаёт иметь значение. На деле всё ровно наоборот: каждый узел Kubernetes — это машина, которая загружается из образа, и взлом хоста компрометирует все размещённые на нём поды. Поэтому AMI узла — критически важный элемент безопасности.
У вас три пути: использовать официальные оптимизированные AMI как есть, взять их за основу и доработать или собрать собственный. Для серьёзной эксплуатации рекомендуется дорабатывать или собирать на усиленной базе.
Что должен содержать хороший AMI узла
- Оптимизированную базу под контейнерный рантайм, с корректно настроенными containerd и kubelet.
- Усиление по CIS операционной системы и, где применимо, по самому CIS Benchmark for Kubernetes.
- Актуальные патчи ядра и компонентов с регулярной пересборкой.
- Нужные агенты — логи, метрики, безопасность — предустановленные для быстрого старта.
- Никаких вшитых секретов и учётных данных; идентификация через IAM Roles for Service Accounts (IRSA) или аналог.
- Минимальную конфигурацию: уберите пакеты и службы, которые узлу не нужны.
Варианты образов для EKS
| Вариант | Преимущество | Когда выбирать |
|---|---|---|
| Оптимизированный AMI EKS (AL2023) | Официальный, поддерживается AWS | Универсальная отправная точка |
| Bottlerocket | Минимальная ОС под контейнеры, неизменяемая | Максимум безопасности, минимум поверхности |
| Собственный AMI | Полный контроль над усилением и агентами | Строгие требования соответствия |
Выбирайте базу узла исходя из баланса между контролем и удобством.
Bottlerocket: контейнеры прежде всего
Bottlerocket — минималистичная операционная система AWS, созданная исключительно для запуска контейнеров. Поверхность атаки крошечная, система неизменяемая и обновляется образом, а не «горячим» патчем, что прекрасно ложится на философию неизменяемой инфраструктуры. Если ваш приоритет — безопасность узла при минимуме обслуживания, её стоит серьёзно рассмотреть.
Обновлять узлы без боли
Усиленный AMI узла полезен только тогда, когда узлы поддерживаются в актуальном состоянии. Здесь неизменяемый подход раскрывается полностью:
- Заменяйте, а не патчите: публикуйте новую версию AMI и ротируйте узлы.
- Rolling update группы узлов: выводите из работы через cordon и drain и заменяйте узел за узлом.
- Managed Node Groups или Karpenter для автоматизации замены на новые AMI.
- PodDisruptionBudgets, чтобы ротация не била по доступности сервисов.
Частые ошибки
- Месяцами использовать оптимизированный AMI по умолчанию, не обновляя его.
- Вшивать учётные данные кластера в образ вместо федеративной идентификации.
- Забывать про усиление самого kubelet и прав файловой системы.
- Не ограничивать доступ по SSH к узлам: в идеале — никакого SSH, только SSM.
Часто задаваемые вопросы
Нужен ли собственный AMI или хватит оптимизированного для EKS?
Для старта официальный оптимизированный AMI — хорошая точка отсчёта. При строгих требованиях к безопасности или соответствию доработайте его или соберите свой с собственным усилением и агентами.
Заменяет ли Bottlerocket обычный Linux-AMI?
Для узлов, которые запускают только контейнеры, да: меньше поверхность атаки и неизменяемые обновления. Для нагрузок, которым нужна ОС общего назначения, он не подходит.
Как обновлять узлы при выпуске нового AMI?
Через rolling update группы узлов: их постепенно выводят из работы и заменяют, соблюдая PodDisruptionBudgets, чтобы сервис не пострадал.
В imaxe.cloud мы проектируем усиленные базовые образы, идеально подходящие в качестве фундамента для ваших узлов Kubernetes.
