RBAC (V2): An Overview

Introduction

RBAC (Role-Based Access Control) is pivotal in any organization and Komodor endeavors to provide the utmost granularity possible with Komodor-native, K8s-native and combined actions and policies.

Instead of granting blanket permissions, RBAC ensures that users only have access to the resources they need—whether at the cluster or namespace level.

Komodor’s RBAC integrates seamlessly with Workspaces, ensuring users can only view and interact with resources within their defined permissions. However, Workspaces do not grant additional access—they simply filter what a user can already see based on RBAC settings.

ChatGPT Image Apr 23, 2025, 04_17_55 PM.png

How RBAC Works in Komodor

RBAC operates on a hierarchical permissions model, ensuring that users can only access what they are explicitly allowed to.

RBAC Components in Komodor:

Component	Description
Roles	Entities that group users and policies. Roles align with organizational functions (e.g., DevOps team) and can be temporary or permanent.
Policies	A set of actions permitted within a defined scope; where and under what conditions the role applies (e.g., by Cluster, Namespace, Labels/ Annotations).
Actions	The actions (tasks) a user can perform, within the specified scope of the policy.
Users	The users or service accounts assigned to roles in order to perform actions in the Komodor Application or at the cluster-level.

Users

Upon adding users to the Komodor platform, either via the UI or your IDP, each user must have a unique email address. Users can be added manually or automatically through SSO (Single Sign-On) if configured.

Note: When SSO is enabled, users should not be added manually via the UI. They are automatically created upon first login using SSO.

To perform any actions within Komodor, users must be assigned a role that includes the relevant policy with the required actions.
If no role is configured when users are created in Komodor, they will not have access.

For programmatic access after SSO is enabled (username/password), please contact Komodor Support.

Roles

Default Role

For every account, there is only one Default Role. When a user logs in and no role is assigned to the user, they will receive the default role.

If the user is added via SSO and komodorRoles are passed, then the default role is ignored.

Multi-roles

In Komodor, users are able to have multiple roles, what's important to remember is that the permissions are additive.

Temporary Roles

Temporary roles are role attachments with an expiration date. When the expiration date is reached, roles are automatically detached from the user.

An example use-case for temporary roles can be access to an on-call role which grants permissions on a wider scope, or short-lived access required for a specific project.

KomodorRoles via SAML in SSO

Once SSO has been set up via one of the guides available here, roles should be passed via SAML 2.0 attributes.

Once the user has been assigned roles in your IDP, upon login the user's access will be validated and should the corresponding user be found they will be allowed access to Komodor with the roles assigned from the IDP.

Once SSO is configured, roles should not be configured in the Komodor Users UI.
When no roles are passed either via the UI or via the IDP, the Default Role for the account is assigned to the user.

For full information per Access Management origin, see below:

Policies

Policies can contain multiple statements.

Policies define the specific actions a user can perform in Komodor and are used when assigning roles.

A policy can contain one or more statements.
When multiple statements exist in a policy, the OR operator is used.
When a single statement contains multiple rules (e.g., actions, resources), they are evaluated with an AND operator.

Example:
A statement granting manage:users and access to a specific namespace will only allow the action if both conditions are satisfied.

To grant full access to a cluster and also full access to a specific namespace, these should be defined in separate statements within the policy.

Scope types are a logical representation guiding users in selecting supported actions for their scope.

The available statement scope types are: Entire cluster, Namespaced resources, Cluster-wide resources, and Komodor admin.

Entire cluster statements apply only to specific cluster scopes and support all Komodor actions applicable to specific clusters.
Namespaced resources statements apply to specific namespaces within specific clusters and support all actions applicable to a specific namespace (note that all namespaced actions can be applied to an entire cluster).
Cluster-wide resource statements apply to a specific tracked key in a specific cluster and include all actions allowed on cluster-wide resources.
Komodor admin statements are scope-less and encompass all Komodor administrative permissions.

Wildcards and excludes

Policy administrators can dynamically allow permissions with more flexibility by using wildcards and wildcard excludes. This applies to the following scope types: Entire Cluster, Namespaced resources, and Cluster wide resources.

To use a wildcard, select the `matches wildcard` operator from the `where` block and use `*` to match all characters.

Preview Definition

To view the current cluster and namespace combinations available for wildcards (for all cluster and namespace resources), click the "preview definition" button.

Wildcard exclusions limit the scope of a wildcard and are only effective after a specific wildcard has been set.

For example, using `default*` and exclude `*docs` will result in only `default` namespace.

Tracked keys

Kubernetes label or annotation keys that are defined by an administrator are called tracked keys. They are utilized as scopes for cluster-wide resource statements and workspaces to manage access for specific teams, tenants, or applications. Screenshot 2025-04-27 at 17.53.12.png

Tracked keys are used in policies to slice and dice resources in clusters for cluster-wide resources such as nodes or cluster-roles.

Tracked keys can be created directly from the policy/workspace management screens or the tracked keys screen. Any user with the manage:trackedkeys action can delete them from the tracked keys management screen. A tracked key must be removed from all related policies and workspaces before an admin can delete it.

Please note: Only 10 Tracked Keys can be managed at a time.

For guides on creating users, policies, and actions please check out our How-To guides here.

Actions

Permissions granted as part of a policy are called actions. Each action has a list of scope availability matrix, as some actions are only relevant on specific scopes.

Action Name	Description	Entire Cluster	Namespaced Resources	Tracked keys	Komodor actions
view:cost	Access the costs optimization page	✅	❌	❌	❌
view:autoscalers	Access the Autoscalers add-on page	✅	❌	❌	❌
view:certmanager	Access the Cert manager add-on page	✅	❌	❌	❌
view:externaldns	Access the Autoscalers add-on page	✅	❌	❌	❌
read:helm-repo		✅	✅	❌	❌
update:helm-repo		✅	✅	❌	❌
add:helm-repo		✅	✅	❌	❌
remove:helm-repo		✅	✅	❌	❌
manage:helm	Access the Helm releases tab in the Drift analysis page Access the Helm add-on page	✅	✅	❌	❌
install:helm-chart		✅	✅	❌	❌
uninstall:helm-chart		✅	✅	❌	❌
revert:helm-chart		✅	✅	❌	❌
get:kubeconfig	Obtain the kubeconfig for all clusters that a user is authorized to access, download the kubeconfig file (for accounts that have RBAC Cluster Sync enabled.)	✅	✅	❌	❌
view:all	View all kubernetes and komodor resources in the relevant scope	✅	✅	❌	❌
manage:kubeconfig	Configure kubeconfig cluster url from the application	❌	❌	❌	✅
manage:reliability-policies	View, edit and delete reliability policies in organization settings page	❌	❌	❌	✅
manage:account-access	View, edit and delete IP allowlist in organization setting	❌	❌	❌	✅
manage:trackedkeys	View, edit and delete Tracked keys in organization settings	❌	❌	❌	✅
view:audit	View audit in organization settings	❌	❌	❌	✅
manage:workspaces	View edit and delete workspaces in organization settings	❌	❌	❌	✅
manage:agents	View and add new agents in organization settings	❌	❌	❌	✅
view:nodecount	Deprecated! - use view:usage instead	❌	❌	❌	✅
manage:users	View edit and delete users, roles, policies and actions in komodor	❌	❌	❌	✅
manage:monitors	View edit and delete Realtime monitors in health policies organization settings	❌	❌	❌	✅
manage:integrations	View edit and delete integrations in organization page	❌	❌	❌	✅
manage:features	Disable and enable features in organization settings	❌	❌	❌	✅
manage:reliability	???	❌	❌	❌	✅
view:usage	View Usage in organization settings	❌	❌	❌	✅
rollback:deployment	Rollback a deployment from a service page or a deployment drawer	✅	✅	❌	❌
rollback:statefulset	Rollback a statefulset from a service page or a statefulset drawer	✅	✅	❌	❌
rollback:daemonset	Rollback a daemonset from a service page or a daemonset drawer	✅	✅	❌	❌
run:cronjob	Run a cronjob from a Jobs page or a Cronjob drawer	✅	✅	❌	❌
rerun:job	Rerun a job from a Jobs page or a Cronjob drawer	✅	✅	❌	❌
restart:deployment	Restart a deployment from a service page or a deployment drawer	✅	✅	❌	❌
delete:pod	Delete a pod from pod drawer	✅	✅	❌	❌
delete:persistentvolumeclaim	Delete a persistentvolumeclaim from persistentvolumeclaim drawer	✅	✅	❌	❌
restart:statefulset	Restart a statefulset from a service page or a statefulset drawer	✅	✅	❌	❌
restart:daemonset	Restart a daemonset from a service page or a daemonset drawer	✅	✅	❌	❌
edit:deployment	Edit yaml for a deployment from a service page or a deployment drawer	✅	✅	❌	❌
delete:deployment	Delete a deployment from a service page or a deployment drawer	✅	✅	❌	❌
edit:statefulset	Edit yaml for a statefulset from a service page or a statefulset drawer	✅	✅	❌	❌
edit:service	Edit yaml for a service from a kubernetes service drawer	✅	✅	❌	❌
delete:service	Delete a service from a kubernetes service drawer	✅	✅	❌	❌
delete:ingress	Delete an ingress from an ingress drawer	✅	✅	❌	❌
delete:networkpolicy	Delete a networkpolicy from a networkpolicy drawer	✅	✅	❌	❌
edit:replicaset	Edit yaml for a replicaset from a replicaset drawer	✅	✅	❌	❌
delete:replicaset	Delete a replicaset from a replicaset drawer	✅	✅	❌	❌
edit:job	Edit yaml for a job from a job drawer	✅	✅	❌	❌
delete:job	Delete a job from a job drawer	✅	✅	❌	❌
edit:cronjob	Edit yaml for a cronjob from a cronjob drawer	✅	✅	❌	❌
delete:statefulset	Delete a statefulset from a statefulset drawer	✅	✅	❌	❌
get:deployment	?	✅	✅	❌	❌
get:statefulset	?	✅	✅	❌	❌
get:daemonset	?	✅	✅	❌	❌
delete:cronjob	Delete a cronjob from a cronjob drawer	✅	✅	❌	❌
delete:daemonset	Delete a daemonset from a daemonset drawer	✅	✅	❌	❌
exec:pod	Open an interactive shell to a specific pod from the pod drawer	✅	✅	❌	❌
forward:port	Create a port forward session using komo-cli to a specific pod from a pod drawer	✅	✅	❌	❌
edit:configmap	Edit yaml for a configmap from a configmap drawer	✅	✅	❌	❌
edit:secret	Edit yaml for a secret from a secret drawer	✅	✅	❌	❌
edit:horizontalpodautoscaler	Edit yaml for a horizontalpodautoscaler from a horizontalpodautoscaler drawer	✅	✅	❌	❌
scale:statefulset	Scale a statefulset from a statefulset drawer or service screen	✅	✅	❌	❌
scale:deployment	Scale a deployment from a deployment drawer or service screen	✅	✅	❌	❌
cordon:node	Cordon a node from a node drawer	✅	❌	✅	❌
uncordon:node	Uncordon a node from a node drawer	✅	❌	✅	❌
drain:node	Drain a node from a node drawer	✅	❌	✅	❌
delete:persistentvolume	Delete a persistentvolume from a persistentvolume drawer	✅	❌	✅	❌
delete:storageclass	Delete a storageclass from a storageclass drawer	✅	❌	✅	❌
view:persistentvolumes	List persistentvolumes in the PV native resources page	✅	❌	✅	❌
view:clusterroles	List clusterroles in the cluster-roles native resources page	✅	❌	✅	❌
view:customresourcedefinitions	List CRDs in the cluster-roles native resources page	✅	❌	✅	❌
view:storageclasses	List storageclasses in the cluster-roles native resources page	✅	❌	✅	❌
view:nodes	List clusterroles in the cluster-roles native resources page	✅	❌	✅	❌
view:namespaces	List clusterroles in the cluster-roles native resources page	✅	❌	✅	❌

Key Concepts

When do permissions actually change?

Permissions change immediately. However, due to local caching by the web app, logging in again may be required to clear the cache and reflect the updated permissions in some areas in the system.

The Komodor backend caching mechanism has a duration of 1 minute.

The RBAC Sync process initiates every minute and may require up to 10 minutes to complete, depending on the quantity of resources that need to be created or modified on the target cluster.

Additive Permissions in Komodor:

Komodor's RBAC is additive. This means that if a user is assigned multiple policies, or a single policy with multiple statements, their total permissions are the sum of all the allowed actions defined in those policies and statements. There's no explicit "deny" mechanism in this basic additive model within Komodor. If a user has a policy that allows them to "view:nodes" and another that allows them to "cordon:nodes" they will be able to do both.

This additive approach simplifies permission management by clearly defining what each role can do.

Workspaces and RBAC

Workspaces only display resources if the user's RBAC policies allow access. In other words, a workspace filters what you're permitted to see - it does not extend the users’s permissions.