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 tooidc:<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 tooidc:<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
.
Runkubectl get workspaces
to obtain a list of all existing workspaces. Theworkspace_ID
is listed under theNAME
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.
Granting user admin
privileges on /dkp/*
grants admin
privileges to all sub-resources, even if bindings exist for sub-resources with less privileges.
Dashboard | Role | Path | access |
---|---|---|---|
* | cluster-admin | * | read, write, delete |
kommander | dkp-view | /dkp/* | read |
kommander | dkp-edit | /dkp/* | read, write |
kommander | dkp-admin | /dkp/* | read, write, delete |
kommander-dashboard | dkp-kommander-view | /dkp/kommander/dashboard/* | read |
kommander-dashboard | dkp-kommander-edit | /dkp/kommander/dashboard/* | read, write |
kommander-dashboard | dkp-kommander-admin | /dkp/kommander/dashboard/* | read, write, delete |
alertmanager | dkp-kube-prometheus-stack-alertmanager-view | /dkp/alertmanager/* | read |
alertmanager | dkp-kube-prometheus-stack-alertmanager-edit | /dkp/alertmanager/* | read, write |
alertmanager | dkp-kube-prometheus-stack-alertmanager-admin | /dkp/alertmanager/* | read, write, delete |
centralized-grafana | dkp-centralized-grafana-grafana-view | /dkp/kommander/monitoring/grafana/* | read |
centralized-grafana | dkp-centralized-grafana-grafana-edit | /dkp/kommander/monitoring/grafana/* | read, write |
centralized-grafana | dkp-centralized-grafana-grafana-admin | /dkp/kommander/monitoring/grafana/* | read, write, delete |
centralized-kubecost | dkp-centralized-kubecost-view | /dkp/kommander/kubecost/* | read |
centralized-kubecost | dkp-centralized-kubecost-edit | /dkp/kommander/kubecost/* | read, write |
centralized-kubecost | dkp-centralized-kubecost-admin | /dkp/kommander/kubecost/* | read, write, delete |
grafana | dkp-kube-prometheus-stack-grafana-view | /dkp/grafana/* | read |
grafana | dkp-kube-prometheus-stack-grafana-edit | /dkp/grafana/* | read, write |
grafana | dkp-kube-prometheus-stack-grafana-admin | /dkp/grafana/* | read, write, delete |
grafana-logging | dkp-grafana-logging-view | /dkp/logging/grafana/* | read |
grafana-logging | dkp-grafana-logging-edit | /dkp/logging/grafana/* | read, write |
grafana-logging | dkp-grafana-logging-admin | /dkp/logging/grafana/* | read, write, delete |
karma | dkp-karma-view | /dkp/kommander/monitoring/karma/* | read |
karma | dkp-karma-edit | /dkp/kommander/monitoring/karma/* | read, write |
karma | dkp-karma-admin | /dkp/kommander/monitoring/karma/* | read, write, delete |
kubernetes-dashboard | dkp-kubernetes-dashboard-view | /dkp/kubernetes/* | read |
kubernetes-dashboard | dkp-kubernetes-dashboard-edit | /dkp/kubernetes/* | read, write |
kubernetes-dashboard | dkp-kubernetes-dashboard-admin | /dkp/kubernetes/* | read, write, delete |
prometheus | dkp-kube-prometheus-stack-prometheus-view | /dkp/prometheus/* | read |
prometheus | dkp-kube-prometheus-stack-prometheus-edit | /dkp/prometheus/* | read, write |
prometheus | dkp-kube-prometheus-stack-prometheus-admin | /dkp/prometheus/* | read, write, edit |
traefik | dkp-traefik-view | /dkp/traefik/* | read |
traefik | dkp-traefik-edit | /dkp/traefik/* | read, edit |
traefik | dkp-traefik-admin | /dkp/traefik/* | read, edit, delete |
thanos | dkp-thanos-query-view | /dkp/kommander/monitoring/query/* | read |
thanos | dkp-thanos-query-edit | /dkp/kommander/monitoring/query/* | read, write |
thanos | dkp-thanos-query-admin | /dkp/kommander/monitoring/query/* | read, write, delete |
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 tooidc:<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 tooidc:<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
.
Runkubectl get workspaces
to obtain a list of all existing workspaces. Theworkspace_ID
is listed under theNAME
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.
Select Access Control in the Administration section of the sidebar menu.
Select the Cluster Roles tab, and then select the + Create Role button.
Give the role a descriptive name and ensure that Cluster Role is selected as the type.
For example, to configure a read-only role, select + Add Rule:
select All Resource Types in the Resources input
select the get, list, and watch verbs with their respective checkboxes
Select Save.
Now you can assign your newly-created role to the developers group.
Accessing the Kubernetes Dashboard
Access to the Kubernetes dashboard at the /dkp/kubernetes/
URL requires a DKP role that grants access to that URL path. As documented above, DKP provides several pre-defined ClusterRoles
(dkp-kubernetes-dashboard-view, dkp-kubernetes-dashboard-edit
, and dkp-kubernetes-dashboard-admin
) that can be used to provide this access.
For example, to provide all authenticated users in the oidc:developers
group access to Kubernetes dashboard, add the following ClusterRoleBinding
:
cat << EOF | kubectl apply -f -
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: developer-dashboard-access
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: dkp-kubernetes-dashboard-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: oidc:developers
EOF
However, access to the underlying Kubernetes resources exposed by the dashboard are protected by the cluster RBAC policy.
Further Reading
This page has provided some basic examples of operations which explain 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.