Аудит безопасности Kubernetes-кластера: базовые проверки для DevOps-инженеров и администраторов

Практический аудит безопасности Kubernetes-кластера проводят в такой последовательности: доступы и RBAC, изоляция namespace, сетевые политики, секреты, затем параметры control plane. Такой порядок помогает сначала закрыть риски, которые дают полный контроль над кластером или открывают доступ к чувствительным данным.

В первую очередь проверьте привязки к cluster-admin, анонимный доступ к API, чтение объектов Secret, отсутствие сетевой сегментации в production namespace и открытые endpoints control plane. После этого оцените сервисные аккаунты, правила межnamespace-доступа, шифрование секретов в etcd и наличие журналов аудита.

Перед началом зафиксируйте версию Kubernetes, тип кластера, используемый CNI, способ управления control plane и список критичных namespace. Managed Kubernetes и self-managed кластер дают разный уровень доступа к настройкам, поэтому одинаковый чек-лист потребует разных команд и действий.

С чего начать аудит безопасности Kubernetes-кластера

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

Для расширенного сценария с готовыми командами можно использовать руководство по аудиту Kubernetes в 5 шагов. Эта статья сосредоточена на базовой последовательности и приоритетах, которые подходят для первичной проверки.

Соберите исходные данные о кластере

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

• версия Kubernetes и версии клиентских инструментов;
• поставщик облака или способ установки кластера;
• состав control plane и расположение узлов;
• используемый CNI и его режим работы;
• список namespace, включая production, staging и системные пространства;
• критичные приложения, базы данных, ingress-контроллеры и операторы;
• источники учетных данных, секретов и конфигурации CI/CD.

Начните с базовой инвентаризации:

kubectl version
kubectl cluster-info
kubectl get nodes -o wide
kubectl get namespaces
kubectl get pods -A -o wide

Команда kubectl version помогает увидеть версии клиента и API-сервера. kubectl cluster-info показывает адреса ключевых сервисов. Вывод kubectl get nodes -o wide нужен для проверки операционных систем, IP-адресов и распределения узлов.

Зафиксируйте, какие параметры вы можете менять самостоятельно. В managed-кластере провайдер часто управляет API-сервером, etcd и частью admission-контроллеров. Для таких сред проверяйте настройки endpoint access, KMS, audit logs и identity provider в панели или API провайдера. Например, Kubernetes-кластеры для рабочих нагрузок можно размещать в облачной инфраструктуре Timeweb Cloud, но параметры безопасности нужно сверять с конкретной конфигурацией выбранной площадки.

Определите критичность находок до начала проверки

Не присваивайте одинаковый приоритет всем замечаниям. Оценка должна учитывать четыре фактора:

• какие права получает субъект;
• доступен ли ресурс из недоверенной сети;
• содержит ли ресурс секреты или персональные данные;
• какова зона воздействия: один Pod, namespace или весь кластер.

Практичная шкала выглядит так:

Привязка cluster-admin к ServiceAccount обычно относится к критичному или высокому риску. Отсутствие метки само по себе редко дает путь к компрометации и чаще получает низкий приоритет.

Аудит RBAC Kubernetes: доступы, роли и сервисные аккаунты

RBAC определяет, какие пользователи, группы и сервисные аккаунты могут выполнять действия над ресурсами Kubernetes. Проверяйте не отдельную роль, а связку из субъекта, роли и binding. Без привязки широкая роль может не создавать непосредственной угрозы, но после назначения права становятся активными.

Найдите привязки к cluster-admin и широкие ClusterRoleBinding

Сначала выгрузите все привязки:

kubectl get clusterrolebindings -o wide
kubectl get rolebindings -A -o wide
kubectl get clusterrole cluster-admin -o yaml

Для каждой записи с ролью cluster-admin определите:

• кто получил права: пользователь, группа или ServiceAccount;
• в каком namespace работает ServiceAccount;
• какая задача требует полного контроля;
• есть ли срок действия или процесс отзыва доступа;
• используется ли привязка в production, CI/CD или тестовой среде.

Особенно внимательно проверяйте группы. Одна широкая группа может включать разработчиков, операторов автоматизации и временных пользователей. Административные права выдавайте адресно. Для разовой операции используйте временный доступ с последующим удалением binding.

Пример поиска привязок к cluster-admin:

kubectl get clusterrolebindings -o jsonpath='{range .items[?(@.roleRef.name=="cluster-admin")]}{.metadata.name}{"\n"}{end}'

Команда показывает имена binding. Состав субъектов для конкретной записи можно посмотреть так:

kubectl get clusterrolebinding BINDING_NAME -o yaml

Проверьте Role и ClusterRole на wildcard и опасные разрешения

Wildcards в RBAC расширяют область действия при появлении новых API-групп и ресурсов. Ищите такие конструкции:

apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]

Получить перечень ролей и их правил можно командами:

kubectl get roles -A -o yaml
kubectl get clusterroles -o yaml

Отдельно проверьте разрешения:

• get, list и watch для secrets;
• create, update, patch и delete для Roles, RoleBindings, ClusterRoles и ClusterRoleBindings;
• доступ к pods/exec, pods/attach и pods/portforward;
• доступ к nodes, persistentvolumes и storage-классам;
• право impersonate для пользователей, групп и ServiceAccount.

Право чтения Secret может раскрыть пароли, токены и ключи приложений. pods/exec позволяет выполнять команды внутри контейнера и часто дает доступ к переменным окружения или смонтированным файлам. Право изменять RBAC-ресурсы фактически может привести к выдаче дополнительных полномочий.

Для проверки эффективных прав используйте kubectl auth can-i:

kubectl auth can-i get secrets -n production --as=system:serviceaccount:production:app
kubectl auth can-i create rolebindings -n production --as=system:serviceaccount:ci:deploy
kubectl auth can-i '*' '*' --as=system:serviceaccount:production:app

Последняя проверка не заменяет полный анализ, но быстро показывает, получил ли субъект практически неограниченные права.

Ограничьте ServiceAccount и отключите ненужный token automount

Каждый Pod может получить токен Kubernetes API автоматически, если для ServiceAccount или Pod не отключен automountServiceAccountToken. Для приложений, которые не обращаются к API, токен не нужен.

kubectl get serviceaccounts -A -o yaml
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" "}{.spec.serviceAccountName}{"\n"}{end}'

Проверьте ServiceAccount по умолчанию и аккаунты приложений. Для workload без доступа к API используйте настройку:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: frontend
  namespace: production
automountServiceAccountToken: false

Если отдельному контейнеру нужен API-токен, назначьте уникальный ServiceAccount и выдайте ему минимальный набор прав. Один аккаунт для нескольких приложений усложняет расследование и увеличивает последствия компрометации.

Подробные проверки RBAC, NetworkPolicy и других типичных ошибок можно сопоставить с материалом о частых ошибках Kubernetes.

Проверьте изоляцию namespace и границы доступа

Namespace группирует ресурсы, но сам по себе не создает полноценную границу безопасности. Пользователь с ClusterRoleBinding может работать с несколькими namespace, а сетевой трафик между Pod часто разрешен, пока его явно не ограничит CNI.

Проверьте доступы между namespace

Сопоставьте RoleBinding и ClusterRoleBinding с окружениями, командами и автоматизацией:

kubectl get rolebindings -A -o yaml
kubectl get clusterrolebindings -o yaml
kubectl get roles,clusterroles -A

Отдельно проверьте production namespace. Пользователь или CI/CD ServiceAccount из staging не должен без обоснования читать или изменять Secret, Deployment и Pod в production.

kubectl auth can-i get secrets -n production --as=USER_OR_SERVICEACCOUNT
kubectl auth can-i update deployments -n production --as=USER_OR_SERVICEACCOUNT
kubectl auth can-i create pods/exec -n production --as=USER_OR_SERVICEACCOUNT

Для каждого межnamespace-доступа зафиксируйте владельца и назначение. Разрешение на чтение ConfigMap для деплоя может быть оправдано. Доступ к Secret, RBAC и ресурсам управления кластером требует отдельного обоснования.

Проверьте защиту системных и production namespace

Сначала составьте список чувствительных пространств:

• kube-system и namespace операторов;
• пространства ingress-контроллеров и сетевых компонентов;
• namespace мониторинга и сбора логов;
• production с базами данных и внутренними API;
• пространства CI/CD и GitOps-инструментов.

Для них установите отдельные правила доступа. Повседневная работа разработчиков не должна выполняться через административную учетную запись. Автоматизация должна использовать собственный ServiceAccount, ограниченный конкретными namespace и ресурсами.

ResourceQuota и LimitRange не заменяют RBAC и NetworkPolicy, но ограничивают последствия ошибок: например, число Pod, объем CPU и памяти, размер объектов или количество LoadBalancer-сервисов.

kubectl get resourcequota,limitrange -A

Проверьте NetworkPolicy и сетевую сегментацию Kubernetes

Сетевая проверка отвечает на три вопроса: кто может подключаться к Pod, куда Pod могут подключаться сами и применяет ли CNI описанные политики. Наличие YAML-манифеста еще не доказывает, что трафик действительно блокируется.

Убедитесь, что CNI применяет NetworkPolicy

Определите сетевой плагин по установленным компонентам и документации вашей платформы. Проверить системные Pod можно так:

kubectl get pods -n kube-system -o wide
kubectl get daemonsets -n kube-system

Сверьте возможности конкретного CNI: поддерживает ли он ingress и egress, правила по namespace selector, pod selector, IP-блокам и портам. Некоторые решения имеют дополнительные ограничения или собственные политики, которые влияют на результат.

Проведите контролируемый тест между двумя временными Pod. Один Pod должен находиться в разрешенном сегменте, второй, в запрещенном. Проверяйте DNS, TCP-порты и доступ к сервисам. Тест выполняйте в staging или в отдельном тестовом namespace, чтобы не нарушить работу production.

Проверьте default-deny и точечные разрешения

В production namespace должна быть базовая политика, запрещающая входящий и исходящий трафик, после чего добавляются необходимые исключения. Минимальный пример для ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Для egress добавьте отдельную политику:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress

После запрета разрешите только необходимые направления:

• frontend к backend на конкретном порту;
• backend к базе данных;
• рабочим нагрузкам к DNS;
• ingress-контроллеру к опубликованным сервисам;
• мониторингу к endpoints метрик;
• приложениям к заранее определенным внешним API.

Проверяйте selectors на точность. Слишком широкая метка вроде app: backend может разрешить доступ нескольким версиям или приложениям, если команда использует одинаковые labels.

Проверьте исходящий трафик из рабочих нагрузок

Egress-политики ограничивают загрузку вредоносных компонентов, передачу данных на внешние адреса и обращения к внутренним сервисам, которые не нужны приложению.

В ходе проверки определите, есть ли у Pod доступ к:

• metadata endpoints облачной платформы;
• внешним базам данных;
• публичным IP-адресам;
• внутренним административным сервисам;
• DNS-сервису кластера.

Если CNI поддерживает нужный формат, ограничивайте egress по namespace, selector, IP-блокам и портам. После применения политики повторите тест из разрешенной и неразрешенной сети.

Для production-ready архитектуры с HA control plane, RBAC, NetworkPolicy и observability пригодится отдельное руководство по проектированию Kubernetes-кластера.

Проверьте секреты Kubernetes и доступ к чувствительным данным

Объект Kubernetes Secret кодирует значение в base64. Base64 не шифрует данные. Любой субъект с правом чтения Secret получает исходное содержимое.

Проверьте, кто может читать Secret

Ищите правила с доступом к secrets и глаголами get, list, watch:

kubectl get roles -A -o yaml
kubectl get clusterroles -o yaml
kubectl get rolebindings -A -o yaml
kubectl get clusterrolebindings -o yaml

Право list или watch особенно опасно: оно может дать массовый доступ к объектам namespace. Сопоставьте каждую привязку с приложением или автоматизацией, которой нужен секрет.

Проверьте расположение секретов:

kubectl get secrets -A
kubectl get secret SECRET_NAME -n production -o yaml

Не публикуйте содержимое Secret в отчетах, терминальных скриншотах и системах тикетов. Для подтверждения доступа достаточно зафиксировать имя объекта, субъекта, правило RBAC и факт успешной проверки через kubectl auth can-i.

Проверьте шифрование секретов в etcd

В self-managed кластере найдите конфигурацию шифрования для kube-apiserver и проверьте, какие ресурсы защищены при хранении. Обычно в область проверки входят Secret и другие чувствительные объекты.

Проверяйте три условия:

• EncryptionConfiguration подключена к kube-apiserver;
• используется надежный провайдер шифрования и защищен его ключ;
• существующие объекты перешифрованы после изменения политики.

Одного изменения конфигурации недостаточно, если старые записи в etcd остались в прежнем виде. После настройки согласуйте процедуру перешифрования и резервного копирования с требованиями вашей платформы.

В managed Kubernetes настройки encryption at rest и KMS проверяйте у провайдера. Уточните, шифруются ли Secret по умолчанию, кто управляет ключами, как выполняется ротация и какие журналы подтверждают использование KMS.

Исключите утечки секретов через манифесты, переменные и логи

Проверьте Git-репозитории, Helm values, CI/CD variables, файлы окружения и шаблоны манифестов. Секрет, однажды попавший в историю Git или лог сборки, нужно считать раскрытым даже после удаления строки.

Отдельно проверьте:

• вывод kubectl describe и диагностических скриптов;
• логи приложений и init-контейнеров;
• аварийные дампы и архивы;
• переменные окружения внутри Pod;
• резервные копии etcd и манифестов;
• доступ к Secret через CI/CD и GitOps-инструменты.

Удаление секрета из YAML не устраняет риск. Раскрытые пароли, токены и ключи нужно отозвать и выпустить заново, затем проверить журналы использования старых учетных данных.

Проверьте безопасность control plane и API-сервера

Control plane управляет состоянием кластера. Компрометация kube-apiserver, etcd или административных учетных данных позволяет менять RBAC, запускать Pod, читать Secret и влиять на рабочие нагрузки.

Ограничьте доступ к kube-apiserver

Проверьте, доступен ли API-сервер из публичного интернета, какие CIDR разрешены, используется ли VPN или private endpoint и как настроен TLS.

Для self-managed кластера проверьте:

• правила firewall и security groups;
• адрес прослушивания API-сервера;
• разрешенные сети администраторов и CI/CD;
• срок действия клиентских сертификатов;
• защиту управляющего трафика между компонентами.

Для managed-кластера проверьте настройки public и private endpoint, authorized networks, доступ через VPN и ограничения для административных операций. Тест должен включать подключение из разрешенной сети и отказ из сети, которая не входит в список доступа.

Проверьте аутентификацию, авторизацию и анонимный доступ

Проверьте, какие identity provider используются, как создаются учетные записи и как отзываются права у уволенных сотрудников или удаленных сервисов. У каждой административной операции должен быть конкретный субъект, а не общая учетная запись команды.

Для self-managed control plane проверьте параметры:

• anonymous-auth должен быть отключен, если анонимный доступ не нужен для конкретной конфигурации;
• authorization-mode должен включать контролируемую авторизацию, обычно RBAC;
• статические токены и общие административные credentials должны иметь план замены;
• клиентские сертификаты и токены должны иметь ограниченный срок действия.

Не меняйте параметры API-сервера без проверки совместимости с managed-платформой и действующими компонентами. После каждого изменения проверяйте вход администраторов, работу CI/CD и системных операторов.

Включите аудит событий и защитите etcd

Audit logs фиксируют обращения к Kubernetes API: кто, когда и с каким результатом создавал, изменял или удалял ресурс. Без таких журналов расследование изменения RBAC или чтения Secret сильно усложняется.

Проверьте:

• подключена ли audit policy;
• попадают ли в журнал изменения RBAC и Secret;
• где хранятся логи и кто имеет к ним доступ;
• каков срок хранения и есть ли защита от удаления;
• передаются ли события во внешнюю систему сбора логов.

Для etcd проверьте TLS между клиентами и узлами, сетевую доступность, резервные копии и права на чтение snapshot-файлов. etcd нельзя выставлять в публичную сеть. Доступ к резервным копиям должен быть ограничен так же строго, как доступ к работающему хранилищу.

Сверьте список admission-контроллеров и политики, которые ограничивают небезопасные Pod. Отсутствие ограничений на privileged-контейнеры, hostNetwork, hostPID, hostPath и запуск от root повышает последствия компрометации рабочей нагрузки.

Зафиксируйте находки и устраните риски по приоритету

Финальный результат аудита должен выглядеть как рабочий реестр, а не как набор общих советов. Для каждой находки запишите ресурс, доказательство, риск, владельца, способ исправления, срок и дату повторной проверки.

Что исправлять в первую очередь

1. Закройте несанкционированный или публично доступный kube-apiserver.
2. Удалите ненужные привязки к cluster-admin и другие cluster-wide права.
3. Ограничьте чтение Secret, особенно через list и watch.
4. Включите шифрование Secret при хранении в etcd и перешифруйте существующие объекты.
5. Добавьте default-deny NetworkPolicy в критичные namespace и разрешите требуемые направления точечно.
6. Включите audit logging и защитите журналы от несанкционированного изменения.
7. Отключите автоматическую выдачу токенов ServiceAccount для Pod, которым не нужен Kubernetes API.

Как проверить, что исправление действительно работает

После изменения RBAC повторите проверки для разрешенного и запрещенного субъекта:

kubectl auth can-i get secrets -n production --as=ALLOWED_SUBJECT
kubectl auth can-i get secrets -n production --as=DENIED_SUBJECT
kubectl auth can-i create rolebindings -n production --as=SERVICE_ACCOUNT

После применения NetworkPolicy выполните тесты связности между Pod в разрешенных и запрещенных направлениях. Проверьте DNS отдельно, потому что блокировка DNS часто выглядит как полная потеря сетевого доступа.

После ограничения API-сервера проверьте подключение из разрешенной сети, отказ из запрещенной сети и работу автоматизации. После включения аудита создайте тестовое изменение в безопасном namespace и убедитесь, что событие появилось в журнале с корректным пользователем, ресурсом и результатом операции.

Повторяйте полный аудит после обновления Kubernetes, смены CNI, миграции в managed-платформу, изменения identity provider и крупных изменений RBAC. Для production-кластера полезно назначить регулярную проверку, а критичные права и доступ к Secret контролировать чаще, чем остальные параметры.

Минимальный практический маршрут выглядит так: инвентаризация, RBAC, namespace, NetworkPolicy, Secret, control plane, приоритизация и повторная валидация. Такой порядок помогает быстро найти самые дорогие ошибки и подтвердить, что исправления повлияли на фактическую безопасность кластера.

Если аудит затрагивает контейнерные образы, Docker и конфигурацию хостов, расширьте проверку по руководству по аудиту контейнеров и Kubernetes. Для комплексной проверки инфраструктуры пригодится практический план аудита IT-инфраструктуры.