hardening

«Kubernetes стал стандартом для контейнерных приложений, но стандартные настройки «из коробки» далеки от идеала безопасности. В отчётах CIS Benchmark содержится более 300 рекомендаций. Без автоматизации ручная проверка занимает недели. При этом многие уязвимости — это просто неправильно выставленные флаги или забытые политики. Злоумышленники сканируют интернет-кластеры и находят открытые порты, анонимный доступ, избыточные права. Наша задача — системно закрыть эти риски, сохранив работоспособность.» «Мы проводим комплексную оценку безопасности вашего кластера на всех уровнях: — инфраструктурный слой (узлы, компоненты управления), — объектный слой (роли, политики, сетевые правила), — прикладной слой (образы контейнеров, конфигурации). На основе аудита разрабатываем детальный план усиления, внедряем исправления и передаём документированный, готовый к сертификации кластер. Всё — с минимальным влиянием на бизнес-процессы.» Инструментарий — обзор Мы используем открытые, признанные в индустрии инструменты. Они дают объективную картину и не требуют установки агентов на узлы. Вот наш основной набор: - kube-bench — эталонный сканер конфигураций по CIS Kubernetes Benchmark. Проверяет API Server, etcd, контроллеры, kubelet, права на файлы, сетевые порты. Выдаёт отчёт с пометками PASS, FAIL, WARN. - Kubescape — сканирует сам кластер через API. Анализирует RBAC-роли и привязки, securityContext подов, наличие и корректность Network Policies, сервисные аккаунты. Оценивает соответствие стандартам CIS, NSA и MITRE ATT&CK. - Trivy — сканирует образы контейнеров на известные CVE-уязвимости и проверяет манифесты на ошибки конфигурации. Показывает проблемы на уровне приложений. - kube-hunter — активный пентест-инструмент, пытается эксплуатировать найденные уязвимости, имитирует атаки. - netfetch — специализированный инструмент для анализа сетевых политик: показывает, какие поды защищены, а какие нет, визуализирует сетевую карту. - Network Policy Assistant (npa) — анализирует существующие сетевые политики на дублирование, избыточность, пересечения и предлагает их оптимизацию. - k8scout (опционально) — выявляет пути эскалации привилегий, показывая, как из пода можно получить cluster-admin. - Falco, Kyverno, OPA/Gatekeeper — используются на этапе пост-проектной настройки для enforcement политик в рантайме и при деплое. Сегодня мы на живом кластере покажем весь цикл: сканирование, анализ, исправление и повторную проверку. Мы увидим, как за несколько минут получить полную картину и быстро закрыть типичные проблемы. Аудит инфраструктуры через kube-bench kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml kubectl logs kube-bench-tf5ql > kube-bench-report-$(date +%Y%m%d).txt Мы видим разделы для API Server, etcd, Controller Manager, Scheduler, kubelet. Каждый FAIL — это конкретное нарушение, например, включённый анонимный доступ или разрешённые привилегированные контейнеры. Итоговая сводка показывает общую картину. Это наш фундамент для плана харденинга. Аудит объектов кластера через Kubescape (5 минут) curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash kubescape scan 2>&1 | tee kubescape-report.txt kubescape scan - Показать фрагмент отчёта: например, разделы с RBAC, Network Policies, securityContext. «Kubescape дополняет kube-bench, потому что он проверяет не то, что лежит на диске, а то, что реально работает в кластере. Он найдёт, например, сервисные аккаунты с правами cluster-admin, поды без ограничений securityContext, отсутствие сетевых политик в пространствах имён с приложениями. Это уже объектный слой безопасности.» ________________________________________ «Мы увидели, что kube-bench находит базовые проблемы на уровне инфраструктуры, а Kubescape — на уровне объектов кластера (RBAC, сетевые политики, безопасность подов). В рамках нашей услуги мы используем оба инструмента и дополнительные (netfetch, Trivy, kube-hunter), чтобы дать полную картину. Затем мы исправляем все FAIL и критические WARN, повторно сканируем и предоставляем отчёт, который доказывает соответствие стандартам CIS, NSA и ФСТЭК.» Сетевой аудит с netfetch и npa netfetch scan - Показать вывод: сколько подов без политик, визуализация. -Сетевая безопасность часто остаётся за кадром. Netfetch показывает, какие поды вообще не защищены политиками. Сканирование образов и уязвимостей (Trivy) curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin trivy k8s --include-namespaces default --report summary запускать не будем – десятки минут - Показать найденные CVE, особенно критические. Не только инфраструктура, но и приложения могут быть уязвимы. Trivy показывает, что даже популярные образы содержат известные уязвимости. В рамках услуги мы настраиваем автоматическое сканирование образов при деплое. шаг 6: Итоговый отчёт и документация **Действие на экране:** - Показать шаблон итогового отчёта: титульный лист, сводка результатов (до/после), детальный список всех проверок с комментариями, рекомендации по устранению для каждой проблемы, план мероприятий с приоритетами. - Показать примеры политик безопасности, которые мы передаём (Pod Security Standards, Network Policy шаблоны, RBAC-роли). **Текст ведущего:** > «Мы не просто фиксим — мы документируем. Отчёт готов для внутреннего аудита или для регуляторов, таких как ФСТЭК. Вместе с отчётом передаём шаблоны политик, инструкции по эксплуатации и проводим обучение вашей команды.» Kube-bench - **Worker Node Security Configuration** (проверки на узлах) - **Kubernetes Policies** (проверки на уровне объектов кластера) - Итоговые сводки по каждому разделу и общая. - **PASS** — настройка соответствует рекомендации, проблем нет. - **FAIL** — нарушение, которое **нужно исправить** (автоматизированная проверка). - **WARN** — требует **ручной проверки** или не может быть проверен автоматически, но это не менее важно. #### По разделу Worker Node (инфраструктурный слой) **FAIL (2 шт.) — это самые критичные, их мы показываем в демо как «проблемы, которые мы исправляем»:** 1. **4.1.1** — права на файл службы kubelet должны быть 600 или строже. У вас, скорее всего, права 644 или 755. Это позволяет другим пользователям читать файл, что может привести к утечке параметров запуска. *Исправление:* на каждом воркер-ноде выполнить `chmod 600 /lib/systemd/system/kubelet.service` (путь может отличаться, смотрите в remediation). 2. **4.1.9** — файл конфигурации kubelet (`/var/lib/kubelet/config.yaml`) имеет неправильные права (должны быть 600). *Исправление:* `chmod 600 /var/lib/kubelet/config.yaml` на каждом воркер-ноде. **WARN (7 шт.) — требуют ручной проверки, но тоже важны:** - 4.1.3, 4.1.4 — если есть proxy kubeconfig, нужно проверить права и владельца. - 4.2.9 — TLS-сертификаты и ключи должны быть указаны. - 4.2.12 — нужно использовать сильные шифры (TLS). - 4.2.13 — ограничение на количество PID на под. - 4.2.14 — включение seccomp по умолчанию. - 4.2.15 — настройка IPAddressDeny. #### По разделу Policies (объектный слой) Здесь **все проверки — WARN (35 шт.)**, потому что это ручные проверки, но они показывают, что **кластер не соответствует лучшим практикам безопасности на уровне RBAC, Pod Security, Network Policies, Secrets и т.д.** Это как раз та часть, которую мы закрываем с помощью Kubescape, netfetch, политик и т.д. **На что обратить внимание (это показываем на демо):** - **5.1.1** — cluster-admin используется там, где не нужно — это критично. - **5.1.2** — доступ к секретам должен быть минимальным. - **5.1.7** — использование группы system:masters (почти всегда плохо). - **5.2.2 – 5.2.13** — отсутствие ограничений на привилегированные контейнеры, hostNetwork, hostPID, capabilities и т.д. — это классика. - **5.3.2** — нет Network Policies во всех namespace — это мы показываем через netfetch. - **5.4.2** — рекомендуется использовать внешнее хранилище секретов (например, HashiCorp Vault) — это опционально, но показывает, что мы можем настроить. 1. **Проблемы на уровне узлов (FAIL)** — это легко исправить, и мы это делаем быстро (демонстрируем `chmod` и повторный запуск). 2. **Проблемы на уровне объектов (WARN)** — они не менее опасны, но их сложнее найти вручную. Мы показываем, что **Kubescape** и **netfetch** дают более детальную картину по этим WARN. 3. **Итоговую сводку** — 17 PASS, 2 FAIL, 42 WARN. Это показывает, что кластер далёк от идеала, и наша услуга необходима. - **Шаг 1:** Запустить kube-bench (вы уже сделали) и показать отчёт. - **Шаг 2:** Выбрать один FAIL, например, 4.1.9 (права на config.yaml). Показать, как исправить (`chmod 600`). Повторно запустить kube-bench и показать, что FAIL стал PASS. - **Шаг 3:** Запустить Kubescape, чтобы показать WARN из раздела Policies (например, RBAC, Pod Security). Сравнить, что Kubescape находит ещё больше проблем, которые kube-bench только предупреждает. - **Шаг 4:** Запустить netfetch, чтобы показать отсутствие Network Policies — это особенно наглядно. - **Шаг 5:** Подвести итог: мы не просто показываем отчёт, а даём план и исправляем всё системно. Интерпретация результатов Kubescape для демо Ваш отчёт содержит множество разделов. Давайте разберём самое важное — то, что мы будем показывать security-команде. Общая оценка безопасности • MITRE: 67.37% — не очень высоко, есть куда расти. • NSA: 63.57% — аналогично. Это отличный аргумент: кластер не соответствует даже базовым рекомендациям от NSA и MITRE. Мы можем это исправить. Раздел «Control plane» (плоскость управления) Здесь выделяются критические FAIL: • Audit logs enabled — ❌ аудит-логи не включены. Это нарушает требования многих регуляторов (ФСТЭК в том числе). • PSP enabled — ❌ PodSecurityPolicy не включена (или Pod Security Admission не настроена). Это означает, что можно запускать привилегированные контейнеры. • Secret/etcd encryption enabled — ❌ секреты не зашифрованы в etcd. Это критично для безопасности данных. ⚠️ Важно: эти FAIL не отображались в kube-bench в явном виде (там были только WARN), но Kubescape их чётко выделяет. Это показывает добавленную ценность Kubescape — он находит то, что kube-bench только предупреждает. Раздел «Access control» (RBAC) Здесь много ресурсов, у которых избыточные права. Наиболее показательные: • Access container service account — 39 ресурсов. Это означает, что многие поды используют сервисные аккаунты с правами, которых им не нужно. • Administrative Roles — 2 ресурса. Это могут быть роли cluster-admin, которые используются не по назначению. • List Kubernetes secrets — 18 ресурсов имеют право читать секреты. Это очень опасно. Это мы будем показывать как пример нарушения принципа наименьших привилегий. Раздел «Network» • Missing network policy — 35 ресурсов (подов или namespace) не имеют сетевых политик. Это означает, что весь трафик внутри кластера разрешён по умолчанию. • Ingress and Egress blocked — 33 ресурса, у которых нет ограничений на входящий/исходящий трафик. Это идеально для демонстрации netfetch — вы покажете визуализацию отсутствующих политик и затем добавите одну политику, чтобы показать улучшение. Раздел «Node escape» (эскалация привилегий) • Allow privilege escalation — 30 ресурсов, у которых разрешено повышение привилегий. • Privileged container — 1 контейнер запущен в привилегированном режиме. • Non-root containers — 22 контейнера, которые не настроены на запуск от non-root пользователя. Это прямые угрозы безопасности — злоумышленник может выйти из контейнера на хост. Раздел «Secrets» • Applications credentials in configuration files — 3 ресурса, где секреты (пароли, токены) хранятся в ConfigMap или в переменных окружения в открытом виде. • Automatic mapping of service account — 44 ресурса, где сервисный аккаунт монтируется автоматически, даже если это не нужно. Это показывает, что секреты используются небезопасно. «Highest-stake workloads» — наиболее критичные рабочие нагрузки Kubescape подсвечивает, что ingress-nginx-controller, argocd-server и simple-app — это самые рискованные компоненты, потому что они имеют широкий доступ или высокую критичность. В демо вы можете сфокусироваться на одном из них (например, simple-app) и показать, как мы исправляем его securityContext или добавляем Network Policy. Netfetch сканирует все пространства имён (namespace) и находит поды, к которым не применена ни одна NetworkPolicy. Это означает, что весь трафик между этими подами разрешён по умолчанию — как внутри одного namespace, так и между разными namespace (если нет политик, ограничивающих кросс-неймспейсовый трафик). В вашем кластере таких подов очень много — и это касается не только тестовых сред, но и production-компонентов. ________________________________________ Детальная статистика по namespace Namespace Количество подов без политик Комментарий codescoring 21 Это, судя по названию, основное приложение (анализ кода, сканирование). Все компоненты — бекенд, фронтенд, Celery, судья, PgBouncer, PostgreSQL, Redis — полностью открыты. default 3 Включая simple-app (тестовое приложение) и test-netcat (утилита для отладки). demo-app 1 guestbook-ui — демонстрационное приложение. ingress-nginx 1 Контроллер Ingress — критичный компонент, который принимает трафик извне. Без политики он может быть скомпрометирован и дать доступ ко всему кластеру. local-path-storage 1 Провизионер локальных томов — тоже системный компонент. metallb-system 6 Контроллер и спикеры MetalLB — компоненты, управляющие внешними IP-адресами. Если их взломать, можно перенаправить трафик. Итого: 33 пода находятся в зоне риска. ________________________________________ Почему это опасно (для объяснения на демо) 1. Горизонтальное перемещение — злоумышленник, получивший доступ к одному поду (например, через уязвимость в веб-приложении), может свободно общаться с любым другим подом в кластере, включая базы данных, кеши, системные компоненты. 2. Доступ к критическим данным — PostgreSQL и Redis в codescoring не защищены. Любой под в том же namespace может подключиться к ним, даже если это не предусмотрено архитектурой. 3. Компрометация инфраструктурных компонентов — Ingress-контроллер и MetalLB являются «входными воротами». Если их не изолировать, атакующий может подменить маршрутизацию или перехватить трафик. 4. Нарушение требований регуляторов — ФСТЭК, CIS Benchmark, PCI DSS требуют сегментации сети и ограничения трафика. Отсутствие Network Policies — прямое нарушение (CIS 5.3.2, Kubescape C-0260). Что показывает отчёт Trivy Вы получили сводку по трём объектам в namespace default: Ресурс Уязвимости (CVE) Misconfiguration (ошибки конфигурации) Deployment/simple-app 0 HIGH: 3, MEDIUM: 5, LOW: 7 Job/kube-bench HIGH: 11, MEDIUM: 17, LOW: 30, UNKNOWN: 2 HIGH: 4, MEDIUM: 5, LOW: 11 Pod/test-netcat 0 HIGH: 5, MEDIUM: 7, LOW: 21 Ошибка про образ harbor.obr.local/test/simple-app:775a340c возникла потому, что Trivy не смог найти этот образ локально (он в приватном реестре с проблемами сертификата). Но это не помешало сканированию — misconfiguration были обнаружены. ________________________________________ Интерпретация для демо 1. Misconfiguration — это серьёзно. Даже если в образе нет уязвимостей, неправильные настройки (например, запуск от root, открытые порты, отсутствие ограничений ресурсов) делают кластер уязвимым. Trivy находит такие проблемы. 2.