Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене CKS. Читайте сверху вниз или переходите к нужному разделу.
Оценка конфигурации кластера на соответствие отраслевым стандартам безопасности.
Используйте `kube-bench` для выполнения проверок CIS Kubernetes Benchmark для узлов уровня управления и рабочих узлов.
Почему: `kube-bench` - это стандартный инструмент для этой конкретной задачи, автоматизирующий проверки на соответствие всеобъемлющим рекомендациям CIS.
Обеспечение строгой аутентификации для всех запросов к API-серверу.
Установите флаги `kube-apiserver`: `--anonymous-auth=false` для отклонения неаутентифицированных запросов и `--client-ca-file` для принудительной проверки клиентских сертификатов (mTLS).
Почему: Эти флаги являются фундаментальными средствами контроля для исключения анонимного доступа и обеспечения аутентифицированной, зашифрованной связи с API-сервером.
Защита хранилища состояния etcd кластера от несанкционированного доступа и кражи данных.
Настройте etcd с mTLS для всей клиентской и пиринговой связи (`--cert-file`, `--key-file`, `--peer-cert-file`). Включите шифрование секретов в состоянии покоя с помощью флага `--encryption-provider-config` API-сервера.
Почему: etcd содержит все секреты кластера. Шифрование данных при передаче (mTLS) и в состоянии покоя критически важно для защиты конфиденциальной информации, даже если узлы etcd скомпрометированы.
Ротация ключей шифрования etcd в состоянии покоя без простоя.
1. Добавьте новый ключ в качестве первой записи в файл `EncryptionConfiguration`. 2. Перезапустите все API-серверы. 3. Принудительно повторно зашифруйте все секреты (`kubectl get secrets -A -o json | kubectl replace -f -`). 4. После проверки удалите старый ключ из конфигурации и снова перезапустите API-серверы.
Почему: Изменение конфигурации влияет только на новые записи. Существующие данные должны быть перезаписаны для шифрования новым ключом. Преждевременное удаление старого ключа заблокирует доступ к вашим данным.
Реализация сетевой модели с нулевым доверием в рамках пространства имен.
Примените `NetworkPolicy` с пустым `podSelector: {}` и `policyTypes: [Ingress, Egress]`, но без правил `ingress` или `egress`. Это выбирает все поды и запрещает весь трафик.
Почему: Эта политика устанавливает базовый уровень "запретить все", принуждая к явным правилам "разрешить" для всей необходимой связи, что является основой сети с нулевым доверием.
Сетевые политики исходящего трафика (Egress NetworkPolicies) блокируют разрешение DNS для подов.
Добавьте специальное правило исходящего трафика, чтобы разрешить трафик к службе DNS кластера. Разрешите исходящий трафик на порт 53 по протоколам UDP и TCP. По возможности выберите поды kube-dns с помощью `namespaceSelector` и `podSelector`.
Почему: Сетевые политики являются детализированными. Общее правило исходящего трафика для блока IP может не охватывать конкретный протокол (UDP), необходимый для DNS, что приводит к сбоям разрешения.
Защита внешнего доступа к службам, предоставляемым через Ingress.
Настройте ресурс Ingress, добавив раздел `tls`, который ссылается на секрет Kubernetes типа `kubernetes.io/tls`. Секрет должен содержать TLS-сертификат и закрытый ключ.
Почему: Это централизует завершение TLS на контроллере Ingress, шифруя трафик от клиентов до границы кластера и упрощая управление сертификатами для бэкенд-сервисов.
Предоставляйте пользователям или приложениям только минимально необходимые разрешения.
По возможности используйте `Roles` и `RoleBindings` с ограничением по пространству имен. Избегайте `cluster-admin` и подстановочных знаков (`"*"`) в `verbs` или `resources`. Предоставляйте конкретные разрешения, такие как `["get", "list"]` для `["pods"]`.
Почему: Это минимизирует радиус поражения в случае компрометации учетной записи или токена, предотвращая горизонтальное перемещение и повышение привилегий.
Уменьшение поверхности атаки для подов, которым не требуется взаимодействовать с Kubernetes API.
Отключите автоматическое монтирование токенов учетных записей служб, установив `automountServiceAccountAccountToken: false` в ServiceAccount или в спецификации пода.
Почему: Если под скомпрометирован, злоумышленник не сможет использовать смонтированный токен для доступа к API-серверу, предотвращая атаки на уровне кластера, исходящие из скомпрометированного пода.
Проверка наличия у конкретного пользователя или учетной записи службы разрешения на выполнение действия.
Используйте `kubectl auth can-i <verb> <resource> --as=<user>` или `kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa-name>`.
Почему: Эта команда позволяет олицетворять пользователя для точной проверки действующих разрешений без необходимости вручную анализировать все роли и привязки.
Поддержание безопасности кластера путем регулярной ротации сертификатов уровня управления и kubelet.
Для кластеров kubeadm используйте `kubeadm certs renew all`. Для других следуйте документированной ручной или автоматизированной процедуре ротации. Включите ротацию клиентских/серверных сертификатов kubelet через его конфигурацию.
Почему: Регулярная ротация ограничивает временное окно, в течение которого злоумышленник может использовать скомпрометированный сертификат. Это критически важная практика гигиены безопасности.
Рабочий узел подозревается в компрометации и должен быть немедленно изолирован.
Сначала используйте `kubectl cordon <node-name>`, чтобы предотвратить планирование новых подов. Затем используйте `kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data`, чтобы безопасно вытеснить запущенные рабочие нагрузки.
Почему: Отключение и опустошение - это стандартная, неразрушающая процедура для вывода узла из эксплуатации, позволяющая перепланировать рабочие нагрузки в другом месте, сохраняя скомпрометированный узел для криминалистического анализа.
Ограничение системных вызовов, которые контейнер может делать к ядру хоста.
В `securityContext` пода или контейнера установите `seccompProfile.type` в `RuntimeDefault` для безопасного базового уровня или `Localhost` с путем к настраиваемому JSON-профилю для более строгого контроля.
Почему: Seccomp уменьшает поверхность атаки ядра изнутри контейнера, предотвращая эксплойты уязвимостей ядра путем блокировки неиспользуемых или опасных системных вызовов.
Ограничение процессов контейнера путем ограничения доступа к файлам, сетевым возможностям и другим ресурсам.
Примените профиль AppArmor к контейнеру с помощью аннотации: `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. Профиль должен быть предварительно загружен на узел.
Почему: AppArmor предоставляет обязательный контроль доступа (MAC), добавляя критически важный уровень глубокой защиты для сдерживания скомпрометированного приложения и предотвращения его доступа к несанкционированным ресурсам.
Контейнеру требуется определенная привилегированная операция (например, привязка к порту 80) без запуска от имени root.
В `securityContext.capabilities` используйте `drop: ["ALL"]`, а затем `add: ["NET_BIND_SERVICE"]`.
Почему: Это следует принципу наименьших привилегий, предоставляя только конкретную необходимую возможность Linux, избегая широких разрешений при запуске от имени root.
Предотвращение получения контейнером полного доступа к хост-системе.
Установите `securityContext.privileged: false` (что является значением по умолчанию). Используйте Pod Security Standards или OPA/Kyverno для обеспечения этого в масштабах всего кластера.
Почему: Привилегированный контейнер имеет почти все возможности хоста и доступ к устройствам, фактически отключая изоляцию контейнера. Это основной вектор для побега из контейнера.
Обеспечение базовых или строгих конфигураций безопасности для подов на уровне пространства имен.
Примените метки к пространству имен, например, `pod-security.kubernetes.io/enforce: restricted`. Режимы: `enforce`, `audit` и `warn`.
Почему: Pod Security Standards (PSS) предоставляют встроенную многоуровневую политику безопасности, которая заменяет устаревшую PodSecurityPolicy, упрощая применение передовых методов обеспечения безопасности.
Укрепление пода путем одновременного применения нескольких мер безопасности.
Настройте `securityContext`, который объединяет `runAsNonRoot: true`, `allowPrivilegeEscalation: false` и `readOnlyRootFilesystem: true`.
Почему: Этот подход "глубокой защиты" накладывает несколько уровней защиты: предотвращение выполнения от имени root, блокирование векторов повышения привилегий (таких как setuid) и обеспечение неизменяемости файловой системы контейнера.
Запуск недоверенных или многопользовательских рабочих нагрузок с более сильной изоляцией, чем у стандартных контейнеров.
Определите ресурс `RuntimeClass`, указывающий на обработчик изолированной среды выполнения (например, gVisor, Kata Containers). Назначьте поды ему, используя `spec.runtimeClassName`.
Почему: Изолированные среды выполнения используют пользовательское ядро или легковесные виртуальные машины для перехвата системных вызовов, обеспечивая дополнительный уровень изоляции между контейнером и ядром хоста.
Обеспечение сложных, пользовательских политик безопасности, которые не охватываются стандартными элементами управления Kubernetes.
Разверните OPA Gatekeeper. Определите политики с помощью `ConstraintTemplate` (логика Rego) и примените их с помощью ресурсов `Constraint`.
Почему: Gatekeeper действует как проверяющий веб-хук допуска, позволяя применять произвольные правила, такие как требование определенных меток, запрет путей хоста или принудительное применение ограничений ресурсов.
Предоставление секретов подам наиболее безопасным способом.
Монтируйте секреты как файлы в том. Для еще большей безопасности используйте драйвер CSI хранилища секретов для монтирования секретов из внешнего хранилища (например, HashiCorp Vault, AWS Secrets Manager) непосредственно в под.
Почему: Монтирование в виде файлов безопаснее, чем переменные среды (которые могут быть записаны в лог или раскрыты). Драйвер CSI вообще позволяет избежать хранения секрета в etcd.
Автоматическое шифрование и аутентификация всего сетевого трафика между подами.
Разверните сервисную сетку, такую как Istio или Linkerd. Сетка внедряет прокси-сервер-сайдкар в каждый под для обработки шифрования mTLS, аутентификации и применения политик.
Почему: Сервисная сетка обеспечивает прозрачную сеть с нулевым доверием, не требуя изменений в коде приложения, обеспечивая безопасность всей внутренней связи между службами.
Предотвращение развертывания образов контейнеров с известными уязвимостями (CVE).
Интегрируйте сканер, такой как Trivy или Grype, в конвейер CI/CD. Прерывайте сборку, если количество уязвимостей превышает определенный порог серьезности (например, HIGH или CRITICAL).
Почему: Этот подход "сдвига влево" выявляет уязвимости на ранних стадиях, до того как они достигнут продакшена, значительно уменьшая поверхность атаки запущенных приложений.
Обеспечение развертывания в кластере только доверенных, неизмененных образов контейнеров.
Подписывайте образы с помощью `cosign` во время процесса сборки CI. Используйте движок политик (Kyverno, OPA Gatekeeper) в качестве контроллера допуска для проверки подписи по открытому ключу, прежде чем разрешить создание пода.
Почему: Криптографическая подпись обеспечивает надежные гарантии целостности образа (он не был изменен) и подлинности (он пришел из доверенного источника).
Минимизация поверхности атаки внутри самого образа контейнера.
Используйте минимальные базовые образы (например, distroless, Alpine). Используйте многоступенчатый Dockerfile для удаления инструментов сборки. Установите пользователя без прав root с помощью инструкции `USER`. Используйте `.dockerignore` для исключения конфиденциальных файлов.
Почему: Минимальный образ содержит меньше пакетов и инструментов, что означает меньше потенциальных уязвимостей и затрудняет злоумышленнику перенаправление атаки в случае компрометации контейнера.
Применение политики, согласно которой все развертываемые образы должны исходить из частного реестра организации.
Используйте контроллер допуска (например, OPA Gatekeeper или Kyverno) для создания политики, которая проверяет поле `image` всех спецификаций контейнеров на соответствие белому списку имен хостов реестров.
Почему: Это предотвращает извлечение разработчиками недоверенных или непроверенных образов из публичных репозиториев, таких как Docker Hub, гарантируя, что весь код прошел внутренние проверки безопасности.
Ведение инвентаризации всех программных компонентов и зависимостей в образе контейнера.
Интегрируйте инструмент, такой как `Syft`, в конвейер CI/CD для генерации спецификации программного обеспечения (SBOM) в стандартном формате, таком как SPDX или CycloneDX.
Почему: SBOM необходим для безопасности цепочки поставок, позволяя быстро идентифицировать все затронутые активы при обнаружении новой уязвимости в зависимости.
Выявление неправильных настроек безопасности в манифестах Kubernetes YAML до их применения.
В конвейере CI используйте инструмент, такой как `trivy config` или `kubesec`, для сканирования файлов манифестов Kubernetes на наличие рискованных конфигураций, таких как запуск от имени root, разрешение повышения привилегий или монтирование конфиденциальных путей хоста.
Почему: Эта проактивная проверка выявляет проблемы безопасности в инфраструктуре как коде до того, как они создадут уязвимости в работающем кластере.
Обнаружение и оповещение о подозрительной активности внутри запущенных контейнеров или на узлах кластера.
Разверните Falco как DaemonSet. Falco использует eBPF или модуль ядра для мониторинга системных вызовов и оповещает об аномальном поведении на основе своего набора правил (например, оболочка в контейнере, неожиданные сетевые подключения).
Почему: Falco обеспечивает видимость поведения во время выполнения в режиме реального времени, позволяя обнаруживать такие угрозы, как побеги из контейнеров, криптомайнинг или эксфильтрация данных, которые статическое сканирование не может выявить.
Правило Falco по умолчанию генерирует слишком много ложных срабатываний.
Создайте пользовательский файл правил Falco для переопределения правила по умолчанию. Добавьте исключения в `condition` правила, чтобы исключить заведомо корректное поведение, такое как определенные процессы или образы контейнеров (например, `and not container.image.repository contains "debug"`).
Почему: Настройка правил критически важна для практического применения безопасности во время выполнения. Уменьшение шума гарантирует, что команды безопасности смогут сосредоточиться на действенных, высокоприоритетных оповещениях.
Запись хронологического, неизменяемого журнала всех действий, выполненных в отношении Kubernetes API.
Включите аудит логирования на `kube-apiserver`, предоставив флаги `--audit-policy-file` и `--audit-log-path`. Настройте политику, чтобы определить, что и на каком уровне регистрируется.
Почему: Журналы аудита необходимы для анализа безопасности, расследования инцидентов и соответствия требованиям. Они предоставляют окончательную запись о том, кто что сделал и когда.
Аудит доступа к конфиденциальным ресурсам, таким как Секреты, без регистрации самого содержимого секрета.
Настройте правило политики аудита для Секретов на использование `level: Metadata`. Это регистрирует пользователя, временную метку, ресурс и действие, но пропускает тела запроса и ответа.
Почему: Это обеспечивает подотчетность за то, кто получает доступ к секретам, не создавая при этом нового риска безопасности путем записи конфиденциальных данных в журналы аудита.
Агрегирование журналов от всех компонентов кластера и приложений для централизованного анализа.
Разверните агент сбора журналов (например, Fluentd, Vector) как DaemonSet для сбора журналов с узлов и их пересылки в централизованную систему SIEM или систему управления журналами (например, Elasticsearch, Splunk).
Почему: Централизованное логирование критически важно для корреляции событий по всему кластеру во время расследования инцидентов и для ведения долгосрочных записей для соблюдения требований.
Пересылка оповещений безопасности Falco во внешнюю систему для уведомления и реагирования.
Разверните `Falcosidekick` вместе с Falco. Настройте его на получение оповещений от Falco и их пересылку в такие системы, как Slack, PagerDuty или SIEM.
Почему: Falcosidekick предоставляет гибкий и надежный механизм для интеграции оповещений Falco в реальном времени в существующие операционные процессы и рабочие процессы безопасности.
Обнаружение модификации запущенного контейнера, что может указывать на компрометацию.
Обеспечьте неизменяемость контейнеров с помощью `readOnlyRootFilesystem: true`. Используйте инструмент безопасности во время выполнения, такой как Falco, для мониторинга и оповещения о любых записях файлов в неожиданные места.
Почему: В неизменяемой модели контейнеры никогда не изменяются во время выполнения; они заменяются. Любое отклонение от этого шаблона является сильным индикатором потенциального нарушения безопасности.