Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене KCSA. Читайте сверху вниз или переходите к нужному разделу.
Разработка комплексной стратегии облачной нативной безопасности.
Внедрить меры безопасности по всем 4С: Облако (основа), Кластер, Контейнер и Код.
Почему: Компрометация внешнего уровня (например, Облака) подрывает безопасность всех внутренних уровней. Безопасность настолько сильна, насколько сильно ее самое слабое звено.
Защита от единичных точек отказа в безопасности.
Реализовать множественные, перекрывающиеся меры безопасности на разных уровнях (например, NetworkPolicies, RBAC, Security Contexts).
Почему: Если один контроль выходит из строя или обходится, другие уровни продолжают обеспечивать защиту, увеличивая сложность для злоумышленника.
Защита сетевого трафика в среде, где сетевое расположение не является доверенной границей.
Реализовать модель "никогда не доверяй, всегда проверяй". Аутентифицировать и авторизовать каждый запрос, обычно используя service mesh для mTLS.
Почему: Предполагает, что угрозы могут существовать как внутри, так и вне сети, устраняя неявное доверие, основанное на сетевой позиции.
Ограничение радиуса поражения скомпрометированной личности или компонента.
Предоставлять всем субъектам (пользователям, учетным записям служб, узлам) только минимальные разрешения, необходимые для выполнения их функций.
Почему: Уменьшает потенциальный ущерб, который злоумышленник может нанести с помощью украденных учетных данных.
Снижение стоимости и влияния уязвимостей безопасности.
Интегрировать автоматическое сканирование безопасности (SAST, SCA, сканирование образов) и проверки политик на ранних этапах конвейера CI/CD.
Почему: Обнаруживает и устраняет уязвимости на более ранних этапах жизненного цикла разработки, когда их исправление обходится дешевле всего.
Защита конфиденциальных данных кластера (особенно Secrets) в случае компрометации хранилища etcd.
На kube-apiserver используйте `--encryption-provider-config` для включения шифрования данных в состоянии покоя для ресурсов до их сохранения в etcd.
Почему: По умолчанию секреты Kubernetes кодируются только в base64 в etcd. Это обеспечивает истинное шифрование на диске.
Предотвращение несанкционированного доступа и прослушивания etcd-коммуникаций.
Настроить etcd с mTLS как для клиентской (`--client-cert-auth`), так и для peer (`--peer-client-cert-auth`) связи.
Почему: Гарантирует, что только аутентифицированные компоненты (apiserver, другие члены etcd) могут взаимодействовать с etcd и что трафик зашифрован.
Предотвращение неаутентифицированного доступа к серверу Kubernetes API.
Установить флаг `--anonymous-auth=false`. Использовать надежные методы аутентификации, такие как OIDC или сертификаты x509.
Почему: Отключает пользователя `system:anonymous`, заставляя все запросы быть аутентифицированными и регистрируемыми под определенной личностью.
Требование отслеживать все изменения и попытки доступа для безопасности и соответствия требованиям.
Включить ведение журнала аудита API-сервера с помощью `--audit-policy-file` и отправлять журналы во внешнюю, неизменяемую систему журналирования.
Почему: Обеспечивает существенный, защищенный от подделки след для расследования инцидентов, поиска угроз и аудитов соответствия требованиям.
Сокращение поверхности атаки рабочих узлов.
Установить флаги kubelet: `--anonymous-auth=false`, `--authorization-mode=Webhook` и `--read-only-port=0`.
Почему: Это гарантирует, что все запросы к API kubelet аутентифицируются и авторизуются API-сервером, и отключает небезопасный, неаутентифицированный порт только для чтения.
Предотвращение утечки информации из компонентов плоскости управления.
Установить флаг `--profiling=false` для kube-apiserver, kube-controller-manager и kube-scheduler в production.
Почему: Конечные точки профилирования могут раскрывать внутренние данные о производительности и системные детали, которые могут помочь злоумышленнику в разведке.
Защита компонентов плоскости управления от несанкционированного доступа к сети.
Использовать правила брандмауэра (облачные группы безопасности, iptables) для ограничения доступа к портам API-сервера (6443) и etcd (2379) только для доверенных источников.
Почему: Контроль доступа на уровне сети является фундаментальным уровнем защиты, предотвращая даже достижение злоумышленниками чувствительных API компонентов.
Предоставление разрешений пользователям или приложениям.
Использовать `Roles` с привязкой к пространству имен вместо `ClusterRoles`. Предоставлять конкретные глаголы (`get`, `list`) вместо подстановочных знаков (`*`).
Почему: Следует принципу наименьших привилегий, ограничивая область разрешений только тем, что необходимо в конкретном пространстве имен.
Поду не требуется обмениваться данными с Kubernetes API.
Установите `automountServiceAccountToken: false` в спецификации пода или в самой учетной записи службы (ServiceAccount).
Почему: Предотвращает раскрытие ненужных учетных данных внутри пода, уменьшая поверхность атаки в случае компрометации пода.
Применение базового уровня безопасности для всех подов в пространстве имен.
Использовать встроенный контроллер допусков `PodSecurity`, применяя метки пространства имен, такие как `pod-security.kubernetes.io/enforce: baseline`.
Почему: Предоставляет стандартизированный, встроенный способ предотвращения рискованных конфигураций подов (например, привилегированных контейнеров) без сторонних инструментов.
Усиление безопасности отдельных контейнеров для предотвращения повышения привилегий.
В спецификации пода установите поля `securityContext`: `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`.
Почему: Эти меры предотвращают запуск от имени root, блокируют механизмы получения новых привилегий и делают файловую систему контейнера неизменяемой, что значительно снижает влияние компрометации.
Реализация сетевой модели "нулевого доверия" внутри кластера.
Применить NetworkPolicy с политикой "отклонять по умолчанию" к каждому пространству имен, который выбирает все поды (`podSelector: {}`) и имеет пустой список правил входящего/исходящего трафика.
Почему: Сеть Kubernetes по умолчанию разрешает трафик. Эта политика инвертирует модель на "отклонять по умолчанию", заставляя разработчиков явно разрешать необходимый трафик.
Разрешение трафика только между конкретными уровнями приложений (например, web-to-api).
Создать NetworkPolicies, использующие `podSelector` и `namespaceSelector` для определения гранулярных правил входящего и исходящего трафика на основе меток.
Почему: Предотвращает горизонтальное перемещение злоумышленников, гарантируя, что скомпрометированный под может взаимодействовать только с явно авторизованными пирами.
Пользователю требуется разрешение на `kubectl exec` для отладки контейнеров.
Предоставить глагол `create` для подресурса `pods/exec` в соответствующей роли (Role) или кластерной роли (ClusterRole).
Почему: Действие `exec` неинтуитивно контролируется глаголом `create`, потому что оно создает новую сессию exec. Это распространенная точка заблуждения.
Злоумышленник получает доступ к контейнеру и пытается скомпрометировать узел хоста.
Запретить привилегированные контейнеры (`securityContext.privileged: false`), хостовые пространства имен (`hostNetwork`, `hostPID`) и монтирование Docker-сокета.
Почему: Эти конфигурации фактически нарушают изоляцию контейнера, предоставляя скомпрометированному контейнеру доступ к хосту на уровне root.
Предотвращение развертывания образов контейнеров с известными уязвимостями или вредоносным кодом.
Внедрить сканирование образов (например, Trivy) и проверку подписей образов (например, Cosign) в конвейере CI/CD и через контроллер допусков.
Почему: Обеспечивает многоуровневую защиту: сканирование выявляет известные уязвимости, а подписывание проверяет целостность и происхождение образа.
Злоумышленник скомпрометировал один под и пытается получить доступ к другим подам в кластере.
Внедрить NetworkPolicies с политикой "отклонять по умолчанию" и создавать специфические правила разрешения только для необходимого взаимодействия между подами.
Почему: Ограничивает "поле зрения" злоумышленника из скомпрометированного пода, локализуя нарушение и предотвращая его распространение.
Предотвращение кражи скомпрометированным подом учетных данных облачного IAM из службы метаданных экземпляра.
Применить NetworkPolicy с политикой "отклонять по умолчанию" для исходящего трафика, которая явно блокирует трафик к IP-адресу метаданных (например, `169.254.169.254/32`).
Почему: Это распространенный путь атаки в облачных средах. Блокировка этого исходящего пути снижает риск кражи учетных данных IAM из подов.
Защита от атак типа "отказ в обслуживании" или "криптоджекинга", истощающих ресурсы узла.
Применить объекты `ResourceQuota` к пространствам имен для ограничения общего использования ресурсов и объекты `LimitRange` для применения ограничений к отдельным подам.
Почему: Гарантирует, что ни один арендатор или рабочая нагрузка не сможет лишить других ресурсов, обеспечивая стабильность и предотвращая злоупотребления.
Злоумышленник пытается сохранить долгосрочный доступ к скомпрометированному кластеру.
Мониторить создание неожиданных `DaemonSets`, `CronJobs` или привилегированных подов. Ограничить разрешения на создание этих ресурсов.
Почему: Злоумышленники используют эти типы рабочих нагрузок, чтобы их вредоносный код запускался постоянно, даже если узел или под перезапускаются.
Обеспечение отсутствия известных уязвимостей в образах контейнеров перед развертыванием.
Интегрировать сканер образов, такой как Trivy, Clair или Grype, в конвейер CI/CD для сканирования образов и прерывания сборки, если обнаружены критические уязвимости.
Почему: Автоматизирует обнаружение уязвимостей на ранней стадии ("сдвиг влево"), предотвращая попадание уязвимого кода в production.
Обеспечение развертывания в кластере только доверенных, неизмененных образов контейнеров.
Подписывать образы с помощью инструмента, такого как Cosign, в конвейере CI. Использовать контроллер допуска с проверкой (например, Kyverno, Gatekeeper) для проверки подписи во время развертывания.
Почему: Обеспечивает криптографическое доказательство целостности образа (он не был изменен) и его происхождения (он пришел из доверенного источника).
Обнаружение вредоносной активности внутри запущенного контейнера (например, запуск оболочки, доступ к конфиденциальным файлам).
Развернуть инструмент безопасности среды выполнения, такой как Falco, который использует eBPF для мониторинга системных вызовов и оповещения о подозрительном поведении на основе определенного набора правил.
Почему: Обеспечивает видимость активности во время выполнения, которую не могут увидеть статическое сканирование и контроль допусков. Это крайне важно для обнаружения активных нарушений.
Применение пользовательских, специфичных для организации политик безопасности (например, "все образы должны поступать из нашего корпоративного реестра").
Использовать механизм политик, такой как OPA Gatekeeper или Kyverno, в качестве контроллера допуска с проверкой для применения политик, написанных на Rego или YAML.
Почему: Позволяет гибко, декларативно и автоматизировано применять политики безопасности, выходящие за рамки встроенных средств управления Kubernetes.
Шифрование и аутентификация всего трафика между службами внутри кластера.
Реализовать service mesh (например, Istio, Linkerd) для автоматического предоставления взаимного TLS (mTLS) для всех служб, включенных в mesh.
Почему: Достигает сетевой модели "нулевого доверия", гарантируя, что весь внутрикластерный трафик зашифрован и службы взаимно проверяют идентичность друг друга.
Запуск недоверенных или мультиарендных рабочих нагрузок, требующих более сильной изоляции, чем стандартные контейнеры.
Использовать песочницу для контейнеров, такую как gVisor или Kata Containers, которая обеспечивает дополнительный слой изоляции между контейнером и ядром хоста.
Почему: Уменьшает поверхность атаки ядра хоста, значительно усложняя выход из контейнера.
Тонкий контроль над разрешениями контейнера на уровне ядра.
Использовать профили Seccomp для фильтрации разрешенных системных вызовов и профили AppArmor/SELinux для принудительного контроля доступа (MAC) к файлам и сетевому доступу.
Почему: Эти встроенные функции безопасности Linux обеспечивают глубокий уровень защиты, ограничивая то, что может фундаментально делать скомпрометированный процесс контейнера.
Уменьшение поверхности атаки внутри образа контейнера.
Создавать образы приложений, используя минимальные или "бесдистровые" базовые образы, которые содержат только приложение и его прямые зависимости.
Почему: Удаляет оболочки, менеджеры пакетов и другие утилиты, которые не нужны для production и могут быть использованы злоумышленником после компрометации.
Проверка соответствия конфигурации кластера Kubernetes передовым методам обеспечения безопасности.
Регулярно запускать `kube-bench`, автоматизированный инструмент, который проверяет кластер на соответствие стандарту CIS Kubernetes Benchmark.
Почему: Предоставляет стандартизированный, всеобъемлющий и автоматизированный способ аудита состояния безопасности кластера и выявления неправильных конфигураций.
Кластер должен обрабатывать и хранить данные кредитных карт в соответствии с PCI DSS.
Использовать NetworkPolicies для сегментации сети, чтобы изолировать среду данных держателей карт (CDE), и включить шифрование данных в состоянии покоя для etcd.
Почему: Эти меры контроля напрямую соответствуют требованиям PCI DSS по сегментации сети (Требование 1) и защите хранимых данных держателей карт (Требование 3).
Кластер обрабатывает защищенную медицинскую информацию (PHI) и должен соответствовать HIPAA.
Внедрить строгий RBAC, включить комплексное ведение журналов аудита и обеспечить шифрование данных как в состоянии покоя, так и при передаче.
Почему: Эти меры контроля касаются технических средств защиты HIPAA для контроля доступа, аудита и безопасности передачи данных.
Обеспечение сохранности аудитных журналов для соблюдения требований и судебной экспертизы, даже в случае компрометации кластера.
Настроить API-сервер для потоковой передачи аудитных журналов во внешний, одноразово записываемый/неизменяемый бэкенд для журналирования (например, SIEM или заблокированный облачный бакет хранения).
Почему: Предотвращает заметание следов злоумышленником с привилегиями cluster-admin путем изменения или удаления локальных аудитных журналов.