Kubernetes в проде: чек-лист безопасности для новичков без экспертизы

Контейнеры и Kubernetes уже стали стандартом для современных разработок, но безопасность часто остаётся на втором плане. Если ваша система уже работает в production, но вы не профессионал в области информационной безопасности, этот чек-лист поможет вам закрыть критические пробелы и защитить инфраструктуру от основных угроз. Речь идёт не о паранойе, а о практических мерах, которые реально спасают от взломов и утечек данных.

Сканирование образов: первая линия защиты

Большинство уязвимостей попадают в production именно через образы контейнеров. Это происходит потому, что разработчики часто не проверяют зависимости перед развёртыванием. Сканирование образов должно быть автоматизированным процессом в вашем CI/CD pipeline. Существует несколько инструментов для сканирования: Trivy, Clair и Grype. Они проверяют образ на известные уязвимости в библиотеках и системных пакетах. Рекомендуется запускать сканирование на этапе сборки, как часть интеграционных тестов. Если уязвимости обнаружены, процесс развёртывания должен остановиться. Важный момент: сканирование нужно проводить не только при создании образа, но и регулярно переиндексировать уже развёрнутые контейнеры. Уязвимости открываются постоянно, и образ, безопасный месяц назад, может оказаться опасным сегодня. Также стоит проверять сами Dockerfile-файлы на ошибки безопасности. Для этого используются инструменты вроде Hadolint и Kics. Они выявляют типичные проблемы: запуск контейнера от root, хранение секретов в коде, использование устаревших базовых образов.

Управление доступом: RBAC и принцип минимальных привилегий

Role-Based Access Control (RBAC) — это не опция, а необходимость. Каждый пользователь, сервис и приложение должны иметь ровно столько прав, сколько нужно для выполнения своих функций, не больше. На практике это означает, что вы должны отключить анонимные запросы к API Kubernetes и явно определить роли для каждого сервис-аккаунта. Если разработчик не работает с секретами — ему не нужна роль для их чтения. Если приложение только читает конфигурации — оно не должно иметь права на удаление подов. Проверьте текущие роли в вашем кластере. Часто можно найти слишком широкие разрешения, которые были выданы "на всякий случай". Это классический вектор атаки: если контейнер скомпрометирован, злоумышленник получит все права, которые есть у его сервис-аккаунта. Регулярный аудит ролей — это не одноразовая работа, а постоянный процесс. Раз в месяц-два проверяйте, какие разрешения действительно используются, и удаляйте лишние.

Security Context: ограничение возможностей контейнеров

Security Context в Kubernetes определяет, от имени какого пользователя запускается контейнер, какие системные вызовы он может выполнять и какие ресурсы может использовать. Это мощный инструмент для изоляции контейнеров. Базовое правило: контейнер никогда не должен запускаться от root. Это критически важно, потому что если контейнер скомпрометирован, злоумышленник получит максимальные привилегии. Вместо этого создайте непривилегированного пользователя в Dockerfile и запускайте приложение от его имени. Дополнительные параметры Security Context включают: - readOnlyRootFilesystem — делает корневую файловую систему контейнера доступной только для чтения. Это предотвращает модификацию файлов системы; - allowPrivilegeEscalation — запрещает контейнеру повышать свои привилегии; - capabilities — ограничивает системные возможности контейнера, оставляя только необходимые. Эти параметры можно задавать как для отдельного контейнера через securityContext, так и для всего пода через podSecurityContext. Рекомендуется установить их на уровне пода, чтобы применить единые стандарты ко всем контейнерам.

Политики безопасности подов: автоматический контроль

Pod Security Standards (PSS) — это встроенный механизм Kubernetes, который автоматически проверяет соответствие подов требованиям безопасности. Это гораздо удобнее, чем ручная проверка каждого развёртывания. PSS имеет три уровня: restricted (самый строгий), baseline (минимальные требования) и unrestricted (без ограничений). Для production рекомендуется использовать restricted, но можно начать с baseline, если у вас много legacy-приложений. Применяется PSS через Pod Security Admission Controller, который проверяет каждый создаваемый под. Если под не соответствует политике, его развёртывание будет заблокировано. Есть три режима работы: enforce (блокировка), audit (логирование нарушений) и warn (предупреждение пользователю). Практический совет: начните с режима audit, чтобы понять, какие ваши приложения нарушают требования. Затем постепенно переводите их на соответствие политике. После этого включите enforce-режим для всех новых развёртываний. Если встроенных PSS недостаточно, можно использовать более мощные инструменты вроде Kyverno, которые позволяют создавать кастомные политики безопасности.

Защита от вредоносного кода: многоуровневый подход

Сканирование уязвимостей должно происходить на нескольких уровнях. Первый уровень — это сканирование образов в Container Registry перед развёртыванием. Второй уровень — мониторинг операционной системы узлов Kubernetes на предмет вредоноса. Для защиты на уровне ОС узлов можно использовать как коммерческие решения, так и бесплатные инструменты классов Runtime Security и Antivirus Engine. Они отслеживают поведение процессов и блокируют подозрительную активность в реальном времени. Важно понимать, что сканирование образа — это статический анализ. Оно находит известные уязвимости в зависимостях, но не может выявить логические ошибки в коде приложения или атаки, которые происходят во время выполнения. Поэтому нужна защита на нескольких уровнях одновременно.

Управление секретами: исключите утечки данных

Секреты — это пароли, токены, сертификаты и другая чувствительная информация. По умолчанию Kubernetes хранит секреты в виде простого текста в etcd, что крайне небезопасно. Первое правило: никогда не храните секреты в Dockerfile или в коде приложения. Это гарантирует, что они будут видны всем, кто имеет доступ к репозиторию или образу. Второе правило: используйте шифрование для секретов в etcd. Kubernetes поддерживает встроенное шифрование, но оно нужно явно включить. Если вы этого не сделали, секреты остаются незащищёнными даже если используется встроенная система управления секретами. Третий вариант — хранить секреты вне кластера, в специализированных хранилищах вроде HashiCorp Vault или облачных сервисах управления ключами. Это более сложный подход, но он обеспечивает лучшую безопасность и централизованное управление. Не забывайте логировать доступ к секретам, но исключайте логирование самих значений. Нужно фиксировать, кто и когда получал доступ к секрету, но не то, какое значение было передано.

Логирование и аудит: видимость в системе

Без логирования вы не сможете обнаружить атаку, пока не будет слишком поздно. Kubernetes должен логировать все критические события: изменения прав доступа, операции с секретами, действия администраторов, развёртывания приложений. CIS Benchmark (стандарт безопасности для Kubernetes) требует включить минимальную audit policy через параметр --audit-policy-file. Политика должна охватывать ключевые риски: доступ к Secrets и ConfigMaps, изменения объектов подов и deployments, использование операций exec, portforward и proxy. Логи нужно отправлять в централизованное хранилище, где их можно анализировать. Простое сохранение логов локально на узлах — это не решение, потому что при компрометации узла логи будут удалены.

Сегментация сети: изолируйте трафик

NetworkPolicy в Kubernetes позволяет контролировать, какие поды могут общаться друг с другом. По умолчанию весь трафик между подами разрешён, что является серьёзной уязвимостью. Создайте базовую политику для каждого namespace, которая запрещает весь входящий трафик, а затем явно разрешайте только необходимые соединения. Это называется "deny-all by default" и это best practice. Убедитесь, что ваш CNI (Container Network Interface) поддерживает NetworkPolicy. Не все CNI это поддерживают, поэтому проверьте документацию вашего провайдера.

Проверка соответствия: CIS Benchmark

Kubernetes CIS Benchmark содержит конкретные инструкции по безопасности кластера, включая флаги для сервера API, настройки kubelet и другие параметры. Это не просто рекомендации — это проверенные на практике требования, которые защищают от известных уязвимостей. Benchmark проверяет множество аспектов: конфигурацию API сервера, защиту etcd, настройки kubelet на воркер-нодах, аудит и многое другое. Даже облачные провайдеры иногда не соответствуют этим требованиям, поэтому всегда стоит проверить вашу конкретную конфигурацию. Начните с проверки критических параметров: отключены ли анонимные запросы, защищены ли конфиги kubelet, включена ли ротация сертификатов, установлены ли безопасные runtime-параметры. Безопасность Kubernetes — это постоянный процесс, а не одноразовая настройка. Используйте этот чек-лист как отправную точку, регулярно проверяйте соответствие требованиям и обновляйте политики по мере появления новых угроз. Даже если вы не эксперт в безопасности, применение этих базовых практик значительно снизит риск компрометации вашей инфраструктуры.