Granting Access to Kubernetes and Kommander Resources

Grant access to Kommander and Kubernetes resources using RBAC

Granting Access to External Users

Users and groups from an external identity provider initially have no access to kubernetes resources. Privileges must be granted explicitly by interacting with the RBAC API. This section provides some basic examples for general usage. More information about the RBAC API can be found in the Kubernetes documentation.

The Basics

Kubernetes does not provide an identity database for standard users. Users and group membership must be provided by a trusted identity provider. In Kubernetes, RBAC policies are additive, which means that a subject (user, group, or service account) is denied access to a resource unless explicitly granted access by a cluster administrator. You can grant access by binding a subject to a role, which grants some level of access to one or more resources. Kubernetes ships with some default roles, which aid in creating broad access control policies.

For example, if you want to make mary@example.com a cluster administrator, bind her username to the cluster-admin default role as follows:

cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: mary-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: mary@example.com
EOF

If you have configured an Identity Provider for a specific workspace, configure the subjects.name field to <workspace_ID>:<user_email>. For example, tenant-z:jane.doe@example.com.

This user now has the highest level of access which can be achieved. Use the cluster-admin role and system:masters group sparingly.

Restricting a User to Namespace

A more common example would be to grant a user access to a specific namespace, by creating a RoleBinding (RoleBindings are namespaced scoped). For example, to make the user bob@example.com a reader of the baz namespace, bind the user to the view role:

cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bob-view
  namespace: baz
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: bob@example.com
EOF

If you have configured an Identity Provider for a specific workspace, configure the subjects.name field to <workspace_ID>:<user_email>. For example, tenant-z:jane.doe@example.com.

The user can now perform non-destructive operations targeting resources in the baz namespace only.

Groups

If your external identity provider supports group claims, you can also bind groups to roles. To make the engineering LDAP group administrators of the production namespace bind the group to the admin role:

cat << EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: engineering-admin
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:engineering
EOF

One important distinction from adding users is that all external groups are prefixed with oidc:, so a group name becomes oidc:devops. This prevents collision with locally defined groups.

The property for the subjects.name varies depending on the context for which you have established an Identity Provider.

• If you have set up an identity provider for All Workspaces:

  • For groups: configure the subjects.name field to oidc:<IdP_user_group>. For example, oidc:engineering.

  • For users: configure the subjects.name field to <user_email>. For example, jane.doe@example.com

• If you have set up an identity provider for a Specific Workspace:

  • For groups: configure the subjects.name field to oidc:<workspace_ID>:<IdP_user_group>. For example, oidc:tenant-z:engineering.

  • For users: configure the subjects.name field to <workspace_ID>:<user_email>. For example, tenant-z:jane.doe@example.com.
    Run kubectl get workspaces to obtain a list of all existing workspaces. The workspace_ID is listed under the NAME column.

DKP UI Authorization

The DKP UI, and other HTTP applications protected by Kommander forward authentication, are also authorized by the Kubernetes RBAC API. In addition to Kubernetes API resources, it is possible to define rules which map to HTTP URIs and HTTP verbs. Kubernetes RBAC calls these nonResourceURLs, Kommander forward authentication uses these rules to grant or deny access to HTTP endpoints.

Default Roles

Roles have been created for granting access to the dashboard and select applications which expose an HTTP server through the ingress controller. The cluster-admin role is actually a system role that defines grants permission to all actions (verbs) on any resource; including non-resource URLs. The default dashboard user is bound to this role.

This section provides a few examples of binding subjects to the default roles defined for the DKP UI endpoints.

Examples

User

To grant the user mary@example.com administrative access to all Kommander resources, bind the user to the dkp-admin role:

cat << EOF | kubectl apply -f -
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dkp-admin-mary
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: dkp-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: mary@example.com
EOF

If you inspect the role, you see what access is now granted:

kubectl describe clusterroles dkp-admin

Name:         dkp-admin
Labels:       app.kubernetes.io/instance=kommander
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/version=v2.0.0
              helm.toolkit.fluxcd.io/name=kommander
              helm.toolkit.fluxcd.io/namespace=kommander
              rbac.authorization.k8s.io/aggregate-to-admin=true
Annotations:  meta.helm.sh/release-name: kommander
              meta.helm.sh/release-namespace: kommander
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
             [/dkp/*]           []              [delete]
             [/dkp]             []              [delete]
             [/dkp/*]           []              [get]
             [/dkp]             []              [get]
             [/dkp/*]           []              [head]
             [/dkp]             []              [head]
             [/dkp/*]           []              [post]
             [/dkp]             []              [post]
             [/dkp/*]           []              [put]
             [/dkp]             []              [put]

The user can now use the HTTP verbs HEAD, GET, DELETE, POST, and PUT when accessing any URL at or under /dkp. Provided the downstream application follows REST conventions, this effectively allows read, edit, and delete privileges.

NOTE: To allow users to access the DKP UI, ensure they have the appropriate dkp-kommander- role in addition to the Kommander roles granted in the DKP UI. For more information, see the Access Control section of the Kommander documentation.

Group

In order to grant view access to the /dkp/* endpoints and edit access to the grafana logging endpoint to group logging-ops, create the following ClusterRoleBindings:

cat << EOF | kubectl apply -f -
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dkp-view-logging-ops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: dkp-view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:logging-ops
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dkp-logging-edit-logging-ops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: dkp-logging-edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: oidc:logging-ops
EOF

Note: external groups must be prefixed by oidc:

The property for the subjects.name varies depending on the context for which you have established an Identity Provider.

• If you have set up an identity provider for All Workspaces:

  • For groups: configure the subjects.name field to oidc:<IdP_user_group>. For example, oidc:engineering.

  • For users: configure the subjects.name field to <user_email>. For example, jane.doe@example.com

• If you have set up an identity provider for a Specific Workspace:

  • For groups: configure the subjects.name field to oidc:<workspace_ID>:<IdP_user_group>. For example, oidc:tenant-z:engineering.

  • For users: configure the subjects.name field to <workspace_ID>:<user_email>. For example, tenant-z:jane.doe@example.com.
    Run kubectl get workspaces to obtain a list of all existing workspaces. The workspace_ID is listed under the NAME column.

Members of logging-ops are now able to view all resources under /dkp and edit all resources under /dkp/logging/grafana.

Custom Roles

In the event that one of the predefined roles from DKP does not include all the permissions you need, you can create a custom role. An example set of steps is listed below, but you choose which actions and permissions you want to grant.

1. Select Access Control in the Administration section of the sidebar menu.

2. Select the Cluster Roles tab, and then select the + Create Role button.

3. Give the role a descriptive name, and ensure that Cluster Role is selected as the type.

4. For example, to configure a read-only role, select + Add Rule:

   1. select All Resource Types in the Resources input

   2. select the get, list, and watch verbs with their respective checkboxes

   3. Select Save.

Now you can assign your newly-created role to the developers group.

Accessing the Kubernetes Dashboard

The Kubernetes dashboard offloads authorization directly to the Kubernetes API server. Once authenticated, all users may access the dashboard at /dkp/kubernetes/ without needing a dkp role. However, access to the underlying kubernetes resources exposed by the dashboard are protected by the cluster RBAC policy.

Further Reading

This page has provides some basic examples of operations which provide the building blocks of creating an access control policy. For more information about creating your own roles and advanced policies, we highly recommend reading the Kubernetes RBAC documentation.

For information on how you can add a user to a cluster as an admin, refer to Onboarding Users onto a DKP Cluster.