Применение принципа наименьших привилегий в Kubernetes с помощью RBAC


Что такое принцип наименьших привилегий?

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

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

На объектах доступ к определенным зонам, таким как серверные комнаты, имеют только те сотрудники, которые имеют право работать в этих помещениях. Доступ к некоторым критическим местам на таких объектах имеют только опытные или старшие члены команды из смежных отделов.

Аналогичное мышление применимо и к PoLP. Например, в программном обеспечении для управления персоналом доступ к кадровым документам, скорее всего, будет иметь только сотрудник отдела кадров. Аналогично, определенные действия — например, развертывание версий приложений в производство — могут быть настроены таким образом, чтобы их могли выполнять только старшие инженеры.

PoLP также присутствует в приложениях «программное обеспечение как услуга» (SaaS), где пользователи имеют различные роли в приложении в зависимости от их конкретных задач.

Защита программных систем требует баланса между обеспечением того, чтобы система не стала слишком ограничивающей для заинтересованных сторон, и предотвращением ее чрезмерной уязвимости для субъектов угроз. PoLP помогает нам достичь этого баланса, обеспечивая безопасность системы и одновременно минимизируя трудности, связанные с доступом.

Кроме того, PoLP помогает поддерживать эффективную и надежную работу системы. Системы становятся менее восприимчивыми к простоям из-за атак вредоносного ПО или рискованных действий пользователей, таких как внедрение небезопасного кода в производство или смена паролей администраторов.

В этой статье мы рассмотрим, как Kubernetes (K8s) поддерживает PoLP путем внедрения контроля доступа на основе ролей.

Применение принципа наименьших привилегий к доступу в Kubernetes

Kubernetes управляет рабочими нагрузками по оркестровке контейнеров. Он предоставляет организациям и разработчикам платформу для автоматизации развертывания, управления и масштабирования контейнерных приложений. Это означает, что при создании и поддержке развернутых приложений доступ к среде Kubernetes необходим различным сотрудникам отделов разработки, эксплуатации и ИТ.

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

Как Kubernetes управляет доступом с помощью RBAC

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

Объекты Kubernetes — это постоянные объекты, которые определяют, какие контейнерные приложения запущены, их ресурсы и политики, определяющие работу этих приложений. По сути, они определяют желаемое состояние кластера. Мы можем создавать, изменять или удалять объекты с помощью API Kubernetes.

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

Разрешения в Kubernetes определяются с помощью объектов Role или ClusterRole. Затем определенные разрешения назначаются в виде правил с помощью объектов RoleBinding и ClusterRoleBinding. API RBAC объявляет четыре следующих типа объектов Kubernetes:

  • Role — управляет разрешениями, которые применяются к ресурсам в пределах отдельного пространства имен.
  • ClusterRole — управляет разрешениями, которые применяются ко всему кластеру.
  • RoleBinding — назначает роль учетной записи или группе в определенном пространстве имен.
  • ClusterRoleBinding — назначение роли ClusterRole учетной записи или группе для всех пространств имен в кластере.

В следующих двух разделах мы рассмотрим, как политики RBAC согласуются с PoLP при ограничении доступа к ресурсам в кластерах.

Определение разрешений

Чтобы правильно установить права доступа, необходимо настроить Kubernetes так, чтобы отразить роль каждого члена команды, помня о практике PoLP. Использование Roles и ClusterRoles — чрезвычайно эффективный способ сделать это. Роли применяются к ресурсам в пределах одного пространства имен, а кластерные роли — к ресурсам всего кластера.

В этом разделе мы рассмотрим, как ограничить доступ к определенным частям системы с помощью ролей и кластерных ролей.

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

Для этого начните с определения объектов Role и ClusterRole в YAML-файле. Ниже приведен пример определения роли для предоставления доступа на чтение к секретам в пространстве имен разработки:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
Войти в полноэкранный режим Выйти из полноэкранного режима

В приведенном выше коде указана версия API. RBAC использует группу API rbac.authorization.k8s.io для настройки политик авторизации через API Kubernetes. Затем он указывает тип определения как Role, и упоминает пространство имен, к которому оно будет применяться — development. Это предполагает, что development — это группа пространств имен для ресурсов, которые использует команда разработчиков. Далее, роль получает имя secretpod-reader.

Раздел rules содержит ресурсы, к которым применяется правило, и действия, которые роль может выполнять над этими ресурсами. В этом разделе также содержатся некоторые глаголы правил. Kubernetes использует такие глаголы правил, как write, watch, read и delete для управления разрешениями в широких классах.

Ниже показано, как определить ClusterRole для разрешения доступа на чтение к внешним блокам в кластере:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"
Войти в полноэкранный режим Выйти из полноэкранного режима

Обратите внимание, что в приведенном выше коде не указано пространство имен в метаданных. Это потому, что кластерные роли не имеют пространства имен. Поэтому в разделе метаданных вы указали только имя роли ClusterRole как pod-reader.

Далее вы можете привязать роль к группе ресурсов с именами для разработки и привязать ClusterRole к кластеру. Теперь ваша команда — и никто другой — может просматривать необходимые секреты в ресурсах разработки. Применение PoLP таким образом позволяет вашей команде получить доступ к тому, что необходимо для выполнения задач разработки, но не позволяет всем остальным в вашей организации получить доступ к этим капсулам и ресурсам.

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

Назначение разрешений

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

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

Если инженером DevOps является пользователь по имени Sola, вы можете назначить созданную выше Role пользователю sola в пространстве имен разработки. Таким образом, sola сможет читать секреты в этом пространстве имен.

Обратите внимание, что имя sola чувствительно к регистру. Определение ролевой привязки выглядит следующим образом:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: secret-reader
  namespace: development
subjects:
- kind: User
  name: sola
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: secret-reader 
  apiGroup: rbac.authorization.k8s.io
Войти в полноэкранный режим Выйти из полноэкранного режима

В приведенном выше коде вы:

  • Указали тип RoleBinding.
  • Указали роль под названием secret-reader и пространство имен, development, к которому применяется привязка роли.
  • Укажите sola в качестве пользователя в разделе субъекты. Вы также можете указать несколько субъектов.
  • Прикрепите соответствующую роль к привязке в разделе roleRef. Следует помнить, что после создания привязки роль или кластерная роль, прикрепленная к привязке в разделе roleRef, не может быть изменена.

Приведенный выше пример RoleBinding служит для случаев использования, когда определенный член команды разработчиков должен иметь доступ к секретным ключам, используемым в конфигурации приложения — таким как пары ключей API и переменные окружения.

В дальнейшем вам придется использовать ClusterBinding для предоставления прав доступа ко всему кластеру. В следующем примере вы увидите, как можно использовать ClusterBinding, чтобы разрешить любому пользователю из группы ops читать pods в любом пространстве имен в кластере. Обратите внимание, что имя ops чувствительно к регистру:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-global
subjects:
- kind: Group
  name: ops
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
Вход в полноэкранный режим Выход из полноэкранного режима

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

Обеспечение безопасности конфигураций K8

Ролевой доступ может сыграть существенную роль в соблюдении принципа наименьших привилегий. К счастью, встроенная структура RBAC в Kubernetes предлагает значительную функциональность в этой области. Возможность создания и привязки ролей является чрезвычайно мощным средством обеспечения того, чтобы только минимальное количество пользователей имело необходимый доступ к любым ресурсам. Это ограничивает возможности потенциальных злоумышленников, не препятствуя выполнению должностных функций любого члена команды. Для примера использования Kubernetes RBAC посмотрите, как мы используем ее в Snyk.

Чтобы узнать больше о том, как правильно и безопасно реализовать PoLP в вашей среде Kubernetes, посетите Snyk и ознакомьтесь с другими постами в блоге Snyk.

Ресурсы Kubernetes:

  • Безопасность Kubernetes
  • Образы Docker в Kubernetes
  • Руководство по мониторингу Kubernetes
  • Настройки Kubernetes securityContext
  • Операторы Kubernetes

Безопасность Kubernetes в упрощенном виде

Закажите демонстрацию сегодня и обеспечьте безопасность ваших контейнеров и конфигураций Kubernetes с помощью Snyk.

Запланировать демонстрацию

Оцените статью
devanswers.ru
Добавить комментарий