Распространение Kubernetes За 3 года количество компаний с 50+ кластерами Kubernetes выросло с 15 до 29%. Число действующих кластеров Kubernetes 2022 2021 2020 5 или меньше 6–10 11–25 26–50 Больше чем 50 12% 23% 20% 16% 29% 25% 32% 17% 10% 16% 30% 27% 16% 13% 15% Исследование VMware The State of Kubernetes 2022
Нужно больше золота Kubernetes-кластеров 48% респондентов ожидают существенного роста количества кластеров Kubernetes в компании. Ожидаемый рост числа кластеров Kubernetes в компаниях Резко увеличится Существенно увеличится Заметно увеличится (больше чем вдвое) (более чем на 50–100%) (на 20–50%) 13% 35% 28% 48% Исследование VMware The State of Kubernetes 2022
Больше внедрений, больше проблем В организациях, где контейнеры используются практически для всех приложений, безопасность становится главным вызовом. Исследование CNCF Annual Survey 2022 25% 41% 44% 40% 35% 30% ОТСУТСТВИЕ ЭКСПЕРТИЗЫ БЕЗОПАСНОСТЬ Контейнеры используются для большинства или всех приложений Контейнеры используются для некоторых приложений Контейнеры находятся в стадии пилотного проекта или активно оцениваются Вызовы при использовании контейнеров
Проблемы точно есть Исследование Red Hat State of Kubernetes security report 2022 Только 7% опрошенных ответили, что не столкнулись с инцидентами связанными с безопасностью при эксплуатации контейнеров и/или Kubernetes. За последние 12 месяцев Проблемы с безопасностью 53% 38% 30% 22% 7% Обнаружена некорректная конфигурация Крупная уязвимость, требующая устранения Инцидент безопасности в runtime Непройденный аудит Нет проблем
Новые-старые вызовы, связанные с безопасностью Больше половины опрошенных откладывали или задерживали deploy приложений из-за опасений насчет безопасности в Kubernetes. 45% Нет 55% Да Откладывали ли вы deploy приложений из-за опасений насчет безопасности в Kubernetes? Исследование Red Hat State of Kubernetes security report 2022
Center for Internet Security Корректность конфигурации проверяется для следующих компонентов: Есть множество реализаций, одна из самых популярных — kube-bench. Kubernetes CIS Benchmark ● Компоненты Control Plane ○ Конфигурационные файлы узлов Control Plane ○ API Server ○ Controller Manager ○ Scheduler ○ etcd ● Конфигурация Control Plane ○ Аутентификация и авторизация ○ Логирование и аудит ● Worker Nodes ○ Конфигурационные файлы worker-узлов ○ Конфигурация kubelet ● Policies (RBAC, Service Accounts, Pod Security Standards, Network Policies)
Payment Card Industry Security Standards Council ● Аутентификация и авторизация ● Безопасность приложений ● Сетевая безопасность ● Управление секретами ● Мониторинг и аудит ● Безопасность среды выполнения ● Управление ресурсами ● Управление конфигурацией Guidance for Containers and Container Orchestration Tools Общий стандарт без инструкций для реализации Содержит разделы:
Федеральная служба по техническому и экспортному контролю ● Изоляция контейнеров ● Выявление уязвимостей в образах контейнеров ● Контроль целостности контейнеров и их образов ● Регистрация событий безопасности ● Проверка корректности конфигурации контейнеров ● Управление доступом Требования по безопасности информации к средствам контейнеризации В документе говорится о следующих функциях безопасности: Приказ ФСТЭК России от 4 июля 2022 г. № 118
Модель 4С’s облачной безопасности ● Защита приложений и используемых библиотек ● Контроль над запускаемыми контейнерами и защита runtime ● Ограничение доступа к Kubernetes control plane и узлам кластера ● Безопасный доступ к API Cloud и инфраструктуре Cluster Master Node Node Container Runtime Pod Container Control Plane Components kube-apiserver kubelet APP APP
5 шагов к безопасности в Kubernetes Корректная конфигурация кластера Kubernetes Сканирование образов Сетевая безопасность Контроль над запускаемыми приложениями Аудит и регистрация событий 1 2 3 4 5
Корректная конфигурация кластера Kubernetes Проверить конфигурацию control-plane и узлов кластера, например с помощью kube-bench Ограничить сетевой доступ к Kubernetes API Каждый пользователь/компонент должен уникально идентифицироваться при доступе к Kubernetes API Кажется, что ничего сложного Настроить RBAC и выдавать только необходимые разрешения 1 2 3 4
Корректная конфигурация кластера Kubernetes После создания кластера никто не должен аутентифицироваться в Kubernetes API как system:masters. Проверим одного из популярных облачных провайдеров managed Kubernetes. Если такой kubeconfig утечет, то придется перевыпускать CA и сертификаты. cat config | yq '.users[0].user.client-certificate-data' | base64 -d | openssl x509 -subject -noout subject=O = system:masters, CN = kube-admin
Сканирование образов ● На этапе конвейера CI/CD ● Registry по расписанию ● В кластере Kubernetes ● Есть множество инструментов как self-hosted, так и SaaS
Сканирование образов ● Необходимо разбирать уязвимости. Не каждый Critical несет угрозу, и его можно эксплуатировать ● Использование общих базовых образов упрощает процесс исправления CVE ● Используем образы с необходимым количеством зависимостей ● Собираем артефакт отдельно и копируем в итоговый контейнер, который будет использоваться в кластере apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: mtls-on namespace: myns spec: host: *.myns.svc trafficPolicy: tls: mode: ISTIO-MUTUAL FROM $BASE_GOLANG_ALPINE as artifact WORKDIR /go/src/github.com/kubernetes-incubator/descheduler RUN apk add --update git make RUN git clone https://github.com/kubernetes-incubator/descheduler.git . \ && git checkout v0.21.0 RUN make FROM $BASE_ALPINE COPY --from=artifact /go/src/github.com/kubernetes-incubator/descheduler/_output/bin/descheduler /bin/descheduler CMD ["/bin/descheduler", "--help"]
Сетевая безопасность ● CNI должен поддерживать сетевые политики ● Ingress- и egress-сетевые политики для всех компонентов кластера ● По умолчанию Deny all, все соединения должны быть явно разрешены Опционально: ● Глобальные политики на весь кластер ● Хостовые политики ● Визуализация сетевых соединений ● Редактор для сетевых политик
● Внедрение политик необходимо как в «коммунальных кластерах», так и в случае, если у каждого сервиса отдельный кластер ● Очень важно понимать и контролировать, кто/что и куда обращается ● Policy as code ● Внедрять на живую гораздо сложнее, но возможно Сетевая безопасность
В Kubernetes 1.23 есть Pod Security Admission из коробки. Если требуется кастомизация и недостаточно Pod Security Standards. Варианты: ● Kubewarden ● Kyverno ● OPA Gatekeeper Контроль над запускаемыми приложениями
Ограничить количество ревизий Обязательно прописывать ресурсы Указывать priorityClass Использовать пробы Разрешить только доверенные registry Запретить использовать тег latest Контроль над запускаемыми приложениями
● Runc and CVE-2019-5736 ● Контейнер, запускаемый от root, мог получить доступ к хосту ● Высокий риск, если приложения запускаются из публичных репозиториев ● Больше контроля, меньше пространства для ошибки и возникновения уязвимости Контроль над запускаемыми приложениями
Аудит и регистрация событий Необходимо анализировать события аудита Kubernetes API: ● Изменения политик безопасности ● Создание/изменение/удаление объектов пользователями Необходимо регистрировать события, которые происходят без участия API: ● События в хостовой ОС на узлах кластера ● События внутри контейнера Для решения этих вопросов есть приложения, которые реализуют runtime security. В Deckhouse используется Falco, который содержит следующие функции: ● Разбор системных вызовов на хосте ● Получение аудит-лога от Kubernetes API через Webhook backend ● Проверка потока событий с помощью сконфигурированных правил ● Отправка алертов в случае нарушения правил
Аудит и регистрация событий Необходимо анализировать события аудита Kubernetes API: ● Изменения политик безопасности ● Создание/изменение/удаление объектов пользователями Необходимо регистрировать события, которые происходят без участия API: ● События в хостовой ОС на узлах кластера ● События внутри контейнера Для решения этих вопросов есть приложения, которые реализуют runtime security. В Deckhouse используется Falco, который содержит следующие функции: ● Разбор системных вызовов на хосте ● Получение аудит-лога от Kubernetes API через Webhook backend ● Проверка потока событий с помощью сконфигурированных правил ● Отправка алертов в случае нарушения правил
Аудит и регистрация событий Необходимо анализировать события аудита Kubernetes API: ● Изменения политик безопасности ● Создание/изменение/удаление объектов пользователями Необходимо регистрировать события, которые происходят без участия API: ● События в хостовой ОС на узлах кластера ● События внутри контейнера Для решения этих вопросов есть приложения, которые реализуют runtime security. В Deckhouse используется Falco, который содержит следующие функции: ● Разбор системных вызовов на хосте ● Получение аудит-лога от Kubernetes API через Webhook backend ● Проверка потока событий с помощью сконфигурированных правил ● Отправка алертов в случае нарушения правил
Аудит и регистрация событий falco-driver-loader — init-контейнер, который собирает eBPF-программу и сохраняет ее в общую папку для дальнейшего использования системой Falco
Аудит и регистрация событий apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: mtls-on namespace: myns spec: host: *.myns.svc trafficPolicy: tls: mode: ISTIO-MUTUAL - required_plugin_versions: - name: k8saudit version: 0.1.0 - macro: kevt_started condition: (jevt.value[/stage]=ResponseStarted) - macro: pod_subresource condition: ka.target.resource=pods and ka.target.subresource exists - macro: kcreate condition: ka.verb=create - rule: Attach/Exec Pod desc: > Detect any attempt to attach/exec to a pod condition: kevt_started and pod_subresource and kcreate and ka.target.subresource in (exec,attach) output: Attach/Exec to pod (user=%ka.user.name pod=%ka.target.name resource=%ka.target.resource ns=%ka.target.namespace action=%ka.target.subresource command=%ka.uri.param[command]) priority: NOTICE source: k8s_audit tags: [k8s] Пример правил с аудитом Kubernetes API
Аудит и регистрация событий ● Правила Deckhouse для системных вызовов https://github.com/deckhouse/deckhouse/blob/main/ee/modules/650-runtime-audit-engine/rules/falco_rules.yaml ● Правила Deckhouse для Kubernetes аудита https://github.com/deckhouse/deckhouse/blob/main/ee/modules/650-runtime-audit-engine/rules/k8s_audit_rules.yaml ● Правила организации Falcosecurity https://github.com/falcosecurity/rules ● Пример правила для закрытия CVE от Sysdig https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/
Идем дальше? Kubernetes — это прекрасный инструмент с большим количеством возможностей Естественно, есть другие важные аспекты безопасности: ● Аутентификация и авторизация ● Аудит RBAC ● Управление секретами ● Защита цепочки поставки ○ Запрет запуска образов с уязвимостями ○ Запуск только подписанных образов, использование cosign ● Режим обучения для генерации политик ● Автоматическое реагирование на события аудита
Итоги Вопрос безопасности в Kubernetes не решен. Есть многофункциональный конструктор. Kubernetes DIY. Обязательно выделяйте время на организацию безопасности. Если нет времени, то стоит посмотреть в сторону готовых решений: ● Kubesec, NeuVector, Kubescape, Luntry и др. ● платформы OKD, Rancher, Deckhouse Kubernetes Platform и др. 1 2 3
Спасибо за внимание Константин Аксёнов, руководитель разработки Deckhouse Kubernetes Platform QR код t.me/konstantin_aksenov konstantin.aksenov@flant.com
Сканирование образов Таблица сравнения от Aqua Security Сканер OS Работает в закрытых окружениях Сертифицирован ФСТЭК Количество звезд на Github Clair Да Да Нет 9,4 К Trivy Да Да Нет 16,5 К
Корректная конфигурация кластера Kubernetes Проверка CIS Benchmark на worker-узле: Проверим одного из популярных облачных провайдеров managed Kubernetes. Следует анализировать каждый FAIL. Есть инструменты, например kubeletctl, которые позволяют найти и использовать уязвимые kubelet’ы. [FAIL] 4.2.1 Ensure that the --anonymous-auth argument is set to false (Automated) [FAIL] 4.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Automated) [FAIL] 4.2.3 Ensure that the --client-ca-file argument is set as appropriate (Automated) [FAIL] 4.2.6 Ensure that the --protect-kernel-defaults argument is set to true (Automated) Хорошо, что это оказался просто баг в kube-bench
Проблема становится только острее Исследование Fairwinds Kubernetes Benchmark Report 2023 По сравнению с 2022 годом в 2023 количество организаций, которые запускает более 90% приложений с небезопасными настройками, выросло до 33%. Процент организаций Небезопасные настройки 2022 2023 0–10% 11–20% Затронутые приложения 21–30% 31–40% 41–50% 51–60% 61–70% 71–80% 81–90% 91–100% 42% 10% 5% 4% 0% 1% 1% 2% 3% 3% 3% 10% 9% 11% 6% 8% 8% 24% 33% 17%
Спасибо за внимание Имя Фамилия, должность Фото Имя Фамилия, должность Фото Имя Фамилия, должность Фото QR код Имя Фамилия, должность Фото Имя Фамилия, должность Фото
flant
eiki
takatsunobuhiro
bonotake
.png){kind=icon}
3playmarketing
nikkei_engineer_recruiting
line_developers
gaelvaroquaux
picardparis
hiashisan
torounit
prathamesh
whywaita
jrom
bkeepers
ammeep
sugarenia
brianwarren
chrislema
myddelton
skipperchong
zenorocha
davidbonilla
edds
malarkey