Сканирование плоскостей управления Kubernetes и рабочих узлов на предмет уязвимостей безопасности

Лидеры и инженеры в области безопасности перешли от термина «нехватка навыков» к термину «хроническая нехватка навыков».

Причина в том, что дефицит навыков в области безопасности находится на рекордно низком уровне.

Если вы подумаете о том, сколько разработчиков работает в компании, по сравнению с тем, сколько инженеров по безопасности работает в той же компании, то это число будет кардинально отличаться. Это если в компании вообще есть инженеры по безопасности.

Поэтому наличие знаний и инструментов для сканирования кластеров Kubernetes на наличие уязвимостей, скорее всего, не происходит вообще, или, по крайней мере, происходит с недостаточной частотой.

В этой статье блога вы узнаете о том, как упростить этот процесс, даже если у вас нет обширных знаний в области безопасности, с помощью функции сканирования кластеров Kubescape.

Для целей этой статьи в блоге будет использоваться облако Kubescape. Kubescape CLI — отличный вариант, но пользовательский интерфейс, безусловно, дает более надежное ощущение и облегчает вашу жизнь с визуальной точки зрения. Если вы хотите подписаться на него, вы можете сделать это здесь.

Предварительные условия

Если вы будете следовать практической части этой статьи, вам понадобятся:

  • Kubescape CLI, который вы можете найти здесь.
  • Кластер Kubernetes. Minikube будет работать так же хорошо, как и любой другой кластер.

Зачем нужно сканирование кластера

Когда вы думаете о кластере Kubernetes, вы видите, что в нем очень много частей, которые обеспечивают его работу. В плоскости управления есть ETCD, планировщик, сервер API и менеджер контроллеров. На рабочих узлах у вас есть каждый запущенный Pod, kube-proxy, DNS, среда выполнения контейнеров и Kubelet.

Список выше приведен на максимально возможном уровне объяснения, и все равно он кажется невероятно сложным для управления. Это буквально целый центр обработки данных сам по себе.

Из-за этого вы должны представить, что полтора миллиона вещей могут пойти не так.

Давайте рассмотрим пример с сетью. Скажем, вы создаете кластер Kubernetes, и сервер, на котором работают плоскости управления, имеет публичный IP-адрес, или вы создаете кластер Kubernetes в облаке, и кластер имеет публичный IP-адрес. Сразу после этого, в результате такого простого действия, как изменение нажатия кнопки, вы получаете целый кластер, который уязвим для любого, кто может попытаться его взломать. Если у вас не настроен RBAC, чего не делают многие организации, или вы не проверяете журналы для конечной точки метрики API-серверов, чтобы увидеть количество поступающих запросов, у вас на руках может оказаться брешь.

Существует два типа кластеров, которые вы будете сканировать:

  • Местные/сырые кластеры Kubernetes.
  • Облачные службы Kubernetes, такие как AKS, GKE, EKS или OpenShift.

Независимо от того, какой вариант вы выберете, вам все равно придется сканировать кластер.

Если вы думаете: «Хорошо, служба Kubernetes управляется поставщиком облака, поэтому мне не нужно заниматься сканированием», вам нужно пересмотреть то, что делают для вас службы Kubernetes в облаке. Они не минимизируют уязвимости внутри вашего кластера Kubernetes. Они просто размещают кластер Kubernetes для вас. Все последствия для безопасности, которые могут возникнуть, все равно на 100% зависят от вас, чтобы смягчить их как можно лучше.

Пять лучших мер безопасности кластера

В предыдущем разделе вы узнали о том, почему необходимо сканировать кластеры, и причина в том, что это целая среда/центр обработки данных в себе и имеет все те же типы уязвимостей, что и любая другая среда.

В этом разделе мы поговорим о пяти основных мерах безопасности, которые можно предпринять для кластера Kubernetes.

Во-первых, убедитесь, что плоскости управления не имеют связанных с ними публичных IP-адресов. Это приводит к тому, что кластеры можно искать по сети. В недавнем отчете более 900 000 кластеров Kubernetes были обнаружены открытыми в Интернете.

Во-вторых, RBAC. RBAC — это, пожалуй, самая просматриваемая конфигурация в кластере Kubernetes. Без надлежащих разрешений RBAC ваш кластер буквально открыт. При разработке RBAC для пользователей, которые проходят аутентификацию в Kubernetes, убедитесь, что они получают разрешения и авторизацию, которые им необходимы, и ничего более. Будьте особенно осторожны в этом вопросе, когда вы запускаете CRD для установки оператора в кластере Kubernetes. Существует множество платформ, которые при установке CRD настраивают учетную запись службы и разрешения RBAC для своей платформы, что в 9 случаях из 10 дает полный администраторский/корневой доступ.

В-третьих, настройка политики. Думайте о политиках как о привратниках для всего и вся в вашем кластере Kubernetes. Это может быть доступ к какому пространству имен Kubernetes или запрет на развертывание Kubernetes Manifest с пометкой latest в образе контейнера. Open Policy Agent (OPA) — это стандарт, за который взялись многие инженеры, также существует Kyverno, который похож на OPA, но специально для Kubernetes.

В-четвертых, ведение журналов. Легко установить агрегатор журналов для сбора журналов. Затем встает вопрос — что делать с этими журналами? Журналы с конечных точек метрики в Kubernetes буквально станут вашим золотым билетом к пониманию того, что происходит не так в вашей среде. Убедитесь, что вы не только сохраняете журналы, но и принимаете меры с журналами, используя какой-либо тип платформы управления производительностью приложений (APM).

В-пятых, сканирование кластеров. Если вспомнить все, что вы узнали из этой статьи в блоге и на протяжении всего вашего путешествия в пространстве Kubernetes, то можно найти способ максимально смягчить эти проблемы. Для этого необходимо иметь соответствующий инструмент для сканирования кластера, с помощью которого вы сможете определить, когда ваш кластер уязвим. В противном случае вы никогда не узнаете об этом, и это будет постоянная игра в угадайку.

Начало работы со сканированием конфигурации Kubescape

Теперь, когда вы понимаете важность сканирования всего кластера, пришло время перейти к практической части и узнать, как настроить сканирование кластера.

Одна из многих замечательных особенностей сканирования конфигурации заключается в том, что вы можете сканировать любой кластер, даже Minikube! Для целей этой статьи в блоге использовался Minikube, но вы можете сделать то же самое для любого кластера Kubernetes.

Сначала войдите в Kubescape UI, и под приборной панелью вы увидите опцию добавления сканирования кластера. Нажмите кнопку Добавить сканирование кластера.

Далее у вас есть две опции на выбор для развертывания сканирования кластера:

  • В Cluster Deployment, который представляет собой Helm Chart, который вы развертываете внутри вашего кластера.
  • С помощью Kubescape CLI, который вы можете использовать локально или даже в автоматическом режиме с помощью конвейера CICD.

Для целей этой статьи в блоге используется Helm Chart. Однако те же результаты будут получены при любом варианте, который вы выберете.

Приведенный ниже код:

  • Добавляет репо ARMO через Helm
  • Обновляет репо
  • Устанавливает ARMO внутри пространства имен armo-system в вашем кластере Kubernetes

Запустите приведенный ниже код для развертывания In Cluster Deployment.

# Add the Helm repo
helm repo add armo https://armosec.github.io/armo-helm/

# Update the helm repo
helm repo update

# Install ARMO on the k8s cluster
helm upgrade --install armo armo/armo-cluster-components -n armo-system --create-namespace --set accountGuid=7bcb8621-517d-4416-9a72-234cf9b5d90c --set clusterName=`kubectl config current-context`
Вход в полноэкранный режим Выйдите из полноэкранного режима

После выполнения приведенного выше кода войдите в свой Kubescape UI. Теперь вы должны увидеть, что ваш кластер отображается на странице DASHBOARD.

Теперь, когда кластер существует, нажмите на CONFIGURATION SCANNING в левой панели, а затем нажмите на AllControls.

Когда вы нажмете на AllControls, вы увидите несколько частей вывода, которые содержат все: от пройденных тестов до неудачных тестов и тестов, помеченных как неактуальные. Приведенный ниже скриншот является примером, но обратите внимание, что ваши результаты могут выглядеть иначе, поскольку вы сканируете свой собственный кластер Kubernetes.

Углубившись немного в фактические элементы управления, нажмите на ArmoBest.

Как вы можете видеть, здесь есть несколько элементов вывода, от сбоев в сети кластера до сбоев Kubernetes Secret и сбоев ETCD.

Подобные уязвимости в производстве могут стать решающим фактором между хорошим и плохим днем. Например, в C-0012 говорится, что любой злоумышленник, имеющий доступ к конфигурационным файлам, может украсть секреты, хранящиеся в Kubernetes, которые могут быть паролями и строками подключения ко всей вашей среде.


Поздравляем! Вы официально настроили Kubescape Configuration Scanner и готовы приступить к устранению любых проблем внутри вашего кластера Kubernetes.

Оцените статью
devanswers.ru
Добавить комментарий