Compare languages | The user-authz module: usage

Example of assigning rights to a cluster administrator

Пример назначения прав администратору кластера

The example uses the experimental role-based.

Пример использует экспериментальную ролевую модель.

To grant access to a cluster administrator, use the role d8:manage:all:manager in ClusterRoleBinding.

Для назначения прав администратору кластера используйте роль d8:manage:all:manager в ClusterRoleBinding.

Example of assigning rights to a cluster administrator (User joe):

Пример назначения прав администратору кластера (User joe):

yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cluster-admin-joe subjects:

  • kind: User name: joe apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: d8:manage:all:manager apiGroup: rbac.authorization.k8s.io

yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cluster-admin-joe subjects:

  • kind: User name: joe apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: d8:manage:all:manager apiGroup: rbac.authorization.k8s.io

The rights that the user will get will be limited to namespaces starting with d8- or kube-.

Права, которые получит пользователь, будут ограничены рамками пространств имён, начинающихся с d8- или kube-.

The user will be able to:

  • View, modify, delete, and create Kubernetes resources and DKP modules;
  • Modify module configurations (view, modify, delete, and create moduleConfig resources);
  • Execute the following commands on pods and services:
  • kubectl attach
  • kubectl exec
  • kubectl port-forward
  • kubectl proxy

Пользователю будут доступны следующие права:

  • Просмотр, изменение, удаление и создание ресурсов Kubernetes и модулей DKP.
  • Изменение конфигурации модулей (просмотр, изменение, удаление и создание ресурсов moduleConfig).
  • Выполнение следующих команд к подам и сервисам:
  • kubectl attach;
  • kubectl exec;
  • kubectl port-forward;
  • kubectl proxy.

Example of assigning rights to a network administrator

Пример назначения прав сетевому администратору

The example uses the experimental role-based.

Пример использует экспериментальную ролевую модель.

To grant a network administrator access to manage the network subsystem of the cluster, use the role d8:manage:networking:manager in ClusterRoleBinding.

Для назначения прав сетевому администратору на управление сетевой подсистемой кластера используйте роль d8:manage:networking:manager в ClusterRoleBinding.

Example of assigning rights to a network administrator (User joe):

Пример назначения прав сетевому администратору (User joe):

yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: network-admin-joe subjects:

  • kind: User name: joe apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: d8:manage:networking:manager apiGroup: rbac.authorization.k8s.io

yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: network-admin-joe subjects:

  • kind: User name: joe apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: d8:manage:networking:manager apiGroup: rbac.authorization.k8s.io

The rights that the user will get will be limited to the following list of DKP module namespaces from the networking subsystem (the actual list depends on the list of modules included in the cluster):

  • d8-cni-cilium
  • d8-cni-flannel
  • d8-cni-simple-bridge
  • d8-ingress-nginx
  • d8-istio
  • d8-metallb
  • d8-network-gateway
  • d8-openvpn
  • d8-static-routing-manager
  • d8-system
  • kube-system

Права, которые получит пользователь, будут ограничены следующим списком пространств имён модулей DKP из подсистемы networking (фактический список зависит от списка включённых в кластере модулей):

  • d8-cni-cilium;
  • d8-cni-flannel;
  • d8-cni-simple-bridge;
  • d8-ingress-nginx;
  • d8-istio;
  • d8-metallb;
  • d8-network-gateway;
  • d8-openvpn;
  • d8-static-routing-manager;
  • d8-system;
  • kube-system.

The user will be able to:

  • View, modify, delete, and create standard Kubernetes resources in the module namespace from the networking subsystem.

Пользователю будут доступны следующие права:

  • Просмотр, изменение, удаление и создание стандартных ресурсов Kubernetes в пространстве имён модулей из подсистемы networking.

Example of resources that the user will be able to manage (the list is not exhaustive):

  • Certificate
  • CertificateRequest
  • ConfigMap
  • ControllerRevision
  • CronJob
  • DaemonSet
  • Deployment
  • Event
  • HorizontalPodAutoscaler
  • Ingress
  • Issuer
  • Job
  • Lease
  • LimitRange
  • NetworkPolicy
  • PersistentVolumeClaim
  • Pod
  • PodDisruptionBudget
  • ReplicaSet
  • ReplicationController
  • ResourceQuota
  • Role
  • RoleBinding
  • Secret
  • Service
  • ServiceAccount
  • StatefulSet
  • VerticalPodAutoscaler
  • VolumeSnapshot

Пример ресурсов, которыми сможет управлять пользователь (список не полный):

  • Certificate;
  • CertificateRequest;
  • ConfigMap;
  • ControllerRevision;
  • CronJob;
  • DaemonSet;
  • Deployment;
  • Event;
  • HorizontalPodAutoscaler;
  • Ingress;
  • Issuer;
  • Job;
  • Lease;
  • LimitRange;
  • NetworkPolicy;
  • PersistentVolumeClaim;
  • Pod;
  • PodDisruptionBudget;
  • ReplicaSet;
  • ReplicationController;
  • ResourceQuota;
  • Role;
  • RoleBinding;
  • Secret;
  • Service;
  • ServiceAccount;
  • StatefulSet;
  • VerticalPodAutoscaler;
  • VolumeSnapshot.
  • View, modify, delete, and create the following resources in the modules namespace from the networking subsystem:
  • Просмотр, изменение, удаление и создание ресурсов в пространстве имён модулей из подсистемы networking.

A list of resources that the user will be able to manage:

  • EgressGateway
  • EgressGatewayPolicy
  • FlowSchema
  • IngressClass
  • IngressIstioController
  • IngressNginxController
  • IPRuleSet
  • IstioFederation
  • IstioMulticluster
  • RoutingTable

Список ресурсов, которыми сможет управлять пользователь:

  • EgressGateway;
  • EgressGatewayPolicy;
  • FlowSchema;
  • IngressClass;
  • IngressIstioController;
  • IngressNginxController;
  • IPRuleSet;
  • IstioFederation;
  • IstioMulticluster;
  • RoutingTable.
  • Modify the configuration of modules (view, change, delete, and create moduleConfig resources) from the networking subsystem.
  • Изменение конфигурации модулей (просмотр, изменение, удаление и создание ресурсов moduleConfig) из подсистемы networking.

List of modules that the user will be able to manage:

  • cilium-hubble
  • cni-cilium
  • cni-flannel
  • cni-simple-bridge
  • flow-schema
  • ingress-nginx
  • istio
  • kube-dns
  • kube-proxy
  • metallb
  • network-gateway
  • network-policy-engine
  • node-local-dns
  • openvpn
  • static-routing-manager
  • Execute the following commands with pods and services in the modules namespace from the networking subsystem:
  • kubectl attach
  • kubectl exec
  • kubectl port-forward
  • kubectl proxy

Список модулей, которыми сможет управлять пользователь:

  • cilium-hubble;
  • cni-cilium;
  • cni-flannel;
  • cni-simple-bridge;
  • flow-schema;
  • ingress-nginx;
  • istio;
  • kube-dns;
  • kube-proxy;
  • metallb;
  • network-gateway;
  • network-policy-engine;
  • node-local-dns;
  • openvpn;
  • static-routing-manager.

Example of assigning administrative rights to a user within a namespace

  • Выполнение следующих команд к подам и сервисам в пространстве имён модулей из подсистемы networking:
  • kubectl attach;
  • kubectl exec;
  • kubectl port-forward;
  • kubectl proxy.

The example uses the experimental role-based.

Пример назначения административных прав пользователю в рамках пространства имён

To assign rights to a user manage application resources within a namespace, but without the ability to configure DKP modules, use the role d8:use:role:admin in RoleBinding in the corresponding namespace.

Пример использует экспериментальную ролевую модель.

Example of assigning rights to an application developer (User app-developer) in namespace myapp:

Для назначения прав на управление ресурсами приложений в рамках пространства имён, но без возможности настройки модулей DKP, используйте роль d8:use:role:admin в RoleBinding в соответствующем пространстве имён.

yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: myapp-developer namespace: myapp subjects:

  • kind: User name: app-developer apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: d8:use:role:admin apiGroup: rbac.authorization.k8s.io

Пример назначения прав разработчику приложений (User app-developer) в пространстве имён myapp:

In the myapp namespace, the user will be able to:

  • View, modify, delete, and create Kubernetes resources. For example, the following resources (the list is not exhaustive):
  • Certificate
  • CertificateRequest
  • ConfigMap
  • ControllerRevision
  • CronJob
  • DaemonSet
  • Deployment
  • Event
  • HorizontalPodAutoscaler
  • Ingress
  • Issuer
  • Job
  • Lease
  • LimitRange
  • NetworkPolicy
  • PersistentVolumeClaim
  • Pod
  • PodDisruptionBudget
  • ReplicaSet
  • ReplicationController
  • ResourceQuota
  • Role
  • RoleBinding
  • Secret
  • Service
  • ServiceAccount
  • StatefulSet
  • VerticalPodAutoscaler
  • VolumeSnapshot
  • View, edit, delete, and create the following DKP module resources:
  • DexAuthenticator
  • DexClient
  • PodLogginConfig
  • Execute the following commands for pods and services:
  • kubectl attach
  • kubectl exec
  • kubectl port-forward
  • kubectl proxy

yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: myapp-developer namespace: myapp subjects:

  • kind: User name: app-developer apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: d8:use:role:admin apiGroup: rbac.authorization.k8s.io

An example of ClusterAuthorizationRule

В рамках пространства имён myapp пользователю будут доступны следующие права:

  • Просмотр, изменение, удаление и создание ресурсов Kubernetes. Например, следующих ресурсов (список не полный):
  • Certificate;
  • CertificateRequest;
  • ConfigMap;
  • ControllerRevision;
  • CronJob;
  • DaemonSet;
  • Deployment;
  • Event;
  • HorizontalPodAutoscaler;
  • Ingress;
  • Issuer;
  • Job;
  • Lease;
  • LimitRange;
  • NetworkPolicy;
  • PersistentVolumeClaim;
  • Pod;
  • PodDisruptionBudget;
  • ReplicaSet;
  • ReplicationController;
  • ResourceQuota;
  • Role;
  • RoleBinding;
  • Secret;
  • Service;
  • ServiceAccount;
  • StatefulSet;
  • VerticalPodAutoscaler;
  • VolumeSnapshot.
  • Просмотр, изменение, удаление и создание следующих ресурсов модулей DKP:
  • DexAuthenticator;
  • DexClient;
  • PodLogginConfig.
  • Выполнение следующих команд к подам и сервисам:
  • kubectl attach;
  • kubectl exec;
  • kubectl port-forward;
  • kubectl proxy.

yaml apiVersion: deckhouse.io/v1 kind: ClusterAuthorizationRule metadata: name: test-rule spec: subjects:

  • kind: User name: some@example.com
  • kind: ServiceAccount name: gitlab-runner-deploy namespace: d8-service-accounts
  • kind: Group name: some-group-name accessLevel: PrivilegedUser portForwarding: true This option is only available if the enableMultiTenancy parameter is set. allowAccessToSystemNamespaces: false This option is only available if the enableMultiTenancy parameter is set. namespaceSelector: labelSelector: matchExpressions:
  • key: stage operator: In values:
  • test
  • review matchLabels: team: frontend

Пример ClusterAuthorizationRule

Creating a user

yaml apiVersion: deckhouse.io/v1 kind: ClusterAuthorizationRule metadata: name: test-rule spec: subjects:

  • kind: User name: some@example.com
  • kind: ServiceAccount name: gitlab-runner-deploy namespace: d8-service-accounts
  • kind: Group name: some-group-name accessLevel: PrivilegedUser portForwarding: true Опция доступна только при включенном режиме enableMultiTenancy. allowAccessToSystemNamespaces: false Опция доступна только при включенном режиме enableMultiTenancy. namespaceSelector: labelSelector: matchExpressions:
  • key: stage operator: In values:
  • test
  • review matchLabels: team: frontend

There are two types of users in Kubernetes:

Создание пользователя

  • Service accounts managed by Kubernetes via the API;
  • Regular users managed by some external tool that the cluster administrator configures. There are many authentication mechanisms and, accordingly, many ways to create users. Currently, two authentication methods are supported:
  • Via the user-authn module.
  • Via the certificates.

В Kubernetes есть две категории пользователей:

When issuing the authentication certificate, you need to specify the name (CN=<name>), the required number of groups (O=<group>), and sign it using the root CA of the cluster. It is this mechanism that authenticates you in the cluster when, for example, you use kubectl on a bastion node.

  • ServiceAccount’ы, учёт которых ведёт сам Kubernetes через API.
  • Остальные пользователи, учёт которых ведёт не сам Kubernetes, а некоторый внешний софт, который настраивает администратор кластера, — существует множество механизмов аутентификации и, соответственно, множество способов заводить пользователей. В настоящий момент поддерживаются два способа аутентификации:
  • через модуль user-authn;
  • с помощью сертификатов.

Creating a ServiceAccount for a machine and granting it access

При выпуске сертификата для аутентификации нужно указать в нём имя (CN=<имя>), необходимое количество групп (O=<группа>) и подписать его с помощью корневого CA-кластера. Именно этим механизмом вы аутентифицируетесь в кластере, когда, например, используете kubectl на bastion-узле.

You may need to create a ServiceAccount with access to the Kubernetes API when, for example, an application is deployed using a CI system.

Создание ServiceAccount для сервера и предоставление ему доступа

  1. Create a ServiceAccount, e.g., in the d8-service-accounts namespace:

Создание ServiceAccount с доступом к Kubernetes API может потребоваться, например, при настройке развёртывания приложений через CI-системы.

shell kubectl create -f - «EOF apiVersion: v1 kind: ServiceAccount metadata: name: gitlab-runner-deploy namespace: d8-service-accounts — apiVersion: v1 kind: Secret metadata: name: gitlab-runner-deploy-token namespace: d8-service-accounts annotations: kubernetes.io/service-account.name: gitlab-runner-deploy type: kubernetes.io/service-account-token EOF

  1. Создайте ServiceAccount, например в пространстве имён d8-service-accounts:
  1. Grant it the necessary privileges (using the ClusterAuthorizationRule custom resource):

shell kubectl create -f - «EOF apiVersion: v1 kind: ServiceAccount metadata: name: gitlab-runner-deploy namespace: d8-service-accounts — apiVersion: v1 kind: Secret metadata: name: gitlab-runner-deploy-token namespace: d8-service-accounts annotations: kubernetes.io/service-account.name: gitlab-runner-deploy type: kubernetes.io/service-account-token EOF

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1 kind: ClusterAuthorizationRule metadata: name: gitlab-runner-deploy spec: subjects:

  • kind: ServiceAccount name: gitlab-runner-deploy namespace: d8-service-accounts accessLevel: SuperAdmin This option is only available if the enableMultiTenancy parameter is set. allowAccessToSystemNamespaces: true
    EOF
  1. Дайте необходимые ServiceAccount-права (используя custom resource ClusterAuthorizationRule):

If multitenancy is enabled in the Deckhouse configuration (via the enableMultiTenancy parameter), configure the namespaces the ServiceAccount has access to (via the namespaceSelector parameter).

shell kubectl create -f - «EOF apiVersion: deckhouse.io/v1 kind: ClusterAuthorizationRule metadata: name: gitlab-runner-deploy spec: subjects:

  • kind: ServiceAccount name: gitlab-runner-deploy namespace: d8-service-accounts accessLevel: SuperAdmin Опция доступна только при включенном режиме enableMultiTenancy. allowAccessToSystemNamespaces: true
    EOF
  1. Set the variable values (they will be used later) by running the following commands (insert your own values):

Если в конфигурации Deckhouse включён режим мультитенантности (в параметре enableMultiTenancy), настройте доступные для ServiceAccount пространства имён (в параметре namespaceSelector).

shell export CLUSTER_NAME=my-cluster export USER_NAME=gitlab-runner-deploy.my-cluster export CONTEXT_NAME=${CLUSTER_NAME}-${USER_NAME} export FILE_NAME=kube.config

  1. Определите значения переменных (они будут использоваться далее), выполнив следующие команды (подставьте свои значения):
  1. Generate the cluster section in the kubectl configuration file:

shell export CLUSTER_NAME=my-cluster export USER_NAME=gitlab-runner-deploy.my-cluster export CONTEXT_NAME=${CLUSTER_NAME}-${USER_NAME} export FILE_NAME=kube.config

Use one of the following options to access the cluster API server:

  1. Сгенерируйте секцию cluster в файле конфигурации kubectl:
  • If there is direct access to the API server:
    1. Get a Kubernetes cluster CA certificate:

Используйте один из следующих вариантов доступа к API-серверу кластера:

shell kubectl get cm kube-root-ca.crt -o jsonpath=’{ .data.ca.crt }’ > /tmp/ca.crt

  • Если есть прямой доступ до API-сервера:
    1. Получите сертификат CA-кластера Kubernetes:
  1. Generate the cluster section (the API server’s IP address is used for access):

shell kubectl get cm kube-root-ca.crt -o jsonpath=’{ .data.ca.crt }’ > /tmp/ca.crt

shell kubectl config set-cluster $CLUSTER_NAME –embed-certs=true
–server=https://$(kubectl get ep kubernetes -o json | jq -rc ‘.subsets[0] | “(.addresses[0].ip):(.ports[0].port)”’)
–certificate-authority=/tmp/ca.crt
–kubeconfig=$FILE_NAME

  1. Сгенерируйте секцию cluster (используется IP-адрес API-сервера для доступа):
  • If there is no direct access to the API server, use one of the following options:
  • enable access to the API-server over the Ingress controller (the publishAPI parameter) and specify the addresses from which requests originate (the whitelistSourceRanges parameter);
  • specify addresses from which requests will originate in a separate Ingress controller (the acceptRequestsFrom parameter).

shell kubectl config set-cluster $CLUSTER_NAME –embed-certs=true
–server=https://$(kubectl get ep kubernetes -o json | jq -rc ‘.subsets[0] | “(.addresses[0].ip):(.ports[0].port)”’)
–certificate-authority=/tmp/ca.crt
–kubeconfig=$FILE_NAME

  • If a non-public CA is used:
  • Если прямого доступа до API-сервера нет, используйте один следующих вариантов:
  • включите доступ к API-серверу через Ingress-контроллер (параметр publishAPI) и укажите адреса, с которых будут идти запросы (параметр whitelistSourceRanges);
  • укажите адреса, с которых будут идти запросы, в отдельном Ingress-контроллере (параметр acceptRequestsFrom).
  1. Get the CA certificate from the Secret with the certificate that is used for the api.%s domain:
  • Если используется непубличный CA:

shell kubectl -n d8-user-authn get secrets -o json
$(kubectl -n d8-user-authn get ing kubernetes-api -o jsonpath=”{.spec.tls[0].secretName}”)
| jq -rc ‘.data.”ca.crt” // .data.”tls.crt”’
| base64 -d > /tmp/ca.crt

  1. Получите сертификат CA из секрета с сертификатом, который используется для домена api.%s:
  1. Generate the cluster section (an external domain and a CA for access are used):

shell kubectl -n d8-user-authn get secrets -o json
$(kubectl -n d8-user-authn get ing kubernetes-api -o jsonpath=”{.spec.tls[0].secretName}”)
| jq -rc ‘.data.”ca.crt” // .data.”tls.crt”’
| base64 -d > /tmp/ca.crt

shell kubectl config set-cluster $CLUSTER_NAME –embed-certs=true
–server=https://$(kubectl -n d8-user-authn get ing kubernetes-api -ojson | jq ‘.spec.rules[].host’ -r)
–certificate-authority=/tmp/ca.crt
–kubeconfig=$FILE_NAME

  1. Сгенерируйте секцию cluster (используется внешний домен и CA для доступа):
  • If a public CA is used. Generate the cluster section (an external domain is used for access):

shell kubectl config set-cluster $CLUSTER_NAME –embed-certs=true
–server=https://$(kubectl -n d8-user-authn get ing kubernetes-api -ojson | jq ‘.spec.rules[].host’ -r)
–certificate-authority=/tmp/ca.crt
–kubeconfig=$FILE_NAME

shell kubectl config set-cluster $CLUSTER_NAME
–server=https://$(kubectl -n d8-user-authn get ing kubernetes-api -ojson | jq ‘.spec.rules[].host’ -r)
–kubeconfig=$FILE_NAME

  • Если используется публичный CA. Сгенерируйте секцию cluster (используется внешний домен для доступа):
  1. Generate the user section using the token from the Secret’s ServiceAccount in the kubectl configuration file:

shell kubectl config set-cluster $CLUSTER_NAME
–server=https://$(kubectl -n d8-user-authn get ing kubernetes-api -ojson | jq ‘.spec.rules[].host’ -r)
–kubeconfig=$FILE_NAME

shell kubectl config set-credentials $USER_NAME
–token=$(kubectl -n d8-service-accounts get secret gitlab-runner-deploy-token -o json |jq -r ‘.data[“token”]’ | base64 -d)
–kubeconfig=$FILE_NAME

  1. Сгенерируйте секцию user с токеном из секрета ServiceAccount в файле конфигурации kubectl:
  1. Generate the context in the kubectl configuration file:

shell kubectl config set-credentials $USER_NAME
–token=$(kubectl -n d8-service-accounts get secret gitlab-runner-deploy-token -o json |jq -r ‘.data[“token”]’ | base64 -d)
–kubeconfig=$FILE_NAME

shell kubectl config set-context $CONTEXT_NAME
–cluster=$CLUSTER_NAME –user=$USER_NAME
–kubeconfig=$FILE_NAME

  1. Сгенерируйте контекст в файле конфигурации kubectl:
  1. Set the generated context as the default one in the kubectl configuration file:

shell kubectl config set-context $CONTEXT_NAME
–cluster=$CLUSTER_NAME –user=$USER_NAME
–kubeconfig=$FILE_NAME

shell kubectl config use-context $CONTEXT_NAME –kubeconfig=$FILE_NAME

  1. Установите сгенерированный контекст как используемый по умолчанию в файле конфигурации kubectl:

How to create a user using a client certificate

shell kubectl config use-context $CONTEXT_NAME –kubeconfig=$FILE_NAME

Creating a user

Создание пользователя с помощью клиентского сертификата

  • Get the cluster’s root certificate (ca.crt and ca.key).
  • Generate the user key:

Создание пользователя

shell openssl genrsa -out myuser.key 2048

  • Получите корневой сертификат кластера (ca.crt и ca.key).
  • Сгенерируйте ключ пользователя:
  • Create a CSR file and specify in it the username (myuser) and groups to which this user belongs (mygroup1 & mygroup2):

shell openssl genrsa -out myuser.key 2048

shell openssl req -new -key myuser.key -out myuser.csr -subj “/CN=myuser/O=mygroup1/O=mygroup2”

  • Создайте CSR, где укажите, что требуется пользователь myuser, который состоит в группах mygroup1 и mygroup2:
  • Sign the CSR using the cluster root certificate:

shell openssl req -new -key myuser.key -out myuser.csr -subj “/CN=myuser/O=mygroup1/O=mygroup2”

shell openssl x509 -req -in myuser.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out myuser.crt -days 10

  • Подпишите CSR корневым сертификатом кластера:
  • Now you can use the certificate issued in the config file:

shell openssl x509 -req -in myuser.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out myuser.crt -days 10

shell cat « EOF apiVersion: v1 clusters:

  • cluster: certificate-authority-data: $(cat ca.crt | base64 -w0) server: https://:6443 name: kubernetes contexts:
  • context: cluster: kubernetes user: myuser name: myuser@kubernetes current-context: myuser@kubernetes kind: Config preferences: {} users:
  • name: myuser user: client-certificate-data: $(cat myuser.crt | base64 -w0) client-key-data: $(cat myuser.key | base64 -w0) EOF
  • Теперь полученный сертификат можно указывать в конфиг-файле:

Granting access to the created user

shell cat « EOF apiVersion: v1 clusters:

  • cluster: certificate-authority-data: $(cat ca.crt | base64 -w0) server: https://<хост кластера="">:6443 name: kubernetes contexts:
  • context: cluster: kubernetes user: myuser name: myuser@kubernetes current-context: myuser@kubernetes kind: Config preferences: {} users:
  • name: myuser user: client-certificate-data: $(cat myuser.crt | base64 -w0) client-key-data: $(cat myuser.key | base64 -w0) EOF

To grant access to the created user, create a `ClusterAuthorizationRule’.

Предоставление доступа созданному пользователю

Example of a ClusterAuthorizationRule:

Для предоставления доступа созданному пользователю создайте ClusterAuthorizationRule.

yaml apiVersion: deckhouse.io/v1 kind: ClusterAuthorizationRule metadata: name: myuser spec: subjects:

  • kind: User name: myuser accessLevel: PrivilegedUser portForwarding: true

Пример ClusterAuthorizationRule:

Configuring kube-apiserver for multi-tenancy mode

yaml apiVersion: deckhouse.io/v1 kind: ClusterAuthorizationRule metadata: name: myuser spec: subjects:

  • kind: User name: myuser accessLevel: PrivilegedUser portForwarding: true

The multi-tenancy mode, which allows you to restrict access to namespaces, is enabled by the enableMultiTenancy module’s parameter.

Настройка kube-apiserver для работы в режиме multi-tenancy

Working in multi-tenancy mode requires enabling the Webhook authorization plugin and configuring a kube-apiserver. All actions necessary for the multi-tenancy mode are performed automatically by the control-plane-manager module; no additional steps are required.

Режим multi-tenancy, позволяющий ограничивать доступ к пространству имён, включается параметром enableMultiTenancy модуля.

Changes to the kube-apiserver manifest that will occur after enabling multi-tenancy mode:

Работа в режиме multi-tenancy требует включения плагина авторизации Webhook и выполнения настройки kube-apiserver. Все необходимые для работы режима multi-tenancy действия выполняются автоматически модулем control-plane-manager, никаких ручных действий не требуется.

  • The --authorization-mode argument will be modified: the Webhook method will be added in front of the RBAC method (e.g., --authorization-mode=Node,Webhook,RBAC);
  • The --authorization-webhook-config-file=/etc/kubernetes/authorization-webhook-config.yaml will be added;
  • The volumeMounts parameter will be added:

Изменения манифеста kube-apiserver, которые произойдут после включения режима multi-tenancy:

yaml

  • name: authorization-webhook-config mountPath: /etc/kubernetes/authorization-webhook-config.yaml readOnly: true
  • исправление аргумента --authorization-mode. Перед методом RBAC добавится метод Webhook (например, --authorization-mode=Node,Webhook,RBAC);
  • добавление аргумента --authorization-webhook-config-file=/etc/kubernetes/authorization-webhook-config.yaml;
  • добавление volumeMounts:
  • The volumes parameter will be added:

yaml

  • name: authorization-webhook-config mountPath: /etc/kubernetes/authorization-webhook-config.yaml readOnly: true

yaml

  • name: authorization-webhook-config hostPath: path: /etc/kubernetes/authorization-webhook-config.yaml type: FileOrCreate
  • добавление volumes:

How do I check that a user has access?

yaml

  • name: authorization-webhook-config hostPath: path: /etc/kubernetes/authorization-webhook-config.yaml type: FileOrCreate

Execute the command below with the following parameters:

Как проверить, что у пользователя есть доступ?

  • resourceAttributes (the same as in RBAC) - target resources;
  • user - the name of the user;
  • groups - user groups;

Необходимо выполнить следующую команду, в которой будут указаны:

You can use Dex logs to find out groups and a username if this module is used together with the user-authn module (kubectl -n d8-user-authn logs -l app=dex); logs available only if the user is authorized).

  • resourceAttributes (как в RBAC) — к чему мы проверяем доступ;
  • user — имя пользователя;
  • groups — группы пользователя.

shell cat «EOF | 2>&1 kubectl create –raw /apis/authorization.k8s.io/v1/subjectaccessreviews -f - | jq .status { “apiVersion”: “authorization.k8s.io/v1”, “kind”: “SubjectAccessReview”, “spec”: { “resourceAttributes”: { “namespace”: “”, “verb”: “watch”, “version”: “v1”, “resource”: “pods” }, “user”: “system:kube-controller-manager”, “groups”: [ “Admins” ] } } EOF

При совместном использовании с модулем user-authn группы и имя пользователя можно посмотреть в логах Dex — kubectl -n d8-user-authn logs -l app=dex (видны только при авторизации).

You will see if access is allowed and what role is used:

shell cat «EOF | 2>&1 kubectl create –raw /apis/authorization.k8s.io/v1/subjectaccessreviews -f - | jq .status { “apiVersion”: “authorization.k8s.io/v1”, “kind”: “SubjectAccessReview”, “spec”: { “resourceAttributes”: { “namespace”: “”, “verb”: “watch”, “version”: “v1”, “resource”: “pods” }, “user”: “system:kube-controller-manager”, “groups”: [ “Admins” ] } } EOF

json { “allowed”: true, “reason”: “RBAC: allowed by ClusterRoleBinding "system:kube-controller-manager" of ClusterRole "system:kube-controller-manager" to User "system:kube-controller-manager"” }

В результате увидим, есть ли доступ и на основании какой роли:

If the multitenancy mode is enabled in your cluster, you need to perform another check to be sure that the user has access to the namespace:

json { “allowed”: true, “reason”: “RBAC: allowed by ClusterRoleBinding "system:kube-controller-manager" of ClusterRole "system:kube-controller-manager" to User "system:kube-controller-manager"” }

shell cat «EOF | 2>&1 kubectl –kubeconfig /etc/kubernetes/deckhouse/extra-files/webhook-config.yaml create –raw / -f - | jq .status { “apiVersion”: “authorization.k8s.io/v1”, “kind”: “SubjectAccessReview”, “spec”: { “resourceAttributes”: { “namespace”: “”, “verb”: “watch”, “version”: “v1”, “resource”: “pods” }, “user”: “system:kube-controller-manager”, “groups”: [ “Admins” ] } } EOF

Если в кластере включён режим multi-tenancy, нужно выполнить ещё одну проверку, чтобы убедиться, что у пользователя есть доступ в пространство имён:

json { “allowed”: false }

shell cat «EOF | 2>&1 kubectl –kubeconfig /etc/kubernetes/deckhouse/extra-files/webhook-config.yaml create –raw / -f - | jq .status { “apiVersion”: “authorization.k8s.io/v1”, “kind”: “SubjectAccessReview”, “spec”: { “resourceAttributes”: { “namespace”: “”, “verb”: “watch”, “version”: “v1”, “resource”: “pods” }, “user”: “system:kube-controller-manager”, “groups”: [ “Admins” ] } } EOF

The allowed: false message means that the webhook doesn’t block access. In case of webhook denying the request, you will see, e.g., the following message:

json { “allowed”: false }

json { “allowed”: false, “denied”: true, “reason”: “making cluster scoped requests for namespaced resources are not allowed” }

Сообщение allowed: false значит, что вебхук не блокирует запрос. В случае блокировки запроса вебхуком вы получите, например, следующее сообщение:

Customizing rights of high-level roles

json { “allowed”: false, “denied”: true, “reason”: “making cluster scoped requests for namespaced resources are not allowed” }

If you want to grant more privileges to a specific high-level role, you only need to create a ClusterRole with the user-authz.deckhouse.io/access-level: <AccessLevel> annotation.

Настройка прав высокоуровневых ролей

An example:

Если требуется добавить прав для определённой высокоуровневой роли, достаточно создать ClusterRole с аннотацией user-authz.deckhouse.io/access-level: <AccessLevel>.

yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: user-authz.deckhouse.io/access-level: Editor name: user-editor rules:

  • apiGroups:
  • kuma.io resources:
  • trafficroutes
  • trafficroutes/finalizers verbs:
  • get
  • list
  • watch
  • create
  • update
  • patch
  • delete
  • apiGroups:
  • flagger.app resources:
  • canaries
  • canaries/status
  • metrictemplates
  • metrictemplates/status
  • alertproviders
  • alertproviders/status verbs:
  • get
  • list
  • watch
  • create
  • update
  • patch
  • delete

Пример:

 

yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: user-authz.deckhouse.io/access-level: Editor name: user-editor rules:

  • apiGroups:
  • kuma.io resources:
  • trafficroutes
  • trafficroutes/finalizers verbs:
  • get
  • list
  • watch
  • create
  • update
  • patch
  • delete
  • apiGroups:
  • flagger.app resources:
  • canaries
  • canaries/status
  • metrictemplates
  • metrictemplates/status
  • alertproviders
  • alertproviders/status verbs:
  • get
  • list
  • watch
  • create
  • update
  • patch
  • delete