Немного о RBAC

В kubernetes есть сущность, которая называется RoleBinding. Она определяет, каким субъектам какая роль будет назначена. RoleBinding действует в рамках namespace, в котором она создана. Для разрешения действий во всех namespace без ограничений необходимо создавать ClusterRoleBinding, который является cluster-wide объектом.

Пример RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edit
  namespace: project-a-devel
subjects:
- kind: Group
  name: sre
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Эта роль:

Действует в рамках namespace project-a-devel - (metadata:)
Применяется к пользователям в группе sre (/O=sre) - (subjects:)
Разрешает действия, описанные в созданной по-умолчанию кластерной роли (ClusterRole) edit - (roleRef:)

Какие права предоставляет ClusterRole edit можно посмотреть через kubectl get clusterrole edit -o yaml (ниже приведена часть вывода)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-edit: "true"
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: edit
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/attach
  - pods/exec
  - pods/portforward
  - pods/proxy
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
...

В секции rules описано в каких группах api (apiGroups:) над какими ресурсами (resources:) какие действия (verbs:) может совершать данная роль

Пример выдачи прав пользователю через x509 сертификат

При использовании сертификатов пользователя и группу как таковые создавать не надо, т.к. аутентификация пользователя происходит по параметрам CN(CommonName) и O(Organization), указанным в подписанным сертификате, которые означают пользователя и группу(ы) соответственно, а дальнейшая авторизация действия пользователя уже по описанным для этих CN,O в Role и RoleBinding

В случае использования в k8s-кластере сампоподписанного CA процедура выглядит примерно так:

Создать ключ и сгенерировать csr с соответсвующими CN, O

openssl genrsa -out vpupkin.key 4096
openssl req -new -key vpupkin.key -out vpupkin.csr -subj "/CN=v.pupkin/O=devops/O=sre"

Зайти на k8s master и подписать csr с помощью своего CA

openssl x509 -req -in vpupkin.csr -CA /etc/kubernetes/ssl/ca.pem -CAkey /etc/kubernetes/ssl/ca-key.pem -CAcreateserial -out vpupkin.crt -days <requiredDays>

Полученный сертификат и сгенерированный ранее ключ добавить в конфиг kubectl в ${HOME}/.kube/config

Заметка

Надо внимательно проверять подписываемый csr, чтобы не оказалось, что пользователь себе установил, например, группу /O=system:masters, у которой по-умолчанию права cluster-admin