Политики безопасности

На странице Политики безопасности представлены результаты анализа политик безопасности кластера Kyverno. Доступен просмотр в разрезе политики или неймспейса.

На странице есть возможность скачать отчет в формате CSV или PDF.

Чтобы добавить отчет в формате CSV в MS Excel:

создайте новый файл MS Excel, перейдите в раздел “Данные”.
В левой части панели управления выберите “Из текста”, выберите файл отчета, который вы скачали, нажмите “Импорт”.
В модальном окне “Мастер текстов (импорт) выберите формат данных “С разделителями”, нажмите “Далее”.
Выберите вариант разделитея “Запятая”, нажмите “Далее”.
Выберите формат данных столбцов “Общий”, нажмите “Готово.

Политики Kyverno

Политика	Описание
automated-satoken-mount-used	По умолчанию Kubernetes реализует подстановку ServiceAccount Token в Pod. При помощи этого Token можно взаимодействовать с API-сервером. Рекомендуется отключать эту функцию.
hostnetwork-is-used	Использование параметра HostNetwork позволяет обойти требования сетевых политик.
image-from-dockerhub	Использование общедоступных образов может быть небезопасным. Рекомендуется использовать доверенные и проверенные образы, которые расположены в корпоративном Registry
service-nodeport-used	NodePort можно использовать для предоставления доступа к приложениям извне кластера. Рекомендуется не использовать такой подход, т. к. его нельзя контролировать при помощи NetworkPolicy. Вместо этого лучше использовать альтернативные подходы, например Ingress, для предоставления внешнего доступа к приложениям кластера
default-ns-is-used	Не рекомендуется использовать namespace с именем default. Вместо этого лучше использовать специально созданные namespace под нужды специалистов и/или приложений
container-is-privileged	Этот флаг запускает контейнер в привилегированном режиме, что может быть использовано злоумышленником, например для повышения привилегий и развития атаки на кластер. Рекомендуется не использовать этот флаг, т. к. для большинства контейнеров он не требуется
absence-of-cpu-requests	Kubernetes обладает возможностью установкии ограничений на потребление ресурсов CPU запускаемыми контейнерами. В случае, если ограничения отсутствуют, может произойти Denial of Service (DoS), обусловленный тем, что pod (контейнер) будет использовать все ресурсы узла, которые ему доступны. По этому хорошей практикой считается установка параметров Request (запрос на ресурс) на CPU
absence-of-ram-requests-limits	Kubernetes обладает возможностью установкии ограничений на потребление ресурсов RAM запускаемыми контейнерами. В случае, если ограничения отсутствуют, может произойти Denial of Service (DoS), обусловленный тем, что pod (контейнер) будет использовать все ресурсы узла, которые ему доступны. По этому хорошей практикой считается установка параметров Request (запрос на ресурс) и Limits () на RAM.
secrets-in-env-var	Секреты, указываемые в качестве переменных окружения, могут быть скомпрометированы. Рекомендуется использовать сторонние системы управления секретами (Secret Management).
sysadmin-capabilities-used	Эта настройка обладает крайне большими полномочиями. Согласно документации на Linux Capabilities: CAP_SYS_ADMIN - this capability is overloaded, Don’t choose CAP_SYS_ADMIN if you can possibly avoid it!. Использование возможностей этой настройки может привести к проблемам информационной безопасности, в том числе «побегу» (escape) из Pod (container). Для большинства приложений эта настройка не требуется, поэтому рекомендуется не использовать ее.
master-tolerations-are-set	Использование tolerations позволяет запускать Pod на узлах, которые обладают соответствующими taints. Рекомендуется не запускать Pod на Master Nodes, которые по умолчанию обладают taints: node-role.kubernetes.io/master:NoSchedule.
tag-latest-is-used	При использовании этого tag трудно понять, какая именно версия была запущена, что особенно важно для промышленной среды. Например, Pod (container) мог содержать уязвимости или была запущена версия, где были исправлены не все ИБ дефекты.