To grant permissions in Deckhouse Kubernetes Platform (DKP), you need to define a subjects block in custom resources.

For users, it should be specified in the following format:

subjects:
- kind: User
  name: <user email>

If you are using the user-authn module and static users, make sure to specify the user’s email in subjects, not the name of the User resource.

Alternatively, you can grant permissions by group:

subjects:
- kind: Group
  name: <name of the group the user belongs to>

For a service account, the subjects block should be specified as follows:

subjects:
- kind: ServiceAccount
  name: <service account name>
  namespace: <namespace where the service account is created>

Granting permissions using AuthorizationRule and ClusterAuthorizationRule (current role model)

When using the current role model in DKP, you can grant permissions to users via the AuthorizationRule and ClusterAuthorizationRule resources.

Granting permissions to a user within a single namespace

To grant a user permissions within a single namespace, use the AuthorizationRule resource. It is applied within a single namespace.

Example:

apiVersion: deckhouse.io/v1
kind: AuthorizationRule
metadata:
  name: dev-access
  namespace: dev-namespace
spec:
  subjects:
  - kind: User
    name: dev-user@example.com
  accessLevel: Admin
  portForwarding: true

Granting permissions to a user in all namespaces

To grant a user permissions across all namespaces, including system ones (for example, to assign administrator permissions), use the ClusterAuthorizationRule resource. It is applied cluster-wide.

If needed, you can restrict the scope of permissions granted via ClusterAuthorizationRule to one or several namespaces. To do this, you can set the corresponding restrictions in the manifest. However, if possible, it is recommended that you use the AuthorizationRule resource for this purpose.

Example:

apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
  name: admin-access
spec:
  subjects:
  - kind: User
    name: dev-user@example.com
  # Available only with enableMultiTenancy mode turned on
  # in the user-authz module (Enterprise Edition).
  namespaceSelector:
    labelSelector:
      matchLabels:
        env: review
  accessLevel: SuperAdmin
  portForwarding: true

Granting permissions using ClusterRoleBinding and RoleBinding (experimental role model)

When using the experimental role model in DKP, you can grant permissions to users via the ClusterRoleBinding and RoleBinding resources.

Assigning cluster administrator permissions (experimental role model)

To assign cluster administrator permissions, use the manage role d8:manage:all:manager in a ClusterRoleBinding resource.

Example of assigning cluster administrator permissions to the user joe:

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

Permissions the user will obtain

The user’s permissions will be limited to namespaces starting with d8- or kube-.

The user will have the following permissions:

  • View, modify, delete, and create Kubernetes resources and DKP module resources.
  • Modify module configurations (view, edit, delete, and create ModuleConfig resources).
  • Run the following commands on pods and services:
    • kubectl attach
    • kubectl exec
    • kubectl port-forward
    • kubectl proxy

Assigning networking administrator permissions (experimental role model)

To assign networking administrator permissions for managing the cluster’s networking subsystem, use the manage role d8:manage:networking:manager in a ClusterRoleBinding resource.

Example of assigning networking administrator permissions to the user joe:

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

Permissions the user will obtain

The user’s permissions will be limited to the following DKP module namespaces from the networking subsystem (the actual list depends on the modules enabled 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

The user will have the following permissions:

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

    Example resources the user will be able to manage (not a complete list):

    • 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, create, and delete resources in DKP module namespaces from the networking subsystem.

    Resources the user will be able to manage:

    • EgressGateway
    • EgressGatewayPolicy
    • FlowSchema
    • IngressClass
    • IngressIstioController
    • IngressNginxController
    • IPRuleSet
    • IstioFederation
    • IstioMulticluster
    • RoutingTable
  • Modify module configurations (view, modify, create, and delete ModuleConfig resources) in the networking subsystem.

    Modules 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
  • Run the following commands on Pods and Services in the module namespaces within the networking subsystem:

    • kubectl attach
    • kubectl exec
    • kubectl port-forward
    • kubectl proxy

Granting administrator permissions to a user within a namespace (experimental role model)

To assign or restrict user permissions to specific namespaces, apply a use role with the corresponding access level in a RoleBinding resource.

For example, to allow a user to manage application resources in a namespace (without giving them access to DKP module configurations), use the d8:use:role:admin role in a RoleBinding resource for the corresponding namespace.

Example of granting application developer app-developer permissions within the myapp namespace:

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

Permissions the user will obtain

The user’s permissions will be limited to the following within the myapp namespace:

  • View, modify, create, and delete Kubernetes resources. Example resources:

    • 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, create, and delete the following DKP module resources:

    • DexAuthenticator
    • DexClient
    • PodLoggingConfig
  • Run the following commands on Pods and Services:

    • kubectl attach
    • kubectl exec
    • kubectl port-forward
    • kubectl proxy