Skip to content

How to Delegate?

Note

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. Welkin 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 Welkin component.

Container registry (Harbor)

Welkin 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. Welkin 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:

Note

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.

Pre-verification

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 Welkin, Application Developers who are Kubernetes admins have the ability to add more Kubernetes admins themselves.

Steps

  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. Access can be limited to specific email domains. 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.