Ресурс Role определяет, какие действия можно предпринимать и на каких ресурсах (или какие типы HTTP-запросов можно выполнять и на каких ресурсах RESTful). В следующем ниже листинге определяется роль, которая позволяет пользователям получать и выводить список служб в пространстве имен boo.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: boo
name: service-reader
rules:
- apiGroups: [""]
verbs: ["get", "list"]
resources: ["services"]

Ресурс Role будет создан в пространстве имен boo. В главе 8 вы узнали, что каждый тип ресурса принадлежит к группе API, которую вы указываете в манифесте ресурса в поле apiVersion (вместе с версией). В определении роли необходимо указывать группу apiGroup для ресурсов, перечисленных в каждом включенном в определение правиле. Если вы разрешаете доступ к ресурсам, принадлежащим разным группам API, вы используете несколько правил.

РИМЕЧАНИЕ. В данном примере вы предоставляете доступ ко всем ресурсам службы, но при этом вы также можете разрешать доступ только к конкретным экземплярам служб, указав их имена через дополнительное поле resourceNames.

Создание роли

Создайте предыдущую роль в пространстве имен boo:

$ kubectl create -f service-reader.yaml -n boo

ПРИМЕЧАНИЕ. Параметр -n является аббревиатурой для параметра —namespace.

Если вы используете Google Kubernetes Engine (GKE), то предыдущая команда может не сработать, так как у вас нет прав администратора кластера. Чтобы предоставить эти права, выполните следующую ниже команду:

$ kubectl create clusterrolebinding cluster-admin-binding

Вместо создания роли service-reader из файла YAML вы также можете ее создать с помощью специальной команды kubectl create role. Давайте воспользуемся этим методом для создания роли в пространстве имен bar:

$ kubectl create role service-reader --verb=get --verb=list --resource=services -n bar

Эти две роли позволяют выводить список служб в пространствах имен boo и bar из двух модулей (работающих соответственно в пространствах имен boo и bar). Но создание двух ролей недостаточно (вы можете проверить, выполнив команду curl еще раз). Вам нужно привязать каждую из ролей к учетным записям ServiceAccount в соответствующих пространствах имен.

Привязка роли к учетной записи службы

Роль определяет, какие действия могут выполняться, но не определяет, кто может их выполнять. Для этого необходимо привязать роль к субъекту, которым может быть пользователь, учетная запись службы или группа (пользователей или учетных записей служб). Привязка ролей к субъектам достигается путем создания ресурса привязки роли, RoleBinding. Для того чтобы привязать роль к учетной записи службы по умолчанию, выполните следующую ниже команду:

$ kubectl create rolebinding test --role=service-reader --serviceaccount=boo:default -n boo

Данная командой Вы создаете привязку роли RoleBinding, которая привязывает роль service-reader к учетной записи по умолчанию в пространстве имен boo. Вы создаете привязку роли RoleBinding в пространстве имен boo.

ПРИМЕЧАНИЕ. Для того чтобы привязать роль к пользователю, а не к учетной записи службы, используйте параметр —user, указав имя пользователя. Для того чтобы привязать ее к группе, примените параметр —group.

Следующий ниже листинг показывает YAML созданной вами привязки роли.

$ kubectl get rolebinding test -n boo -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: test
namespace: boo
…
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: service-reader
subjects:
- kind: ServiceAccount
name: default
namespace: boo

Привязка роли всегда ссылается на одну роль (как явствует из свойства roleRef), но может привязывать роли к нескольким субъектам subjects (например, одной или нескольким учетным записям и любым количествам пользователей или групп). Поскольку эта привязка роли привязывает роль к учетной записи в пространстве имен boo, под которым работает модуль, теперь вы можете вывести список служб из этого модуля.

Команда получения служб с сервера API

/ # curl localhost:8001/api/v1/namespaces/boo/services