Безопасность Kubernetes в 2026:
полное руководство от аудита до PCI DSS

От проверки кластера до прохождения сертификации регулятора

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

Почему безопасность Kubernetes — задача №1 в 2026

Kubernetes стал стандартом оркестрации контейнеров, но в 2026 году он также стал одной из главных целей для злоумышленников. Мисконфигурации остаются главным риском — не zero-day эксплойты, а ошибки в настройках, которые открывают дверь атакующим.

Для инженеров: в декабре 2025 года TeamPCP развернула масштабную кампанию, нацеленную на облачные среды: через открытые Docker API, Kubernetes-кластеры и другие мисконфигурации. Для Kubernetes-сред использовался специальный payload, который перечислял поды и namespace’ы, выполнял команды во всех доступных рабочих нагрузках и устанавливал привилегированный DaemonSet для постоянного контроля над кластером. По данным Flare, было подтверждено компрометирование минимум 185 серверов с контейнерами. Один скомпрометированный под превратил целые кластеры в распределённый ботнет.

Для CTO: по данным Red Hat, 67% компаний замедляли или откладывали развёртывание приложений из-за проблем безопасности Kubernetes, а около 90% сталкивались хотя бы с одним инцидентом безопасности за последний год. Это не вопрос «если», а вопрос «когда». Для казахстанского рынка это особенно актуально: PCI DSS 4.0 вступил в полную силу, НБРК ужесточает требования, банки массово переходят на контейнерные среды.
💼 Из нашей практики: когда компания ioka обратилась к нам для прохождения ежегодной сертификации PCI DSS 4.0, мы прошли 288+ критериев безопасности и обнаружили как мелкие недочёты, так и критичные уязвимости в инфраструктуре. Именно ошибки конфигурации составляли основную угрозу
В этом руководстве мы разберём все слои безопасности Kubernetes по модели 4C, покажем практические примеры из наших аудитов и дадим чеклист, который можно применить прямо сегодня.

Модель 4C: четыре слоя безопасности

Безопасность Kubernetes строится по принципу глубинной защиты (defense in depth). Модель 4C описывает четыре слоя, каждый из которых должен быть защищён независимо: Cloud, Cluster, Container, Code. Если один слой пробит — следующий должен остановить атаку.

Cloud: фундамент, который часто забывают

Первый слой — это инфраструктура, на которой работает ваш кластер: облако, дата-центр или гибрид. Можно идеально настроить RBAC внутри кластера, но если облачный провайдер оставил открытыми security groups — всё бесполезно.

По данным отчёта Wiz, 81% кластеров EKS всё ещё используют устаревшую CONFIG_MAP-аутентификацию. Для on-premise инсталляций в Казахстане ситуация зачастую ещё хуже: серверы в дата-центрах не всегда имеют даже базовую сетевую изоляцию.

Что проверить на уровне Cloud

Шифрование данных. Все данные должны быть зашифрованы как при передаче (in transit), так и при хранении (at rest). Это одно из обязательных требований PCI DSS 4.0.

Изоляция сети. Security groups, VPC, firewall rules — кластер Kubernetes не должен быть доступен из интернета напрямую. API-сервер должен быть доступен только через VPN или bastion host.

IAM и ротация ключей. Сервисные аккаунты облачного провайдера должны иметь минимальные привилегии. Ключи доступа должны ротироваться автоматически.

Специфика Казахстана. Если вы используете Yandex Cloud или VK Cloud — проверьте, что Managed Kubernetes настроен с приватным API-эндпоинтом, включенным шифрованием и ограниченными сетевыми политиками. Если ваш облачный провайдер не прошёл аудит ISO 27001 — никакой RBAC внутри кластера не спасёт.

Cluster: control plane под замком

RBAC — принцип наименьших привилегий

RBAC (Role-Based Access Control) — это первое, что нужно настроить правильно. Самая распространённая ошибка — назначение cluster-admin сервис-аккаунтам CI/CD или разработчикам. Это нарушает принцип наименьших привилегий и делает латеральное движение атакующего тривиальным.

Правила: назначайте права на уровне namespace через Role/RoleBinding, а не ClusterRole/ClusterRoleBinding. Используйте только те разрешения, которые реально нужны. Регулярно аудируйте права командой kubectl auth can-i --list.

Пример: создаём ограниченную роль для команды разработки. Она даёт доступ только к подам и деплойментам в конкретном namespace:
# Role: разрешаем только pods и deployments в namespace dev
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-team-role
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
---
# RoleBinding: привязываем роль к группе
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: dev-team-binding
subjects:
- kind: Group
  name: "dev-team"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-team-role
  apiGroup: rbac.authorization.k8s.io
Обратите внимание: Role, а не ClusterRole. Права действуют только в namespace dev. Команда может смотреть логи подов и управлять деплойментами, но не может удалять поды, менять секреты или создавать сервисы. Проверить текущие права: kubectl auth can-i --list --namespace dev --as dev-team-member.

Pod Security Admission

Pod Security Policy (PSP) устарела и удалена из Kubernetes. Её замена — Pod Security Admission (PSA), которая работает через метки namespace. Три уровня: Privileged (без ограничений), Baseline (минимальные ограничения, блокирует наиболее опасные конфигурации) и Restricted (максимальное ужесточение). Минимум для продакшна — Baseline.

Применить PSA можно одной командой — достаточно добавить метки на namespace:
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # enforce = блокирует поды, нарушающие политику
    pod-security.kubernetes.io/enforce: "baseline"
    pod-security.kubernetes.io/enforce-version: "latest"
    # warn = предупреждает, но не блокирует (для тестирования restricted)
    pod-security.kubernetes.io/warn: "restricted"
    pod-security.kubernetes.io/warn-version: "latest"
    # audit = пишет в лог (для мониторинга)
    pod-security.kubernetes.io/audit: "restricted"
    pod-security.kubernetes.io/audit-version: "latest"
Стратегия: начните с enforce=baseline (блокирует самые опасные конфигурации — привилегированные контейнеры, hostNetwork, hostPID), а restricted поставьте в режим warn. Когда все предупреждения устранены — переключите на enforce=restricted.

Admission Controllers и Policy Engines

ValidatingAdmissionPolicy стал стабильным (GA) в Kubernetes 1.30 и позволяет описывать политики декларативно, без внешних вебхуков.

Для более сложных сценариев используют OPA/Gatekeeper или Kyverno.

OPA подходит, когда нужна унифицированная политика за пределами Kubernetes (например, для Terraform).

Kyverno проще в освоении, так как политики пишутся на YAML.

Защита API-сервера и etcd

API-сервер — центральная точка управления кластером. Отключите анонимный доступ, включите audit logging для отслеживания всех действий. База данных etcd хранит всё состояние кластера, включая секреты. Доступ на запись к etcd эквивалентен root-доступу ко всему кластеру. Обязательно: шифрование at rest, TLS, ограниченный сетевой доступ. На kubelet отключите read-only port и включите webhook-авторизацию.
Получите бесплатную консультацию по вашему проекту
Настроим ваш Kubernetes под новые реалии
💼 Кейс Sector Tree: когда мы разворачивали Kubernetes-кластер для 20–25 микросервисов, мы интегрировали аутентификацию через Azure AD с OAuth-токенами. Это сразу закрыло вектор несанкционированного доступа к CI/CD пайплайну. Результат: критичные сервисы перестали зависеть от локальных сбоев, время выпуска обновлений сократилось на 30–40%.

Container: безопасность от сборки до рантайма

Образы: сканирование и подпись

Каждый контейнерный образ должен сканироваться на уязвимости до развёртывания. Trivy и Grype — основные инструменты, которые легко интегрируются в CI/CD. Подпись образов через cosign/Sigstore гарантирует, что в продакшн попадают только проверенные образы. Harbor как приватный реестр обеспечивает дополнительный контроль.

Рантайм: не запускать от root

Контейнеры, запущенные от root — одна из главных угроз. Используйте runAsNonRoot: true и readOnlyRootFilesystem: true в спецификации подов. Seccomp и AppArmor профили ограничивают системные вызовы и уменьшают поверхность атаки. User Namespaces — один из ключевых механизмов усиления изоляции, который движется к GA в 2026.

Вот как выглядит полный securityContext для продакшн-пода:
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
  namespace: production
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myregistry.kz/app:v1.2.3@sha256:abc123...
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
    resources:
      limits:
        cpu: "500m"
        memory: "256Mi"
      requests:
        cpu: "100m"
        memory: "128Mi"
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  volumes:
  - name: tmp
    emptyDir: {}
Ключевые моменты: runAsNonRoot: true — запрещает запуск от root. readOnlyRootFilesystem: true — файловая система только для чтения (для tmp используем emptyDir). capabilities: drop: ["ALL"] — убираем все Linux capabilities. allowPrivilegeEscalation: false — запрещаем повышение привилегий. Образ закреплён через sha256 digest, а не тег — это защита от подмены.

Runtime Detection

Falco — стандарт обнаружения аномалий в рантайме Kubernetes. Он использует eBPF для перехвата системных вызовов и может обнаружить, например, несанкционированное развёртывание DaemonSet или подозрительный east-west трафик между подами.

Безопасность Kubernetes — это не только защита самой платформы, но и всех смежных систем: registry, CI/CD, внешних баз данных.

Code: сеть и секреты

Network Policy — файрвол внутри кластера

По умолчанию в Kubernetes все поды могут общаться друг с другом без ограничений. Это означает, что один скомпрометированный под может сканировать весь кластер или добраться до базы данных. Правильный подход: начать с deny-all политики, затем явно разрешать только нужный трафик. CNI-плагины Calico и Cilium обеспечивают применение этих политик.

Шаг 1 — закрыть всё. Deny-all политика запрещает весь входящий и исходящий трафик для всех подов в namespace:
# Шаг 1: запретить весь трафик в namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}  # применяется ко ВСЕМ подам
  policyTypes:
  - Ingress
  - Egress
---
# Шаг 2: разрешить frontend → backend на порту 8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
---
# Шаг 3: разрешить backend → postgres на порту 5432
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 5432
Важно: Network Policy работает только если ваш CNI-плагин поддерживает их. Calico и Cilium — поддерживают. Стандартный kubenet — нет. После deny-all вы явно разрешаете только нужные маршруты: frontend → backend → database. Скомпрометированный frontend не сможет достучаться до базы данных напрямую.

Управление секретами

Встроенные Kubernetes Secrets — это не шифрование, а base64-кодирование. Любой, кто имеет доступ к поду, может прочитать секреты. Секреты рискуют попасть в логи — передавайте их через файлы (монтированные тома), а не переменные окружения. Для продакшна используйте External Secrets Operator в связке с HashiCorp Vault или аналогичным хранилищем.

Сравните два подхода:
# ❌ ПЛОХО: секрет в переменной окружения — попадёт в логи и env dump
env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-credentials
      key: password

# ✅ ХОРОШО: секрет через volume — доступен только как файл
volumeMounts:
- name: db-creds
  mountPath: /etc/secrets/db
  readOnly: true
volumes:
- name: db-creds
  secret:
    secretName: db-credentials
    defaultMode: 0400  # только чтение для владельца
Переменные окружения видны через /proc/[pid]/environ, попадают в логи при crash dump, доступны всем процессам в контейнере. Файловые секреты можно ограничить правами доступа (0400), они автоматически обновляются при ротации в Kubernetes, и их сложнее случайно залогировать. Для продакшна используйте External Secrets Operator + HashiCorp Vault — секреты вообще не хранятся в etcd.

mTLS и service mesh

Взаимная TLS-аутентификация (mTLS) гарантирует, что сервисы внутри кластера общаются только с проверенными партнёрами. В Kubernetes 1.35 появилась бета-версия встроенного механизма Pod Certificates (KEP-4317), который позволяет подам получать TLS-сертификаты напрямую от kubelet — в первую очередь для аутентификации к API-серверу.

Для полноценного pod-to-pod mTLS по-прежнему используются service mesh: Istio и Linkerd, которые также дают ретрай, circuit breaking и обсервабилити.

Compliance: PCI DSS 4.0 и требования регулятора

Этот раздел — наша уникальная экспертиза. Мы помогли компаниям в Казахстане пройти сертификацию PCI DSS 4.0 и испытания ГТС. Вот что нужно знать.

CIS Kubernetes Benchmark

CIS Kubernetes Benchmark — наиболее признанный стандарт для проверки конфигурации кластера. Инструмент kube-bench автоматизирует проверку по 100+ тестам. Это минимум для любого продакшн-кластера.

OWASP Kubernetes Top 10

OWASP Kubernetes Top 10 предоставляет приоритизированную карту рисков: K01 — небезопасная конфигурация, K02 — уязвимости цепочки поставок, K03 — избыточные права RBAC. Это полезный фреймворк для разговора между DevOps и безопасниками.

Кейс ioka: прохождение PCI DSS 4.0

Компания ioka — платёжная система, которая работает с платёжными данными и обязана ежегодно проходить сертификацию. Мы работаем с ioka уже 3 года: сначала мигрировали приложения в Казахстан, затем помогали с ежегодной сертификацией.

Этап 1. Аудитор отправил документы со списком из 288+ критериев. Мы заполнили эти документы совместно с сотрудниками ioka и составили план работ.

Этап 2. Прощупали инфраструктуру самостоятельно, исходя из особенностей стека и собственных наработок. Обнаружили мелкие недочёты и критичные уязвимости — ioka исправляла приложение, мы — инфраструктуру.

Этап 3. Аудитор запросил доступы, проверил систему, отправил отчёт по доработкам. Мы внедряли исправления. Этот цикл повторялся несколько раз. Сложность: ioka проходила по новому стандарту PCI DSS 4.0 — он существенно строже предыдущей версии. Результат: сертификат получен.

Инструменты: что для чего

Вот основные инструменты, которые мы рекомендуем клиентам. Подробнее о Kubescape читайте в нашей отдельной статье.

Чеклист: 20 действий по приоритету

Мы разделили действия на три группы по срочности. Начните с красных — это то, что можно сделать за один день и закрыть основные векторы атак.
Получите бесплатную консультацию по вашему проекту
Настроим ваш Kubernetes под новые реалии