Skip to content

How to Delegate?


This section helps you implement ISO 27001, specifically:

  • A.9.4.1 Information Access Restriction

Now that you are almost ready to go live, you will certainly want to delegate some permissions to other team members or IT systems in your organization. This page shows you how to do that.

Authentication vs. Access Control

Authentication is the act of proving your identity. Compliant Kubernetes is usually configured to use your organization's Identity Provider (IdP). Examples of supported IdPs include Google, Microsoft Entra ID, and Jump Cloud. The email and group provided by your IdP are used for access control in various components.

Next sections will explain how to handle access control in each user-facing Compliant Kubernetes component.

Container registry (Harbor)

Compliant Kubernetes uses Harbor as container registry. For access control, Harbor defines the concepts of:

  • user and group -- for human access;
  • robot account -- for IT system access.

You don't need to create Harbor users or groups. Compliant Kubernetes configures Harbor in "OIDC authentication mode", which means that Harbor will automatically onboard users logging in via your IdP and will automatically get the group from your IdP. In contrast, you need to create robot accounts, as these only exist within Harbor.

Your administrator will have configured one of your IdP groups as the "Harbor system administrator" group. Please read the upstream documentation linked below to learn how a Harbor admin can:


You can either add users or groups to a project with various roles. To simplify access control, consider only using groups and assigning users to groups from your IdP.

Kubernetes API

Kubernetes uses the following concepts for access control:

For delegating permissions to ServiceAccounts, follow the example on the CI/CD page.

The next section covers delegation to users and groups.


First, make sure you are in the right namespace on the right cluster:

kubectl get nodes
kubectl config view --minify --output 'jsonpath={..namespace}'; echo

You can only delegate as much permission as you have (see Privilege escalation prevention). Therefore, check what permissions you have:

kubectl auth can-i --list

Create a Role

Next, create a Role capturing the set of permissions you want to delegate. If unsure, start from the example Role that the user demo's CI/CD pipeline needs.

kubectl apply -f ci-cd-role.yaml

Delegate to a Group

Prefer delegating to a group, so that access control is centralized in your IdP.

ROLE=my-role     # Role created above
GROUP=my-group   # As set in your IdP

kubectl create rolebinding $ROLE --role $ROLE --group=$GROUP --dry-run=client -o yaml > my-role-binding.yaml
# review my-role-binding.yaml
kubectl apply -f my-role-binding.yaml

Add a Kubernetes admin

In Compliant Kubernetes, Application Developers who are Kubernetes admins have the ability to add more Kubernetes admins themselves.


  1. Edit the ClusterRoleBinding extra-user-view and add the desired users or groups under subjects. If unsure, look at an example subject from the official Kubernetes documentation.

    kubectl edit clusterrolebinding extra-user-view
  2. In each of your user namespaces that you want the users or groups to be admin in, edit the RoleBinding extra-workload-admins and add the desired users or groups under subjects. If you have a root HNC namespace and you want the users or groups to be admin in all of your namespaces, you only need to edit the RoleBinding in this root namespace and it will propagate.

    kubectl edit rolebinding extra-workload-admins -n user-namespace

Application Metrics (Grafana)

Your administrator will have mapped your IdP groups to the Grafana viewer, editor and admin roles. Please read the upstream documentation to learn more.

Application Logs (OpenSearch Dashboards)

For improved security and due to technical limitations, OpenSearch permissions can only be configured by the Platform Administrator. Contact them to change access control to application logs.