0Pricing
Security+ Academy · Урок

Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов

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

«Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов» — бесплатный урок Security+ Academy на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Security+ Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Security+ Academy содержит 4 уроков всего.

Обзор поверхности атаки Kubernetes

Kubernetes оркестрирует рабочие нагрузки в контейнерах в больших масштабах, но его сложность создаёт широкую поверхность атаки. Ключевые компоненты, которые необходимо защищать: сервер API (центральная плоскость управления — его компрометация даёт контроль над всем кластером), etcd (база данных состояния кластера — хранит секреты в формате base64, поэтому данные необходимо шифровать в состоянии покоя), kubelet (агент узла — неаутентифицированный API kubelet позволяет произвольно запускать Pod), среда выполнения контейнеров (Docker/containerd) и сетевая инфраструктура, соединяющая все Pod. Кандидатам на Security+ следует понимать, что неправильные настройки Kubernetes относятся к числу наиболее распространённых проблем безопасности в облаке.

RBAC: управление доступом на основе ролей в Kubernetes

RBAC (управление доступом на основе ролей) Kubernetes определяет, какие пользователи, служебные учётные записи и процессы могут выполнять какие действия с какими ресурсами API. Модель включает четыре объекта: Role (разрешения в пространстве имён), ClusterRole (разрешения на уровне кластера), RoleBinding (предоставляет Role субъекту в пределах пространства имён) и ClusterRoleBinding (предоставляет ClusterRole субъекту во всём кластере). Каждая команда kubectl преобразуется в вызов API, который проверяется по правилам RBAC. Если RBAC не настроен, любой аутентифицированный пользователь (или служебная учётная запись) может получить административный доступ.

# Create a role allowing only pod reads in 'default' namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [''] 
  resources: ['pods']
  verbs: ['get', 'list', 'watch']

Служебные учётные записи и минимальные привилегии

Каждый Pod в Kubernetes работает от имени служебной учётной записи — удостоверения, используемого для аутентификации в API. По умолчанию Pod используют служебную учётную запись default в своём пространстве имён, которая может иметь широкие разрешения. Принцип минимальных привилегий требует создавать выделенные служебные учётные записи для каждого приложения и предоставлять им только необходимые разрешения. Кроме того, установка параметра automountServiceAccountToken: false для Pod, которым не нужен доступ к API, не позволяет подключать токен служебной учётной записи к файловой системе Pod, где скомпрометированное приложение могло бы использовать его для выполнения вызовов API.

# Pod spec: disable service account token auto-mount
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  serviceAccountName: myapp-sa
  automountServiceAccountToken: false
  containers:
  - name: myapp
    image: myapp:v1.0

Сетевые политики: запрет по умолчанию

По умолчанию в Kubernetes все Pod могут взаимодействовать со всеми другими Pod в любом пространстве имён. Скомпрометированный Pod может немедленно попытаться обратиться к базам данных, внутренним API и другим микросервисам. Ресурсы NetworkPolicy Kubernetes задают правила, ограничивающие обмен трафиком между Pod на основе меток, пространств имён и портов. Рекомендуемый подход — создать сетевую политику «запретить всё по умолчанию» в каждом пространстве имён, а затем добавить явные правила разрешения для необходимых путей взаимодействия. Обратите внимание: для работы NetworkPolicy требуется поддерживающий её плагин CNI (Calico, Cilium, Weave); обычный Kubernetes игнорирует NetworkPolicy без совместимого CNI.

# Default deny all ingress and egress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Стандарты безопасности Pod: замена PSP

Стандарты безопасности Pod (PSS), представленные в Kubernetes 1.23 и стабилизированные в версии 1.25, заменяют устаревшую политику безопасности Pod (PSP) тремя встроенными профилями, применяемыми на уровне пространства имён: Privileged (без ограничений, для системных компонентов), Baseline (предотвращает известные способы повышения привилегий, например использование привилегированных контейнеров и доступ к сети узла) и Restricted (усиленный профиль, требующий пользователей без прав root, отключающий все возможности и принудительно задающий файловые системы root только для чтения). Пространства имён получают метки для применения уровня политики, а Pod, нарушающие её, отклоняются на этапе допуска.

# Label namespace to enforce 'restricted' pod security
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

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

Секреты Kubernetes хранят конфиденциальные данные, такие как пароли, токены и сертификаты TLS. По умолчанию секреты хранятся в etcd в виде значений, закодированных в base64, то есть не зашифрованными. Любой, кто может читать etcd или обладает достаточными разрешениями RBAC, может легко их декодировать. Рекомендуемые меры включают: включение шифрования данных etcd в состоянии покоя с помощью AES-GCM и ключа, хранящегося в KMS (AWS KMS, GCP KMS); интеграцию с внешним менеджером секретов, например HashiCorp Vault или AWS Secrets Manager, через Secrets Store CSI Driver; а также ограничение доступа к секретам с помощью RBAC, чтобы читать их могли только нуждающиеся в них служебные учётные записи.

# Enable etcd encryption at rest (encryption configuration)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>

Контроллеры допуска: рубежи безопасности

Контроллеры допуска — это плагины сервера API Kubernetes, которые перехватывают запросы API после аутентификации и авторизации, но до сохранения объекта, что позволяет им проверять, изменять или отклонять запросы. К контроллерам допуска, связанным с безопасностью, относятся: PodSecurity (применяет стандарты безопасности Pod), ImagePolicyWebhook (позволяет внешнюю проверку подписей образов), AlwaysPullImages (принудительно загружает образы заново, предотвращая использование локально кэшированных вредоносных образов) и OPA/Gatekeeper (Open Policy Agent — наиболее гибкий вариант, позволяющий задавать пользовательские политики на языке Rego для применения любых организационных правил безопасности).

Усиление защиты компонентов кластера

Усиление защиты компонентов плоскости управления Kubernetes имеет критическое значение: для сервера API следует задать --anonymous-auth=false, чтобы отключить неаутентифицированный доступ, настроить --audit-log-path для записи всех действий API и включить TLS для всех соединений. Для kubelet следует задать --authorization-mode=Webhook (а не AlwaysAllow) и отключить анонимную аутентификацию. Для etcd следует включить шифрование TLS для соединений между узлами и клиентов, ограничить сетевой доступ (разрешить доступ только серверу API) и шифровать данные в состоянии покоя. Эталон CIS Kubernetes содержит полный контрольный список настроек всех компонентов.

# Check kubelet configuration for security issues
kubectl get --raw /api/v1/nodes/nodename/proxy/configz | jq '.kubeletconfig | {anonymousAuth: .authentication.anonymous.enabled, authorization: .authorization.mode}'

Изоляция пространств имён и мультитенантность

Пространства имён Kubernetes обеспечивают логическое разделение ресурсов, но сами по себе не являются надёжной границей безопасности — прежде всего они обеспечивают организационную изоляцию. Для настоящей изоляции арендаторов (например, рабочих нагрузок разных клиентов) требуются дополнительные средства: сетевые политики для блокирования трафика между пространствами имён, квоты ресурсов для предотвращения DoS со стороны одного из арендаторов, отдельные пулы узлов для сильной изоляции арендаторов или выделенные кластеры для каждого арендатора. Многие организации используют иерархические пространства имён или коммерческие решения, такие как vCluster, для более сильной мультитенантности в пределах одного кластера.

Аудит и мониторинг во время выполнения

Аудит в Kubernetes записывает каждый запрос к API: кто его отправил, откуда, какое действие запросил и какого Resource оно коснулось. Журналы аудита необходимы для криминалистического расследования после инцидента безопасности и обнаружения аномального поведения, например необычных привязок ролей, обращений к секретам или выполнения команд exec в рабочих модулях. Журналы аудита следует передавать в централизованную систему SIEM. Falco обеспечивает мониторинг поведения контейнеров во время выполнения, а облачные управляемые сервисы Kubernetes (EKS, GKE, AKS) обеспечивают встроенную интеграцию журналов аудита с соответствующими платформами ведения журналов.

# Check recent kubectl exec events in audit log
grep '"verb":"create".*"resource":"pods".*"subresource":"exec"' /var/log/kubernetes/audit.log | tail -20

Безопасность цепочки поставок: происхождение образов

Безопасность цепочки поставок для Kubernetes гарантирует, что в рабочую среду попадут только доверенные и проверенные образы. Рекомендации CNCF по безопасности цепочки поставок включают проверку подписей образов с помощью Cosign перед развертыванием (с принудительным контролем через контроллеры допуска), создание и проверку SBOM (спецификаций состава программного обеспечения) для всех образов контейнеров, чтобы отслеживать происхождение компонентов, закрепление образов за дайджестами (myimage@sha256:abc123), а не за изменяемыми тегами, а также проверку всех сторонних диаграмм Helm на наличие неправильных конфигураций и уязвимостей перед развертыванием.

# Pin image to digest for immutability
# Instead of:
image: nginx:latest
# Use:
image: nginx@sha256:a3e2a7a3d7f94e...  # immutable digest

Быстрая проверка

Проверьте, насколько хорошо Вы понимаете рассмотренные в этом уроке концепции CompTIA Security+ (SY0-701).

Итоги урока

В этом уроке Вы узнали, что Kubernetes RBAC управляет доступом к API через роли, ClusterRoles и привязки: для учетных записей сервисов всегда следует применять принцип минимальных привилегий; конфигурации NetworkPolicy с запретом по умолчанию предотвращают горизонтальное перемещение между модулями и пространствами имен; а Pod Security Standards обеспечивают усиление защиты контейнеров на уровне пространства имен, блокируя привилегированные контейнеры, доступ к сети узла и выполнение от имени root. Далее мы рассмотрим безопасность бессерверных приложений и поверхности атак на уровне функций.

Часто задаваемые вопросы

Урок «Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов» бесплатный?

Да — полный текст урока «Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Security+ Academy, подпишись на CoddyKit PRO. Курс Security+ Academy содержит 4 уроков всего.

Чему я научусь в уроке «Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов»?

Настройте роли RBAC в Kubernetes, применяйте сетевые политики, ограничивающие трафик между подами, и используйте стандарты безопасности подов для ограничения повышения привилегий. Ты практикуешь Security+ Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Security+ Academy?

Предыдущий опыт не требуется. Security+ Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.

Сколько времени занимает урок «Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Security+ Academy?

Да. Каждый урок Security+ Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Безопасность контейнеров: усиление образов и защита во время выполнения
  2. Безопасность Kubernetes: RBAC, сетевые политики и безопасность подов
  3. Безсерверные системы и безопасность функций
  4. Сканирование безопасности инфраструктуры как кода
← Назад к Security+ Academy