Обеспечение безопасности кластера Kubernetes с помощью Kubescape и kube-bench

С переходом предприятий на «облачные» технологии Kubernetes стал основным инструментом для оркестровки контейнеров. Развертывание и управление приложениями никогда не было таким простым. Однако обеспечение безопасности кластеров во многом напоминает неизведанные воды с контейнерами. Злоумышленники находят и используют новые способы проникновения в системы, в то время как сообщество круглосуточно работает над их защитой.

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

Изучая вопрос о том, как настроить сканирование кластеров Kubernetes на предмет оценки уязвимостей, мы наткнулись на два инструмента: kube-bench и Kubescape.

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

Что такое kube-bench?

kube-bench — это инструмент от компании Aqua Security. Это предложение с открытым исходным кодом, которое анализирует кластер в соответствии с рекомендациями Centre for Internet Security.

Как работает kube-bench?

kube-bench — это инструмент, который не работает постоянно на вашем кластере. Скорее, его можно запустить на всех узлах с помощью простых команд. Тест разделен на различные секции, такие как:

• Конфигурация безопасности главного узла
• Конфигурация узла etcd
• Конфигурация плоскости управления
• Конфигурация безопасности рабочих узлов
• Политики Kubernetes

Каждая секция публикует свои тесты, меры по устранению ошибок или предупреждений, а также свои итоги (количество проверок PASS/FAIL/WARN/INFO). В конце публикуется общий итог. Ниже приведены небольшие фрагменты результатов проверки kube-bench на кластере minikube:

Пример проверок

[INFO] 1 Master Node Security Configuration
[INFO] 1.1 Master Node Configuration Files
[FAIL] 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)
[FAIL] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root (Automated)
[FAIL] 1.1.3 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Automated)
[FAIL] 1.1.4 Ensure that the controller manager pod specification file ownership is set to root:root (Automated)
[FAIL] 1.1.5 Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Automated)

[INFO] 1.2 API Server
[WARN] 1.2.1 Ensure that the --anonymous-auth argument is set to false (Manual)
[PASS] 1.2.2 Ensure that the --token-auth-file parameter is not set (Automated)
[PASS] 1.2.3 Ensure that the --kubelet-https argument is set to true (Automated)
[PASS] 1.2.4 Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate (Automated)
[FAIL] 1.2.5 Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated)

Устранения Пример

1.1.1 Run the below command (based on the file location on your system) on the
master node.
For example, chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml
1.1.2 Run the below command (based on the file location on your system) on the master node.
For example,
chown root:root /etc/kubernetes/manifests/kube-apiserver.yaml
1.1.3 Run the below command (based on the file location on your system) on the master node.
For example,
chmod 644 /etc/kubernetes/manifests/kube-controller-manager.yaml
1.1.4 Run the below command (based on the file location on your system) on the master node.
For example,
chown root:root /etc/kubernetes/manifests/kube-controller-manager.yaml
1.1.5 Run the below command (based on the file location on your system) on the master node.
For example,
chmod 644 /etc/kubernetes/manifests/kube-scheduler.yaml

1.2.1 Edit the API server pod specification file /etc/kubernetes/manifests/kube-apiserver.yaml
on the master node and set the below parameter.
--anonymous-auth=false
1.2.5 Follow the Kubernetes documentation and setup the TLS connection between
the apiserver and kubelets. Then, edit the API server pod specification file
/etc/kubernetes/manifests/kube-apiserver.yaml on the master node and set the
--kubelet-certificate-authority parameter to the path to the cert file for the certificate authority.
--kubelet-certificate-authority=<ca-string>

Пример сводки

24 checks PASS
27 checks FAIL
13 checks WARN
0 checks INFO

Методы развертывания

kube-bench может быть запущен как простая команда на хосте, как контейнер на хосте с помощью команды Docker или как задание внутри кластера Kubernetes. В случае запуска внутри контейнера/пода, ему потребуется доступ к пространству имен PID хост-системы. Методы запуска kube-bench в AKS, EKS, GKE, On-prem cluster, Openshift и ACK (Alibaba Cloud Container Service For Kubernetes) отличаются, но хорошо документированы.

Когда использовать kube-bench?

Анализ kube-bench великолепен, когда он сканирует узлы (главный узел, рабочий узел, узел etcd). Он дает очень точные указания относительно прав собственности и разрешений на конфигурационные файлы, а также на флаги и аргументы, которые неправильно настроены. Он также дает команды непосредственно там, где это необходимо. Однако, когда дело дошло до сканирования артефактов внутри кластера, мы столкнулись с тем, что результаты были скорее рекомендациями. Не было никакой конкретной информации о том, какой артефакт имеет неправильную конфигурацию. Ниже приведены некоторые примеры проверок и устранения неполадок в разделе Kubernetes Policies:

Проверки

[INFO] 5 Kubernetes Policies
[INFO] 5.1 RBAC and Service Accounts
[WARN] 5.1.1 Ensure that the cluster-admin role is only used where required (Manual)
[WARN] 5.1.2 Minimize access to secrets (Manual)
[WARN] 5.1.3 Minimize wildcard use in Roles and ClusterRoles (Manual)

[INFO] 5.2 Pod Security Policies
[WARN] 5.2.1 Minimize the admission of privileged containers (Automated)
[WARN] 5.2.2 Minimize the admission of containers wishing to share the host process ID namespace (Automated)
[WARN] 5.2.3 Minimize the admission of containers wishing to share the host IPC namespace (Automated)
[WARN] 5.2.4 Minimize the admission of containers wishing to share the host network namespace (Automated)
[WARN] 5.2.5 Minimize the admission of containers with allowPrivilegeEscalation (Automated)

Исправления

5.1.1 Identify all clusterrolebindings to the cluster-admin role. Check if they are used and if they need this role or if they could use a role with fewer privileges.
Where possible, first bind users to a lower privileged role and then remove the clusterrolebinding to the cluster-admin role :
kubectl delete clusterrolebinding [name]
5.1.2 Where possible, remove get, list and watch access to secret objects in the cluster.
5.1.3 Where possible replace any use of wildcards in clusterroles and roles with specific objects or actions.

5.2.1 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.privileged field is omitted or set to false.
5.2.2 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.hostPID field is omitted or set to false.
5.2.3 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.hostIPC field is omitted or set to false.
5.2.4 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.hostNetwork field is omitted or set to false.
5.2.5 Create a PSP as described in the Kubernetes documentation, ensuring that the .spec.allowPrivilegeEscalation field is omitted or set to false.

Такие результаты не дают четкого представления о кластере. Например, приведенный выше результат не дает никакой информации о конкретных полях/привязках кластера, которые нарушают контроль безопасности. И если ваш кластер большой, то такая информация не сильно поможет.

Интеграция с другими инструментами

На момент написания этого блога kube-bench не предлагает никакой встроенной интеграции с другими инструментами. Однако AWS Security Hub добавил его в качестве интеграции с инструментами с открытым исходным кодом. Вот более подробная информация об интеграции kube-bench с другими инструментами. Помимо этого, kube-bench также предоставляет результаты сканирования в формате JSON, так что если вы хотите создавать отчеты или оповещения на основе результатов кластерного сканирования, вы можете создать сценарий на его основе.

Итак, речь шла о kube-bench. Как мы видели выше, он отлично подходит, когда мы хотим защитить кластер со стороны узлов. Однако он не дает точной информации, когда речь идет о проверке уязвимостей в конфигурациях артефактов Kubernetes. Эти вопросы можно очень хорошо решить с помощью другого инструмента, о котором мы сейчас поговорим и который стал популярным в последнее время, под названием Kubescape.

Что такое Kubescape?

Kubescape — это инструмент от компании ARMO Security. Его предложение с открытым исходным кодом анализирует кластер в соответствии с рекомендациями NSA и MITRE. Помимо этих двух инструментов, компания Armo сама разработала два фреймворка безопасности для Kubernetes, названные ArmoBest и DevOpsBest, которые работают с Kubescape.

Как работает Kubescape?

Kubescape имеет возможность работать как внутри вашего кластера, так и в CI/CD конвейере. Такая гибкость позволяет вам постоянно контролировать как ваши кластеры, так и CI/CD конвейеры.

В отличие от kube-bench, тесты Kubescape не разделены на секции. Скорее, Kubescape использует элементы управления. В экосистеме Kubescape рекомендации NSA/MITRE/ArmoBest/DevOpsBest разбиты на небольшие наборы политик (известные как элементы управления). Каждый элемент управления имеет свой собственный набор правил, по которым проверяется кластер или конвейер. Используя веб-интерфейс, вы также можете создать свою собственную структуру для использования с Kubescape, комбинируя элементы управления, предоставляемые на портале. После сканирования конфигурации она отправляет данные на портал ARMO. Вы также можете просмотреть уровень безопасности вашего кластера/трубопровода из самого веб-интерфейса. Основное различие между kube-bench и Kubescape заключается в том, что Kubescape углубляется в конкретные детали, когда речь идет о проверке артефактов Kubernetes. На портале Kubescape направляет вас точно к строке в конкретном артефакте/конфигурации, из-за которой происходит сбой контроля (пример приведен на изображении ниже):

Если вы не хотите использовать портал ARMO, вы можете просто просканировать свой кластер/трубопровод. Проблема в том, что вы не можете планировать сканирование из Kubescape. Однако для этого можно использовать утилиты типа cron. Ниже приведены примеры вывода CLI:

Пример проверки элементов управления

[control: Naked PODs - https://hub.armo.cloud/docs/c-0073] failed 😥
Description: It is not recommended to create PODs without parental Deployment, ReplicaSet, StatefulSet etc.Manual creation if PODs may lead to a configuration drift and other untracked changes in the system. Such PODs won't be automatically rescheduled by Kubernetes in case of a crash or infrastructure failure. This control identifies every POD that does not have a corresponding parental object.
Failed:
 Namespace default
   Pod - bus
 Namespace kube-system
   Pod - storage-provisioner
Summary - Passed:22   Excluded:0   Failed:2   Total:24
Remediation: Create necessary Deployment object for every POD making any POD a first class citizen in your IaC architecture.

[control: Enforce Kubelet client TLS authentication - https://hub.armo.cloud/docs/c-0070] passed 👍
Description: Kubelets are the node level orchestrator in Kubernetes control plane. They are publishing service port 10250 where they accept commands from API server. Operator must make sure that only API server is allowed to submit commands to Kubelet. This is done through client certificate verification, must configure Kubelet with client CA file to use for this purpose.
Summary - Passed:2   Excluded:0   Failed:0   Total:2

Пример сводки

FRAMEWORKS: DevOpsBest (risk: 43.94), MITRE (risk: 15.93), ArmoBest (risk: 27.62), NSA (risk: 30.72)
+-----------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
|                             CONTROL NAME                              | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % RISK-SCORE |
+-----------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
| Access Kubernetes dashboard                                           |        0         |         0          |      98       |      0%      |
| Access container service account                                      |        41        |         0          |      45       |     91%      |
| Access tiller endpoint                                                |        0         |         0          |       0       |   skipped    |
| Allow privilege escalation                                            |        24        |         0          |      25       |     96%      |
| Allowed hostPath                                                      |        4         |         0          |      25       |     16%      |
.
.
.
.
.
+-----------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
|                           RESOURCE SUMMARY                            |       131        |         0          |      185      |    28.35%    |
+-----------------------------------------------------------------------+------------------+--------------------+---------------+--------------+

Методы развертывания

Kubescape может быть развернут на любом кластере Kubernetes для рутинной проверки, а также в конвейере CI/CD, чтобы гарантировать, что никакая неправильная конфигурация не попадет в производство. Он может быть запущен на любой машине, при условии, что на ней должен присутствовать файл kubeconfig для доступа к кластеру.

Его можно установить или запустить с помощью простого набора команд, которые доступны на портале ARMO. После регистрации на портале АРМО вы получаете идентификатор учетной записи. Вы также получаете набор команд, содержащих этот идентификатор учетной записи, чтобы все ваши кластеры или CI/CD-сканирования отображались на одной странице. На следующем изображении показано, как выглядят эти команды:

Если вы хотите запустить Kubescape внутри кластера Kubernetes с воздушной завесой, то вы можете установить утилиту Kubescape из Github-репозитория Kubescape и следовать инструкциям в разделе Offline/Air-gaped Environment Support на Github-репозитории Kubescape.

Где лучше всего использовать?

Kubescape может эффективно работать как на вашем обычном кластере, так и на эфемерных кластерах (созданных для проверки CI/CD). Kubescape сияет, когда речь идет о конфигурации артефактов внутри кластера (другими словами, объектов Kubernetes). Причиной этого является подробный анализ, доступный на портале ARMO для каждой неудачной проверки. На портале ARMO вы можете проанализировать проблему вплоть до отдельной строки в вашей конфигурации, из-за которой контроль не работает.

Интеграции

Kubescape изначально обеспечивает интеграцию с Prometheus, Slack, Jenkins, CircleCI, Github, GitLab, Azure-DevOps, GCP-GKE, AWS-EKS и т.д.. Шаги по интеграции хорошо документированы как в официальной документации ARMO, так и на странице Integrations на портале ARMO.

Заключение

И Kubescape, и kube-bench отличаются тем, какие фреймворки они поддерживают, как они развертываются, как они выполняют сканирование и предоставляют результаты. Лучше сказать, что у обоих есть свои сильные стороны. kube-bench доказывает свою состоятельность, когда дело доходит до сканирования хоста, разрешений на файлы и прав собственности, флагов для различных компонентов плоскости управления Kubernetes. С другой стороны, Kubescape проявляет себя при сканировании объектов внутри кластера, таких как стручки, пространства имен, учетные записи и т.д.. Следует помнить, что портал АРМО — это хостинговое решение, и для его использования вам придется делиться с ним информацией о внутрикластерных ресурсах через Kubescape. Однако, как мы уже говорили выше, вы также можете использовать Kubescape только в режиме CLI (как указано в разделе Offline/Air-gaped Environment Support в GitHub-репозитории Kubescape).

Подводя итог, я считаю, что kube-bench и Kubescape дополняют друг друга. kube-bench следует использовать при настройке кластера или добавлении нового узла в кластер, поскольку разрешения на файлы и права собственности — это одноразовые задачи, и очень важно сохранить конфигурацию кластера от несанкционированного доступа. После запуска кластера/нового узла Kubescape можно использовать для регулярного сканирования артефактов внутри кластера, так как он позволяет найти проблему вплоть до одной строки конфигурации.

Надеюсь, вы нашли эту статью информативной и увлекательной. Чтобы получить больше сообщений, подобных этому, подпишитесь на нашу еженедельную рассылку. Я буду рад услышать ваши мысли по поводу этого поста, поэтому начните разговор на LinkedIn 🙂

Если вам нужна помощь в обеспечении безопасности в облаке, ознакомьтесь с нашими возможностями, как мы помогаем стартапам и предприятиям в качестве поставщика консалтинговых услуг DevSecOps.