Создали Kubernetes? Теперь попробуйте эти 5 инструментов RBAC для аудита разрешений

Kubernetes RBAC — это эффективный метод авторизации на основе ролей, используемый для предоставления детального доступа к ресурсам в кластере Kubernetes.

Однако, если он не используется должным образом, он может легко привести к катастрофе соответствия. Вот почему нам нужны инструменты RBAC для аудита и обнаружения рискованных разрешений в Kubernetes.

В этой статье мы обсудим, что такое Kubernetes RBAC, почему важно проводить аудит рискованных разрешений и узнаем, какие инструменты лучше всего помогут нам в аудите рискованных разрешений!

Что такое RBAC?

Управление доступом на основе ролей (RBAC) — это механизм безопасности, в котором каждая авторизация доступа основана на ролях, назначенных пользователю. Таким образом, с помощью этой системы можно ограничить доступ к ресурсам кластера Kubernetes (пространствам имен, модулям, заданиям) для приложений или пользователей.

В Kubernetes политики RBAC можно использовать для управления правами доступа системного пользователя (пользователя или группы), а также учетных записей служб (служебной учетной записи).

Существуют и другие способы авторизации пользователей в Kubernetes, такие как ABAC (управление доступом на основе атрибутов), через веб-перехватчик или авторизацию узла, но наиболее широко используемый и собственный механизм авторизации, доступный в стабильной версии, — это RBAC.

Практически все взаимодействие с ресурсами осуществляется через его API-сервер, а это означает, что, в конце концов, все ограничивается выполнением HTTP-запросов к указанному серверу (неотъемлемый компонент мастер-ноды или Панели управления).

В Kubernetes есть четыре объекта, связанных с RBAC, которые можно комбинировать для установки разрешений на доступ к ресурсам кластера. Это Role, ClusterRole, RoleBinding и ClusterRoleBinding. Для работы с этими объектами, как и со всеми объектами Kubernetes, необходимо использовать Kubernetes API.

Роли в Кубернете

В Kubernetes есть два типа ролей: Role и ClusterRole. Самая большая разница между ними заключается в том, что роль принадлежит конкретному пространству имен, а роль ClusterRole является глобальной для кластера. Итак, в случае ClusterRole ее имя должно быть уникальным, поскольку она принадлежит кластеру. В случае роли два разных пространства имен могут иметь роль с одним и тем же именем.

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

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

Наконец, нам нужен «клей», который привязывает роль к учетной записи (пользователю или службе) или группе. Для этого в Kubernetes есть два ресурса: RoleBinding и ClusterRoleBinding. Привязка RoleBinding может ссылаться на роль в том же пространстве имен, а привязка ClusterRoleBinding может ссылаться на любую роль в любом пространстве имен и глобально назначать разрешения.

В качестве примечания, разрешения разрешают доступ только к ресурсам, потому что «по умолчанию все запрещено» и можно назначить несколько ролей одному и тому же пользователю.

Единственным предварительным условием для использования RBAC является то, что он включен в нашем кластере с помощью параметра « –authorization-mode=RBAC ». Мы можем проверить это с помощью команды:

 kubectl api-versions

Что такое рискованные разрешения RBAC и как их исправить?

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

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

Ниже приведены некоторые из лучших инструментов RBAC для аудита разрешений на основе разных языков и пользовательских интерфейсов.

КубиСкан

KubiScan — это инструмент RBAC на основе Python для сканирования рискованных разрешений в кластере Kubernetes. Инструмент должен быть запущен в главном узле, а затем его можно запустить непосредственно из терминала, чтобы получить список рискованных разрешений. Kubiscan можно использовать для поиска рискованных ролей, ClusterRoles, RoleBindings, ClusterBindings, Subjects, Pods и даже Container.

Кран

Krane от Appvia — это инструмент статического анализа и визуализации Kubernetes RBAC на основе Ruby. Его можно запускать как локально как CLI, так и в конвейере CI/CD. Более того, он также может работать как отдельная служба в контейнере Kubernetes. Krane предоставляет возможность анализировать разрешения RBAC с помощью фасетных древовидных и графических представлений сети. Он также выдает предупреждения о любых рискованных разрешениях через интеграцию со Slack.

Инструмент RBAC

Инструмент RBAC от InsightCloudSec — это автономный инструмент аудита разрешений, созданный с помощью Go. Он не только позволяет вам сканировать и выделять рискованные разрешения RBAC, но также позволяет создавать политику RBAC на основе аудита разрешений с помощью функции Auditgen. Инструмент RBAC также предлагает функцию визуализации RBAC.

Фэйрвиндс

Fairwinds Insight — это автономный инструмент, предоставляющий ряд функций безопасности и соответствия требованиям Kubernetes. Его функция применения политик позволяет вам проверять разрешения RBAC и проверять их на соответствие стандартным и настраиваемым политикам. Fairwinds предлагает демо-версию по запросу.

Диспетчер разрешений

Permission Manager от Sighup — это инструмент управления разрешениями Kubernetes на основе Javascript. Он предлагает простой и инициативный способ управления разрешениями пользователей в кластере Kubernetes. Permission Manager также предлагает корпоративную версию инструмента, которая позволяет выполнять базовый аудит разрешений RBAC.

Вывод

Kubernetes RBAC — это эффективный способ управления доступом к ресурсам в кластере Kubernetes. Однако, если это не реализовано должным образом, это может привести к проблемам с безопасностью и соответствием требованиям. Однако этого можно избежать, постоянно проверяя разрешения с помощью инструментов аудита RBAC.

Вас также могут заинтересовать лучшие практики Kubernetes.