Kubernetes RBAC – это эффективный метод авторизации на основе ролей, используемый для предоставления доступа к ресурсам в кластере Kubernetes.
Однако, если его использовать неправильно, он может легко привести к катастрофе с нарушением нормативных требований.
Вот почему нам нужны инструменты RBAC для аудита и обнаружения рискованных прав в Kubernetes.
В этой статье мы обсудим, что такое Kubernetes RBAC, почему важно проводить аудит таких прав, а также откроем для себя инструменты, которые лучше всего помогут нам в аудите!
Что такое RBAC?
Role-Based Access Control(RBAC) – это механизм безопасности, в котором каждое разрешение доступа основано на ролях, назначенных пользователю.
Благодаря этой системе можно ограничить доступ приложений или пользователей к ресурсам кластера Kubernetes (пространства имен, поды, джобы).
В Kubernetes политики RBAC могут использоваться для управления правами доступа системного пользователя (User или Group), а также учетных записей сервисов (Service Account).
Существуют и другие способы авторизации пользователей в Kubernetes, такие как ABAC (Attribute-based access control), через Webhook или Node Authorization, но наиболее широко используемым и встроенным механизмом авторизации, доступным в стабильной версии, является RBAC.
Практически все взаимодействие с ресурсами осуществляется через API-сервер, что означает, что в конечном итоге все сводится к выполнению HTTP-запросов к указанному серверу (важнейший компонент мастер ноды или панели управления).
Kubernetes имеет четыре объекта RBAC, которые могут быть объединены для установки прав доступа к ресурсам кластера.
Это Role, ClusterRole, RoleBinding и ClusterRoleBinding.
Для работы с этими объектами, как и со всеми объектами Kubernetes, необходимо использовать Kubernetes API.
Роли в Kubernetes
В Kubernetes существует два типа ролей, которые называются Role и ClusterRole.
Самое большое различие между ними заключается в том, что роль принадлежит конкретному пространству имен, в то время как роль ClusterRole является глобальной для кластера.
Поэтому в случае с ClusterRole ее имя должно быть уникальным, поскольку она принадлежит кластеру.
В случае с Role два разных пространства имен могут иметь Role с одинаковым именем.
Еще одно различие, которое следует упомянуть, заключается в том, что Role позволяет получить доступ к ресурсам, находящимся в одном пространстве имен, в то время как ClusterRole, помимо того, что может предоставлять доступ к ресурсам в любом пространстве имен, может также предоставлять доступ к ресурсам в одном пространстве имен, таким как узлы и т.д.
Теперь, когда мы знаем типы ролей, необходимо понять, кому мы можем назначить эти роли.
В данном случае у нас есть учетные записи пользователей, учетные записи служб и группы.
Учетные записи пользователей – это учетные записи, назначенные конкретному пользователю, в то время как служебные учетные записи используются процессами. Например, представьте, что нашему приложению необходим программный доступ к ресурсам кластера, для этого мы будем использовать учетную запись службы.
Наконец, нам нужен “клей”, который связывает роль с учетной записью (пользовательской или сервисной) или группой.
Для этого в Kubernetes есть два ресурса: RoleBinding и ClusterRoleBinding.
RoleBinding может ссылаться на роль, находящуюся в том же пространстве имен, а ClusterRoleBinding может ссылаться на любую роль в любом пространстве имен и назначать разрешения глобально.
Как примечание, разрешения разрешают доступ только к ресурсам, поскольку “по умолчанию все запрещено”, и одному и тому же пользователю можно назначить несколько ролей.
Единственным предварительным условием для использования RBAC является то, что он включен на нашем кластере с помощью опции “-authorization-mode=RBAC”.
Мы можем проверить это с помощью команды:
kubectl api-versions
Какие риски в направильных настройках RBAC и как их исправить?
Любое разрешение, которое позволяет или может позволить несанкционированный доступ к ресурсам пода, считается рискованным.
Например, если пользователь имеет право редактировать, он может редактировать свою собственную роль и может получить доступ к ресурсам, к которым он не имеет права доступа.
Это может привести к проблеме соответствия нормативным требованиям.
Аналогичным образом, если старые права оставлены неисправленными, некоторые пользователи могут получить доступ к ресурсам, которые им больше не нужны.
При наличии большого количества ролей поиск таких избыточных прав вручную является сложной и трудоемкой задачей.
Для облегчения этого процесса существует ряд инструментов аудита разрешений RBAC, которые помогают просканировать весь кластер на предмет обнаружения рискованных прав.
Также важно понимать, что эффективность RBAC зависит от актуальной политики RBAC, которая, в свою очередь, требует регулярного аудита.
Ниже приведены некоторые из лучших инструментов для аудита на RBAC основе различных языков и пользовательских интерфейсов.
KubiScan
KubiScan – это инструмент на базе Python для сканирования рискованных прав кластере Kubernetes.
Инструмент должен быть запущен на мастер-ноде, а затем его можно запустить непосредственно из терминала, чтобы получить список избыточных прав.
Kubiscan можно использовать для поиска рискованных Roles, ClusterRoles, RoleBindings, ClusterBindings, Subjects, Подов и даже контейнеров.
Ранее был рассмотрен:
🍿 KubiScan: проверка кластера Kubernetes на наличие рискованных прав
Krane
Krane от Appvia – это основанный на Ruby инструмент статического анализа и визуализации Kubernetes RBAC.
Его можно запускать как локально в качестве CLI, так и в пайплайне CI/CD.
Кроме того, он может работать как отдельный сервис внутри пода Kubernetes.
Krane предоставляет возможность анализа разрешений RBAC с помощью древовидных и графовых сетевых представлений.
Он также выдает предупреждения о любых рискованных правах благодаря интеграции со Slack.
RBAC Tool
RBAC Tool от InsightCloudSec – это отдельный инструмент аудита прав, созданный на базе Go.
Он позволяет не только сканировать и выделять рискованные разрешения RBAC, но и генерировать политику RBAC на основе аудита с помощью функции Auditgen.
Инструмент RBAC также предлагает функцию визуализации RBAC.
Fairwinds
Fairwinds Insight – это отдельный инструмент, предоставляющий ряд функций обеспечения безопасности и соответствия Kubernetes.
Его функция внедрения политик позволяет вам проводить аудит прав RBAC и проверять их на соответствие стандартным и настраиваемым политикам.
Permission Manager
Permission Manager от Sighup – это инструмент управления правами Kubernetes на базе Javascript.
Он предлагает простой и инициативный способ управления разрешениями пользователей в кластере Kubernetes.
Permission Manager также предлагает корпоративную версию инструмента, которая позволяет выполнять базовый аудит прав доступа RBAC.
Заключение
Kubernetes RBAC – это эффективный способ управления доступом к ресурсам в кластере Kubernetes.
Однако при неправильной реализации это может привести к проблемам безопасности и соответствия нормативным требованиям.
Однако этого можно избежать путем постоянного аудита прав с помощью инструментов аудита RBAC.
см. также:
- ☸️ Kubernetes и RBAC: ограничение доступа пользователя в одном namespace
- ☸️ Ломаем и чиним Kubernetes
- ☸️ Управление автогенерируемыми секретами в чартах helm
- ☸️ Peirates : Инструмент для тестирования на проникновение Kubernetes
- ☸️ Побег из контейнера Kubernetes с помощью монтирования HostPath
- ✔️ Контрольный список повышения безопасности Linux ( чек-лист )
- 🐳 Обзор сканеров безопасности контейнеров для поиска уязвимостей
