Безопасность учетной записи службы Kubernetes

Question

Я пытаюсь понять последствия для безопасности предоставления разрешения kubernetes serviceaccount для выполнения развертываний, создания служб и т. Д. c. Это роль кластера с привязкой ролей в пространстве имен.

Пример использования - использование учетной записи службы для автоматизации / оркестровки некоторых задач внутри кластера. Версия 1.16

Answer 1

Позвольте мне обсудить это.

Согласно docs .

• A Роль всегда _ устанавливает разрешения в определенном пространстве имен __; при создании роли вы должны указать пространство имен, которому она принадлежит

• ClusterRole , в отличие от - это ресурс без пространства имен . Ресурсы имеют разные имена (Role и ClusterRole), потому что объект Kubernetes всегда должен быть либо в пространстве имен, либо без него; не может быть одновременно.

Привязка роли предоставляет разрешения, определенные в роли, пользователю или группе пользователей. Он содержит список субъектов (пользователей, групп или учетных записей служб) и ссылку на предоставляемую роль. RoleBinding предоставляет разрешения в пределах определенного пространства имен c, тогда как ClusterRoleBinding предоставляет доступ ко всему кластеру.

• Если вы хотите определить роль в пространстве имен, используйте Role; если вы хотите определить роль для всего кластера, используйте ClusterRole.
• RoleBinding может ссылаться на любую роль в том же пространстве имен . В качестве альтернативы RoleBinding может ссылаться на ClusterRole и связывать эту ClusterRole с пространством имен RoleBinding . Если вы хотите связать ClusterRole со всеми пространствами имен в вашем кластере, вы используете ClusterRoleBinding. 1052 * Лучшее решение - предоставить как можно меньше разрешений .
  • Предоставить роль учетной записи службы c для конкретного приложения (наилучшее практика)
  • Предоставить роль учетной записи службы "по умолчанию" в пространстве имен
  • Предоставить роль всем учетным записям службы в пространстве имен
  • Предоставить ограниченную роль всем службам учетные записи на уровне кластера (не рекомендуется)
  • Предоставить суперпользователю доступ ко всем учетным записям служб на уровне кластера (настоятельно не рекомендуется)

  На этот вопрос нет однозначного ответа, потому что вам необходимо спланировать и протестировать действие / разрешения между вашим приложением / развертыванием и Kubernetes API. Fe в ресурсах с именами или без имен, в одном пространстве имен или во всем кластере.

  В вашем примере вы можете просто использовать Role / Rolebinding, если вы работаете в одном пространстве имен. Вы можете использовать ClusterRole / Rolebinding и расширять разрешения с помощью дополнительной привязки RoleBinding, позволяя ServiceAccount создавать новые объекты k8s в другом пространстве имен.

  Предполагая, что мы говорим о ServiceAccount для развертывания, здесь вы можете найти полезный совет для " RBA C в развертываниях: пример использования "

  Если вы создаете ServiceAccount для своего развертывания и создаете соответствующие Role / ClusterRole и Rolebinding / ClusterRoleBinding:

  , вы можете выполнить:

  kubectl can-i get secrets --as=system:serviceaccount:[namespace]:[service_account_name] -n [target_namespace]
  

  Для тестирования возьмите взгляните также на Кластеры доступа с использованием Kubernetes API .

  Эта команда покажет вам, определен ли конкретный ServiceAccount ( субъектом в Rolebinding / ClusterRolebinding ) имеет разрешения ( определяется глаголами в Role / ClusteRole ) для получения секретов ( определяется ресурсами Role / ClusterRole ) в указанном пространство имен.

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

  При работе с RBA C в Kubernetes вы должны учитывать указанные ниже темы:

  • Наличие нескольких пользователей с разными свойствами, создание надлежащего механизма аутентификации.

  • Полный контроль над операциями, которые может выполнять каждый пользователь или группа пользователей .

  • Полный контроль над операциями, которые может выполнять каждый процесс внутри модуля. Ограничьте видимость определенных ресурсов пространств имен.

Answer 2

Сервисная учетная запись может использоваться для предоставления разного уровня доступа разным целям. для разработчика ClusterRole необходимо перечислять, получать и просматривать ресурсы, но не удалять. но администратор может удалять и создавать ресурсы.

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