Compare languages | Модуль user-authz: примеры конфигурации

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

Example of assigning rights to a cluster administrator

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

The example uses the experimental role-based.

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

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

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

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

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

  • kind: User name: jane.doe@example.com 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-jane subjects:

  • kind: User name: jane.doe@example.com apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: d8:manage:all:manager apiGroup: rbac.authorization.k8s.io

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

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

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

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

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

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

Example of assigning rights to a network administrator

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

The example uses the experimental role-based.

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

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

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

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

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

  • kind: User name: jane.doe@example.com 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-jane subjects:

  • kind: User name: jane.doe@example.com apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: d8:manage:networking:manager apiGroup: rbac.authorization.k8s.io

Права, которые получит пользователь, будут ограничены следующим списком пространств имён модулей 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 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

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

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

The user will be able to:

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

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

  • 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.

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
  • Просмотр, изменение, удаление и создание ресурсов в пространстве имён модулей из подсистемы networking.
  • View, modify, delete, and create the following resources in the modules namespace from the networking subsystem:

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

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

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

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

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

  • 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.

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

Example of assigning administrative rights to a user within a namespace

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

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.

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

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

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

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

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

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

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

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

В рамках пространства имён 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.

An example of ClusterAuthorizationRule

Пример ClusterAuthorizationRule

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

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

Creating a user

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

There are two types of users in Kubernetes:

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

  • Service accounts managed by Kubernetes via the API;
  • Regular users and groups 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. The module supports the following external providers and authentication protocols: GitHub, GitLab, Atlassian Crowd, BitBucket Cloud, Crowd, LDAP, OIDC. More details — in the documentation of the user-authn module.
  • Via the certificates.
  • ServiceAccount’ы, учёт которых ведёт сам Kubernetes через API.
  • Остальные пользователи и группы, учёт которых ведёт не сам Kubernetes, а некоторый внешний софт, который настраивает администратор кластера, — существует множество механизмов аутентификации и, соответственно, множество способов заводить пользователей. В настоящий момент поддерживаются способы аутентификации:
  • Через модуль user-authn. Модуль поддерживает следующие внешние провайдеры и протоколы аутентификации: GitHub, GitLab, Atlassian Crowd, BitBucket Cloud, Crowd, LDAP, OIDC. Подробнее — в документации модуля user-authn.
  • С помощью сертификатов.

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.

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

Creating a ServiceAccount for a machine and granting it access

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

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 с доступом к Kubernetes API может потребоваться, например, при настройке развёртывания приложений через CI-системы.

  1. Create a ServiceAccount, e.g., in the d8-service-accounts namespace:
  1. Создайте ServiceAccount, например в пространстве имён d8-service-accounts:

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: 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. Grant it the necessary privileges (using the ClusterAuthorizationRule custom resource):
  1. Дайте необходимые ServiceAccount-права (используя custom resource ClusterAuthorizationRule):

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

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

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

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

  1. Set the variable values (they will be used later) by running the following commands (insert your own values):
  1. Определите значения переменных (они будут использоваться далее), выполнив следующие команды (подставьте свои значения):

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

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. Generate the cluster section in the kubectl configuration file:
  1. Сгенерируйте секцию cluster в файле конфигурации kubectl:

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

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

  • If there is direct access to the API server:
    1. Get a Kubernetes cluster CA certificate:
  • Если есть прямой доступ до API-сервера:
    1. Получите сертификат CA-кластера Kubernetes:

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

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

  1. Generate the cluster section (the API server’s IP address is used for access):
  1. Сгенерируйте секцию cluster (используется IP-адрес API-сервера для доступа):

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

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

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 -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. Generate the cluster section (an external domain and a CA for access are used):
  1. Сгенерируйте секцию cluster (используется внешний домен и CA для доступа):

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 –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

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

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-cluster $CLUSTER_NAME
–server=https://$(kubectl -n d8-user-authn get ing kubernetes-api -ojson | jq ‘.spec.rules[].host’ -r)
–kubeconfig=$FILE_NAME

  1. Generate the user section using the token from the Secret’s ServiceAccount in the kubectl configuration file:
  1. Сгенерируйте секцию user с токеном из секрета ServiceAccount в файле конфигурации kubectl:

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-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. Generate the context in the kubectl configuration file:
  1. Сгенерируйте контекст в файле конфигурации kubectl:

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

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

  1. Set the generated context as the default one in the kubectl configuration file:
  1. Установите сгенерированный контекст как используемый по умолчанию в файле конфигурации kubectl:

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

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

How to create a user using a client certificate

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

This method is recommended for system needs (authentication of kubelets, control plane components, etc.). If you need to create a “normal” user (e.g. with console access, kubectl, etc.), use kubeconfig generation.

Этот способ рекомендуется использовать для системных нужд (аутентификация kubelet’ов, компонентов control plane и пр.). Если нужно создать «обычного» пользователя (например, с доступом через консоль, kubectl и т.д.), используйте генерацию kubeconfig.

To create a user with a client certificate, you can use either OpenSSL or the Kubernetes API (via the CertificateSigningRequest object).

При создании пользователя с помощью клиентского сертификата можно использовать OpenSSL или Kubernetes API (объект CertificateSigningRequest).

Certificates issued by any of these methods cannot be revoked. If a certificate is compromised, you will need to remove all permissions for that user (this can be difficult if the user is added to any groups: you will also need to remove all relevant groups).

Сертификаты, выпущенные любым из этих способов, отозвать нельзя. В случае компрометации сертификата потребуется убрать все права этого пользователя (это может быть сложно, если пользователь добавлен в какие-нибудь группы: придётся также удалять все соответствующие группы).

Creating a user using a certificate issued via OpenSSL

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

Consider security risks when using this method.

При использовании этого способа учитывайте риски безопасности.

The ca.crt and ca.key must not leave the master node: sign the CSR only on the master node.

ca.crt и ca.keyне должны покидать master-узел: подписывайте CSR только на нём.

Signing CSRs outside the master node risks compromising the cluster root certificate.

При подписании CSR вне master-узла есть риск компрометации корневого сертификата кластера.

The features of this method are:

Особенности этого способа:

  • The client certificate must be signed on the master node to prevent the cluster certificate from being compromised.
  • Access to the cluster CA key (ca.key) is required. Only the cluster administrator can sign certificates.
  • Клиентский сертификат должен подписываться на master-узле, чтобы не допустить компрометации кластерного сертификата.
  • Необходим доступ к CA-ключу кластера (ca.key). Подписывать сертификаты может только администратор кластера.

To create a user using a client certificate issued through OpenSSL, follow these steps:

Чтобы создать пользователя с помощью клиентского сертификата, выпущенного через OpenSSL, выполните следующие шаги:

  1. Get the cluster’s root certificate (ca.crt and ca.key).
  2. Generate the user key:
  1. Получите корневой сертификат кластера (ca.crt и ca.key).
  2. Сгенерируйте ключ пользователя:

shell openssl genrsa -out myuser.key 2048

shell openssl genrsa -out myuser.key 2048

  1. Create a CSR file and specify the username in it (myuser) and groups to which this user belongs (mygroup1 and mygroup2):
  1. Создайте CSR, указав в нём имя пользователя myuser, который состоит в группах mygroup1 и mygroup2:

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

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

  1. Upload the CSR created in the previous step (myuser.csr in this example) to the master node and sign it with the cluster root certificate. Example command to sign the CSR on the master node (make sure that the paths to myuser.csr, ca.crt and ca.key are correct for your case):
  1. Загрузите созданный на предыдущем шаге CSR (в этом примере — myuser.csr) на master-узел и подпишите его корневым сертификатом кластера. Пример команды для подписания CSR на мастер-узле (убедитесь, что в команде указаны верные для вашего случая пути к myuser.csr, ca.crt и ca.key):

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

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

Now the certificate can be specified in the config file:

Полученный сертификат можно указывать в конфигурационном файле:

shell cat « EOF apiVersion: v1 clusters:

  • cluster: certificate-authority-data: $(cat /etc/kubernetes/pki/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

shell cat « EOF apiVersion: v1 clusters:

  • cluster: certificate-authority-data: $(cat /etc/kubernetes/pki/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

Creating a user by issuing a certificate via the Kubernetes API

Создание пользователя с помощью сертификата, выпущенного через Kubernetes API

This is a more secure method because a special kubernetes API is used to sign the certificate.

Это более безопасный способ, т.к. для подписания сертификата используется специальный API kubernetes.

The features of this method are:

Особенности этого способа:

  • API-based certificate signing: CSRs are processed through the Kubernetes API without requiring access to the CA’s private key (ca.key).
  • Not only the cluster administrator can issue client certificates. The right to create CSRs and sign them can be assigned to a specific user.
  • Подписание сертификата через Kubernetes API: CSR отправляется на подпись через API и прямой доступ к ca.key не требуется.
  • Выпускать клиентские сертификаты может не только администратор кластера. Право на создание CSR и их подписание можно назначить определенному пользователю.

To create a user using a client certificate issued through the Kubernetes API, follow these steps:

Чтобы создать пользователя с помощью клиентского сертификата, выпущенного через Kubernetes API, выполните следующие шаги:

  1. Generate the user key:
  1. Сгенерируйте ключ пользователя:

shell openssl genrsa -out myuser.key 2048

shell openssl genrsa -out myuser.key 2048

  1. Create a CSR file and specify in it the username (myuser) and groups to which this user belongs (mygroup1 and mygroup2):
  1. Создайте CSR, указав в нём имя пользователя myuser, который состоит в группах mygroup1 и mygroup2:

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

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

  1. Create a manifest for the CertificateSigningRequest object and save it to a file (csr.yaml in this example):
  1. Создайте манифест объекта CertificateSigningRequest и сохраните его в файл (в этом примере — csr.yaml):

In the request field, specify the contents of the CSR created in the previous step, encoded in Base64.

В поле request укажите содержимое CSR, созданного на предыдущем этапе, закодированное в Base64.

yaml apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: demo-client-cert spec: request: # CSR in Base64 signerName: “kubernetes.io/kube-apiserver-client” expirationSeconds: 7200 usages:

  • “digital signature”
  • “client auth”
  1. Apply the manifest to create a certificate signing request: shell kubectl apply -f csr.yaml

yaml apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: demo-client-cert spec: request: # CSR в Base64 signerName: “kubernetes.io/kube-apiserver-client” expirationSeconds: 7200 usages:

  • “digital signature”
  • “client auth”
  1. Примените манифест, чтобы создать запрос на подпись сертификата: shell kubectl apply -f csr.yaml
  1. Check that the certificate has been approved and issued:
  1. Убедитесь, что сертификат подтвержден:

shell kubectl get csr demo-client-cert

shell kubectl get csr demo-client-cert

If the certificate is issued, it will have the value Approved,Issued in the CONDITION column. Example output:

Если сертификат подтвержден, в колонке CONDITION у него будет значение Approved,Issued. Пример вывода:

shell NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION demo-client-cert 8m24s kubernetes.io/kube-apiserver-client kubernetes-admin 120m Approved,Issued

shell NAME AGE SIGNERNAME REQUESTOR REQUESTEDDURATION CONDITION demo-client-cert 8m24s kubernetes.io/kube-apiserver-client kubernetes-admin 120m Approved,Issued

If the certificate is not automatically verified, verify it:

Если сертификат не подтвердился автоматически, подтвердите его:

shell kubectl certificate approve demo-client-cert

shell kubectl certificate approve demo-client-cert

Then, confirm that the certificate has been successfully approved.

После этого убедитесь, что сертификат подтвержден.

  1. Extract the encoded certificate from the CSR named demo-client-cert, decode it from Base64 and save it to the file (myuser.crt in this example) created in step 2:
  1. Извлеките закодированный сертификат из CSR с именем demo-client-cert, декодируйте его из Base64 и сохраните в файл (в этом примере — myuser.crt), созданный на шаге 2:

shell kubectl get csr demo-client-cert -ojsonpath=”{.status.certificate}” | base64 -d > myuser.crt

shell kubectl get csr demo-client-cert -ojsonpath=”{.status.certificate}” | base64 -d > myuser.crt

Now the certificate can be specified in the config file:

Полученный сертификат необходимо указать в конфигурационном файле:

shell cat « EOF apiVersion: v1 clusters:

  • cluster: certificate-authority-data: $(cat /etc/kubernetes/pki/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

shell cat « EOF apiVersion: v1 clusters:

  • cluster: certificate-authority-data: $(cat /etc/kubernetes/pki/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

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

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

Для предоставления доступа созданному пользователю создайте 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

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

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

Configuring kube-apiserver for multi-tenancy mode

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

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

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

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

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

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

  • 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:
  • исправление аргумента --authorization-mode. Перед методом RBAC добавится метод Webhook (например, --authorization-mode=Node,Webhook,RBAC);
  • добавление аргумента --authorization-webhook-config-file=/etc/kubernetes/authorization-webhook-config.yaml;
  • добавление volumeMounts:

yaml

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

yaml

  • name: authorization-webhook-config mountPath: /etc/kubernetes/authorization-webhook-config.yaml readOnly: true
  • The volumes parameter will be added:
  • добавление volumes:

yaml

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

yaml

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

How do I check that a user has access?

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

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;
  • resourceAttributes (как в RBAC) — к чему мы проверяем доступ;
  • 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).

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

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

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

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

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

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

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:

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

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

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

json { “allowed”: false }

json { “allowed”: false }

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:

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

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

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

Customizing rights of high-level roles

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

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.

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

An example:

Пример:

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