> For the complete documentation index, see [llms.txt](https://book.konstantinsecurity.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.konstantinsecurity.com/readme/architect/kubernetes/security-center/security-senter-for-kubernetes.md).
# Security Сenter for Kubernetes
Эта статья будет полезна специалистам по безопасности и DevSecOps, платформенным командам и DevOps, и вообще всем, кто сталкивался или может столкнуться с более, чем одним кластером Kubernetes в продакшене.
За основу взято выступление Алексея Миртова на HighLoad++ Foundation 2022. Он является экспертом и архитектором по безопасности внутри Yandex Cloud. Занимается облачными технологиями больше 10 лет, обладает экспертизой по безопасности в сетях и контейнерах. Построил цикл безопасной разработки в команде 400+ разработчиков для IT-системы на базе Kubernetes в облаке, спроектировал и реализовал Security Operation Center в Казахстане. Доклад готовил вместе с Нареком Татевосяном, экспертом и адвокатом по Kubernetes в Яндексе и соведущим YouTube канала [Yandex Cloud](https://youtube.com/c/YandexCloudPlatform).
Речь пойдет о том, как:
* Эксплуатировать парк «безопасных» кластеров Kubernetes: создавать и обновлять кластеры, утилиты, сервисы безопасности
* Правильно управлять платформенными инструментами и инструментами безопасности.
* В рамках статьи будут предоставлены гайдлайны, материалы, решения, как делать кластеры «безопасными».
**Внимание!** В статье не будет рассказываться как строить безопасность приложений (SAST, DAST и др.) и работать со SBOM, проверять подписи (cosign и др.).
### Проблема безопасности кластеров
Когда компания растёт, увеличивается и число кластеров Kubernetes. Темпы роста могут отличаться: например, в Яндексе добавляется по одному кластеру на один бизнес-юнит с независимыми DevOps-инженерами, а у некоторых их заказчиков — по нескольку кластеров на каждую бизнес-команду. В качестве хорошего примера, давайте посмотрим [доклад](https://www.youtube.com/watch?v=8jf7AHCxBmA) про проект Nautilus. Коллеги из университета Сан-Диего развернули огромный кластер для нужд разработки и вычислений со стороны ученых и студентов. Но затем были вынуждены его децентрализовать и развернуть множество кластеров, чтобы у каждой команды был собственный [namespace](https://kubernetes.io/ru/docs/concepts/overview/working-with-objects/namespaces/) (пространство имён) для всех процессов и они могли самостоятельно его администрировать.
Что странно, в этом докладе не было ни слова про безопасность. Ведь даже если вы имеете право администрировать только свой namespace Kubernetes, ничто не мешает вам развернуть в нём привилегированный контейнер. Такой контейнер сможет выйти за пределы ноды и скомпрометировать весь кластер. Это огромная проблема для безопасности, поэтому давайте поговорим о том, как не создавать таких уязвимостей.
### Что такое безопасный кластер?
Признаки безопасности кластера Kubernetes:
**Безопасные настройки.** Кластер должен быть настроен в соответствии с каким-нибудь гайдлайном, например [CIS Benchmark](https://www.cisecurity.org/cis-benchmarks/) или другими стандартами, в нём должно быть включено шифрование, аудит и т.д.
**Находится в безопасно настроенной среде.** Даже если настройки кластера правильные, а среда настроена с уязвимостями или открыты все порты, любой может зайти и удалить кластер.
**Есть минимально необходимый набор инструментов безопасности внутри кластера**, интегрированный с корпоративными системами. Именно минимально необходимый, потому, что кластер может быть вообще без выхода в интернет, тогда угрозы не актуальны и можно снизить количество инструментов безопасности.
### Как безопасно деплоить кластеры
Процесс деплоя и эксплуатации можно разложить на такие блоки:
* Сервис получения кластеров Kubernetes. Например, с помощью Terraform;
* Платформенные инструменты и инструменты безопасности, работающие параллельно друг с другом;
* Приложения — ради их запуска и используют Kubernetes.
Безопасный деплой кластеров нужен, чтобы получить единую версионированную базу данных всех кластеров Kubernetes, их настроек и инструментов безопасности. А так же автоматику, которая создает, обновляет и настраивает кластеры из этой базы данных и автоматизированные security-проверки конфигурации до раскатки и после.
Рассмотрим некоторые популярные схемы деплоя.
### Схема деплоя Time to market mode (push)
Это GitOps push модель, её «пушат» прямо в кластер. Например, когда вы создаете pull request, его подхватывает CI/CD система, например, GitLab или Jenkins. Она реагирует на него и после этого выполняет, например [Terraform Apply](https://www.terraform.io/cli/commands/apply) и создаёт кластеры для ваших команд. Получается так называемый кластер pipeline. Вот как это выглядит:
Ниже могут следовать security pipeline и platform pipeline с инструментами для этих потребностей. Каждое событие порождает реакцию CI/CD системы. Она делает [Helm install](https://helm.sh/docs/helm/helm_install/) или [Kubectl apply](https://kubernetes.io/ru/docs/reference/kubectl/cheatsheet/), и устанавливает эти инструменты в несколько ваших кластеров — один и более.
**Преимущества:**
Это самый быстрый, проверенный в бою способ.
Идеален для одного проекта.
**Минусы**:
Необходимость ручных операций. Автоматизировать все процессы — не выйдет\*\*.\*\*
Риск Configuration drift — ситуации, когда фактическое состояние системы отличается от первоначального предполагаемого состояния из-за несовместимости элементов. Например, кто-то вручную зашел в Kubernetes кластер, изменил настройки и в результате появилась разница между настройками кластера и настройками репозитория.
Отсутствие visibility.
Открытие входящих сетевых соединений.
### Схема деплоя Kubernetes GitOps mode (pull)
В этой модели вы ничего не пушите в кластер. Он сам подтягивает (git pull) изменения. Например, у вас есть управляющий кластер Kubernetes с установленным в нём GitOps инструментом непрерывной доставки [Argo CD](https://argo-cd.readthedocs.io/en/stable/) или опенсорсным решением [Spinnaker](https://spinnaker.io/). В этом случае кластер pipeline остается без изменений, ведь кластеры раскатываются с помощью платформы [Terraform](https://www.terraform.io/), которая представляет инфраструктуру как код. А [Argo CD](https://argo-cd.readthedocs.io/en/stable/) самостоятельно подтягивает платформенные инструменты и инструменты безопасности каждые 3 секунды и меняет настройки в соответствии с этими изменениями.
**Преимущества:**
Single company toolset — единый набор инструментов для компании, например, Argo CD.
Single source of truth (enforce) — архитектура единого источника достоверности. Практика сбора данных из многих систем внутри организации в одном месте.
Предотвращение несанкционированных изменений. Даже если кто-то вручную поправит что-то в кластере, [Argo CD](https://argo-cd.readthedocs.io/en/stable/) проверит и вернет настройки в исходное состояние (если включить данную настройку разумеется).
Full asset visibility from GitOps — прозрачность активов в pull-модели с обязательным промежуточным Git-репозиторием.
**Недостатки:**
Risk of misconfiguration Stack — риски неправильной конфигурации безопасности. Речь о риске быстрого применения неправильных настроек, если произошел быстрый pull, это может породить ошибки в системе из-за которых придется откатывать систему назад.
### Схема деплоя Kubernetes GitOps mode (pull)
Если пойти еще дальше, можно отказаться от Terraform для деплоя кластеров и использовать no code инструмент [Crossplane](https://crossplane.io/).
В этой модели в управляющий кластер с Argo CD нужно установить оператор [Crossplane](https://crossplane.io/) и описывать облачные объекты Kubernetes-кластеры, как CustomResourceDefinitions (yaml-файлы). Argo CD применит (Apply) эти файлы, а Crossplane-оператор их подхватит и создаст облачные объекты.
**Преимущества:** позволяет вынести CD-часть глубже в Kubernetes. В ряде случаев это бывает очень полезно.
### Схема деплоя с Kubernetes Platform mode
Для тех, кто хочет пойти ещё дальше, существует инструмент [Admiralty](https://github.com/admiraltyio/admiralty), который в своем проекте использовали коллеги из Сан-Диего. Он позволяет рассматривать несколько кластеров, как один виртуальный. То есть это такой интеллектуальный мультикластерный планировщик — multi-cluster scheduler.
**Преимущества:**
Централизованный контроль доступа и аудит логов.
Безопасное управление кластерами учетных данных — credentials. В кластер ставится admiralty agents, благодаря которому не нужно открывать входящий доступ, например, к Kubernetes API.
**Минусы:**
Существенная часть продукта платная.
### А что с проблемами безопасности
### Terraform
Terraform-манифесты можно сканировать на предмет проблем с безопасностью из-за неправильной конфигурации — security misconfiguration. Например, отсутствие защищенных групп (security group) на нодах кластера, публичных корзинах (Public bucket) и другие облачные проблемы с misconfiguration.
Находить и проверять Credentials и secrets в Terraform и еще следующие типы объектов:
* Terraform,
* Terraform plan,
* Cloudformation,
* AWS SAM,
* Kubernetes,
* Helm charts,
* Kustomize,
* Dockerfile,
* Serverless,
* Bicep or ARM Templates
Есть ряд инструментов, например, [Checkov](https://www.checkov.io/), который позволяет сканировать эти манифесты и выдавать ответы. Причем их можно внедрить даже в pre-commit hook на ноутбуке разработчика, или же в CI/CD систему, что привычнее. Сам Checkov бесплатен, но в нём есть платные расширения.
В Yandex Cloud сделали конрибьют из Yandex Cloud в Checkov, чтобы в нём появилась возможность сканировать Terraform-манифесты. По [ссылке](https://bridgecrew.io/blog/terraform-plan-security-scanning-checkov/) можно познакомиться с реальным решением, которое на примере GitLab CI/CD позволит вам его использовать.
А еще Yandex Cloud составили [чек-лист по безопасности Terraform](https://cloud.yandex.ru/docs/security/domains/secure-config#terraform), который поясняет, почему правильно использовать Terraform state в защищенном object storage, а не на ноутбуке разработчиков и как правильно работать с секретами.
### Kubernetes
Также мы подготовили [гайд по безопасности Kubernetes](https://cloud.yandex.ru/docs/security/domains/kubernetes):
Если вам нужно соответствовать какому-то стандарту, например, PCI DSS или 152-ФЗ, будучи в облаке, или если вы просто хотите обезопасить вашу среду, пройдитесь по этому гайду. В нём есть такие разделы, как домены, сетевая безопасность, шифрование, аутентификация и возможность настроить по порядку все необходимые параметры.[Чеклист по безопасности | Yandex Cloud - Документация](https://cloud.yandex.ru/docs/security/domains/checklist#kubernetes-security)
### CI/CD
Существует риск, что вашу CI/CD систему могут атаковать. Если к ней получат доступ, то, скорее всего, полный, потому что, как правило, доступы у неё достаточно широкие. На просторах интернета даже есть матрица атак на CI/CD систему, вот как она выглядит:
### GitLab Instance
В [чек-листе по безопасности gitlab](https://cloud.yandex.ru/docs/managed-gitlab/concepts/security#secure-instance) есть информация о том, как безопасно получать доступ к CI/CD системе, как правильно настроить ее и так далее. Это очень полезная информация при построении модели угроз на вашу инфраструктуру.
Отдельно отметим плюсы Managed Service CI/CD, например, Managed Service for GitLab, который доступен в некоторых местах, включая облако. Недавно опубликовали множество уязвимостей в GitLab. На сайте Yandex Cloud обычно выпускают бюллетени безопасности на эту тему: какая уязвимость обнаружена, каких версий она касается и как её исправить. Если у вас управляемый сервис GitLab, то за обновление можно не переживать. Уже на следующий день эти инстансы будут обновлены.
### Инструменты защиты кластеров
Для полноценной защиты нужно:
1. Настроить инструменты так, чтобы покрыть максимальное количество угроз.
2. Интегрировать инструменты с корпоративными системами.
3. Интегрироваться в процессы платформы.
### Управление уязвимостями
В Yandex Cloud провели [сравнительный анализ инструментов](https://github.com/yandex-cloud/yc-solution-library-for-security/blob/master/kubernetes-security/choice_of_solutions/) по безопасности (опенсорс и платных) и разбили их на домены.
[Сравнение\_функций\_k8s\_security.pdf](https://github.com/yandex-cloud/yc-solution-library-for-security/blob/master/kubernetes-security/choice_of_solutions/%D0%A1%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B9_k8s_security.pdf)
В домене управления уязвимостями есть сканирование образов, нод — continuous pentest. Лидируют платные решения, потому что закрывают наибольшее количество функционала — например, [Aqua Security](https://www.aquasec.com/), [Sysdig](http://com/). Но набор опенсорсных инструментов — таких, как [Kyverno](https://kyverno.io/), оператор [Starboard](https://aquasecurity.github.io/starboard/v0.15.6/), GitLab — позволяют приблизиться к максимальному покрытию без дополнительных расходов.
### Runtime Security
В этом домене защищаем runtime, анализируем [SYSCALLS](https://man7.org/linux/man-pages/man2/syscalls.2.html), пакеты установленные на ноды и т.д.
Лидируют тоже платные решения, но есть и бесплатные — [Osquery](https://osquery.io/), [Falco](https://falco.org/), [ClamAV](http://www.clamav.net/), которые тоже позволяют закрыть большую часть потребностей.
### Network security
Функция наблюдения и устранения неполадок [Cilium/Hubble](https://github.com/cilium/hubble-ui) позволяет Flow logs частично анализировать и выстраивать карту сети и расширенные сетевые политики. Также есть платные решения, которые немного удобнее.
### UI, data logging, compliance
В наличии функции построения карты сети и карты взаимодействия объектов.
Российский продукт [Luntry](https://luntry.ru/) закрывает большинство потребностей. А ещё есть [KubiScan](https://github.com/cyberark/KubiScan) и декларативный GitOps-инструмент непрерывной доставки [Argo CD](https://argo-cd.readthedocs.io/en/stable/), которые обеспечат такое свойство системы кластеров, как observability (наблюдаемость).
### Kubernetes cloud audit logs
Говоря об инструментах безопасности, хочется подсветить важность Kubernetes аудит-логов в облаке. Почему-то их не многие реально анализируют.
В облаке аудит-логи делятся на два типа:
**Admin Activity audit logs** — логи работы с API облака через UI/CLI/Terraform. Это то, что делают с облачным API. Например, создание кластера, изменения кластера, действия с nodes.
Data audit logs — это аудит-логи, встроенные в Kubernetes (К8 native audit logs). Например, создание pod, назначение прав внутри Kubernetes и т.д.
Схематично это выглядит так:
Два типа логов попадают в Cloud Logging System или в Cloud Audit System. После этого их можно экспортировать, например, в [S3](https://aws.amazon.com/ru/s3/) или в data streams, а потом уже в SIEM систему, которая у вас есть — например, [DataDog](https://www.datadoghq.com/), [Splunk](https://www.splunk.com/), [Elastic](https://www.elastic.co/) или [ArcSight](https://www.microfocus.com/en-us/cyberres/secops/arcsight-esm). Какую именно систему вы будете использовать — не имеет значения.
### Use cases and important security events in audit logs
Как анализировать логи — не всем понятно, поэтому в Yandex Cloud подготовили [use cases](https://github.com/yandex-cloud/yc-solution-library-for-security/tree/master/auditlogs/_use_cases_and_searches). Там рассмотрены подозрительные действия, на которые важно вовремя отреагировать. Это может быть, например, отслеживание событий [exec в container](https://docs.docker.com/engine/reference/commandline/exec/), подключение к Kubernetes кластеру извне с публичных адресов, назначение излишне привилегированных прав.
### Внедрение инструментов
### Enterprise system
Существуют платные enterprise-системы, которые достаточно легко внедряются и содержат всё в одной коробке:
* опыт и база знаний от вендора;
* полный набор фич в одной коробке;
* облегченная установка;
* нативные выгрузки событий в систему управления событиями и информацией о безопасности — SIEM.
Но эти системы обычно дорогие и у них длинный цикл покупки, что не всегда удобно и к сожалению в настоящее время не многие из них можно купить в РФ.
### Open Source System
Альтернатива — опенсорс-решения. Они выглядят примерно так:
Есть одинаковые кластеры, в которые устанавливают:
[Falco](https://falco.org/) для Runtime Security;
[Kyverno](https://kyverno.io/), как admission controller, например, [Starboard оператор](https://aquasecurity.github.io/starboard/operator/) (который переименовали в trivy-operator), который содержит [Trivy](https://aquasecurity.github.io/trivy/dev/) для скан-образов и [kube-bench](https://github.com/aquasecurity/kube-bench) для нод;
[Kubequery](https://github.com/Uptycs/kubequery), который опрашивает ноды на предмет установленных пакетов, наличие юзеров в определенных группах ОС и т.д.
Все эти инструменты нужно отгрузить в SIEM-систему, потому что анализировать срабатывание всех инструментов, вручную заходя в кластер и отслеживая [CRD](https://itnext.io/crd-is-just-a-table-in-kubernetes-13e15367bbe4) и outputs подов — невозможно.
Open Source System: экспорт событий
Анализ логов обычно выглядит так:
Каждый инструмент содержит еще один инструмент, который позволяет отгружать логи. Например, [Falco](https://falco.org/) имеет [Falco sidekik](https://github.com/falcosecurity/falcosidekick), [Kyverno — Policy Reporter](https://github.com/kyverno/policy-reporter). У Starboard инструменты отгрузки логов вовсе отсутствуют. А чтобы посмотреть логи в [Osquery](https://github.com/osquery/osquery), нужно установить [Fluentbit](https://fluentbit.io/). Он позволит из папки warlog все отгружать в SIEM, а это не самый простой и красивый путь.
### Kyverno Policy Reporter
Этот продукт изначально создавался для красивой визуализации и срабатывания [Kyverno admission controller](https://kyverno.io/docs/introduction/). Для тех, кто не знает, с admission controller нельзя создавать привилегированный под в кластере, или монтировать файловую систему ноды и т.д. Вот тут можно прочесть о Kyverno Policy Reporter подробнее: [GitHub - kyverno/policy-reporter: Monitoring and Observability Tool for the PolicyReport CRD with an optional UI.](https://github.com/kyverno/policy-reporter)
Kyverno Policy Reporter умеет отправлять отработки политик в:
* Grafana Loki
* Elasticsearch
* Slack
* Discord
* MS Teams
* Policy Reporter UI
* S3
* http/s endpoint
Он поддерживает Yandex Cloud S3 и другие S3 совместимые storages и инструменты безопасности вроде Trivy, Falco, Kube-Bench.
### Доступность для других облаков
Эти решения [работают](https://sba.yandex.net/redirect?url=https%3A%2F%2Fkyverno.github.io%2Fpolicy-reporter%2Fcore%2F06-targets%2F%23s3-compatible-storage\&client=clck\&sign=2d634ae3e75e791e8c18c394fbd83bf3) и в других облаках. Все инструменты можно отгружать в Policy Reporter, а из него, например, в object storage, а оттуда в SIEM систему в формате, приведённом к единому. Нет необходимости в дополнительном парсинге.
### Multi cluster mode
Policy Reporter предоставляет cluster view, но позволяет отгружать данные в S3. Этот мод легко внедрить в Yandex Cloud — есть готовые шаблоны для работы с Elastic.
Так выглядит экспорт событий с Policy Reporter:
Есть нюанс, что Policy Reporter ничего не знает про другие кластеры, а взаимодействует только в рамках одного. Здесь возникает сложность, что в SIEM системе нельзя отследить, с какого кластера пришли эти срабатывания, какой cluster\_ID они имеют. Но можно прибегнуть к лайфхаку — указывать префикс файлов в object storage, то есть название папки object storage указывать как cluster\_ID при установке Policy Reporter. Тогда вы сможете обогащать данные в SIEM систем, используя этот cluster\_ID. Либо можно использовать параметр «custoField» в чарте reporter.
### Готовое решение в Yandex Cloud
В Yandex Cloud сделали [готовое решение](https://github.com/yandex-cloud/yc-solution-library-for-security/tree/master/auditlogs/export-auditlogs-to-ELK_k8s) по установке с помощью Terraform Falco, Kyverno, отгрузки всех логов вместе с аудит логами в Elasticsearch. Еще есть Managed Service Elastic, так как это популярное решение, которое работает не только на Managed Service.
Там же загружаются уже предзаготовленные дашборды, содержащие в себе предзаготовленные данные для анализа.
Это технологическая часть условного security-центра, который позволяет фильтровать данные и наблюдать за ними. Для большего удобства можно даже перейти на облачную консоль, кликнув на конкретный cluster\_ID.
Здесь есть:
**Готовый дашборд в Elasticsearch** с разбивкой и фильтрами по cluster\_ID и сloud\_ID.
**Карта подключений,** которая показывает из каких стран в ваш кластер подключаются админы или другие пользователи.
**Дашборды, которые показывают подозрительные действия** с сетевыми политиками, контейнерами, сервисными аккаунтами.
**Отдельный дашборд для срабатываний инструментов Falco.** В режиме таймлайн показывает, какие политики сработали и для каких подов. Отслеживать события можно в наглядной форме. Ниже есть таблица с названием подов, количеством срабатываний и разбивкой по namespace. Если произошел какой-то инцидент, можно зайти и быстро посмотреть, нормальное ли это действие или false positive.
**Отдельный дашборд для policy Kyverno**. Появится информация, если, например, кто-то создал под, получил расширенные права. Все данные о нарушениях правил подами предоставлены в табличной форме. Можно создать фильтр по конкретному событию и получить детализацию или drilldown по конкретному нарушению правила политики. Есть возможность промотать вниз и посмотреть сырые логи, а затем расследовать конкретную ситуацию.
Конечно, круглосуточно просматривать этот дашборд никто не будет. Поэтому существует механизм алертинга для любой подобной системы, в том числе Elastic. В этом случае правила реагирования подготовлены заранее. Например, проникновение админа в контейнер в продакшене, если установлен доступ только для CI/CD системы. Уведомления тоже можно настроить — например, получать в Slack со ссылкой на Elasticsearch.
### Другие решения из нашей Security Library
Это решения, как в Osquery раскатывать [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/), экспортировать [Flow logs Cilium](https://docs.cilium.io/en/stable/operations/troubleshooting/), создавать заплатки на CVE: [yandex-cloud/yc-solution-library-for-security](https://github.com/yandex-cloud/yc-solution-library-for-security)
### Marketplace
Не так давно в Kubernetes появился Marketplace, в котором есть много продуктов по безопасности. Их можно быстро и легко протестировать нажатием кнопки. Многие интегрированы с облаком. Например, при установке можно указать сервис аккаунт ключ — sa keys input — чтобы предоставить доступ в облако для HashiCorp Vault интеграции с KM (Key Management) сервисом. А ещё можно скачать все чарты и использовать/кастомизировать их.
### Резюмируя
Как же построить Security center для Kubernetes
1. Неизбежная потребность в multi-cluster структуре — наличии больше одного кластера.
2. Выбрать подходящую из существующих схем деплоя кластеров, security- и платформ-инструментов.
3. Использовать предоставленные мной чек-листы и материалы для обеспечения безопасности кластеров.
4. Понимать особенности инструментов безопасности и их функций, а также аудит-логов — какие за что отвечают, как можно достичь нужного уровня с их помощью.
5. Выбирать правильные платные или бесплатные инструменты, исходя из вашей модели угроз, и правильно их интегрировать с корпоративным SIEM. Не забывайте про готовое решение с Elastic SIEM в Yandex Cloud.
Соблюдая эти правила, вы получите много алертов и логов. Останется настроить реагирование на них, потому что иначе они так и останутся нетронутыми файлами в вашей файловой системе. Ведь если не реагировать на эти срабатывания, то все предпринятые усилия были напрасны.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://book.konstantinsecurity.com/readme/architect/kubernetes/security-center/security-senter-for-kubernetes.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.