Role-based access control for Kubernetes resources
Role-based access control (RBAC) in Virtana Platform lets you enforce least-privilege access to the Kubernetes environments that CO monitors. As an administrator, you combine resource groups, data access groups, and user groups so that each user sees only the clusters or namespaces they are responsible for.
Virtana Platform supports two access models for Kubernetes resources:
Namespace-level access restricts a user to one or more selected namespaces within a cluster, so that workloads, logs, and alerts from other namespaces stay hidden.
Cluster-level access grants a user visibility into all resources and namespaces in one selected Kubernetes cluster.
This topic covers the RBAC-specific choices you make in each model. For the field-level detail and the navigation steps on each Settings page, this topic links to the existing configuration topics instead of repeating them.
Note
You must have Administrator privileges in the platform to configure Role-Based Access Control (RBAC), including creating and managing Resource Groups, Data Access Groups (DAGs), User Groups, and user assignments.
RBAC components
Virtana Platform enforces access boundaries through four objects. You configure them in the order shown in the following table, because each object references the one above it.
Component | Description |
|---|---|
Resource group | Filters resources by criteria such as source cluster, entity type, and Kubernetes namespace label. Required only for namespace-level access. |
Data access group (DAG) | Defines the data boundary. A DAG points either directly at a CO cluster or at a resource group. |
User group | Combines a platform role, such as Reader, with one or more data access groups. |
User account | An individual account that takes its role and its data boundary from the user groups it belongs to. |
For conceptual background on each object, see resource groups in virtana platform, using data access groups, and managing user groups.
Before you begin
Before you configure RBAC for Kubernetes resources, confirm the following:
You have the Administrator role in Virtana Platform. Every option under Settings, including Resource Groups and Users Management, requires administrator privileges. For the privileges attached to each role, see user roles in virtana platform.
The target Kubernetes cluster is onboarded and actively sending metrics to CO. The cluster must be reporting data before it appears as a selectable source in a resource group or a data access group.
You know the exact cluster name and, for namespace-level access, the namespace value to filter on.
Configure namespace-level access
Namespace-level access restricts a user to selected namespaces within a Kubernetes cluster. Use this model for application teams, service owners, and external auditors who should see only their own workloads, for example, to isolate production traffic or to protect data that is in scope for a compliance audit. It adds a resource group in front of the data access group. The resource group carries the namespace filter, and the DAG then points at the resource group instead of at the cluster.
Step 1: Create the resource group
Resource Groups in the Virtana Platform provide a logical way to organize infrastructure resources across environments, enabling efficient monitoring, analysis, and optimization through integrated observability, alert filtering, and topology visualization. To learn more, see the configure resource groups.
Perform the steps to create the resource group:
Log in to the Virtana Platform and open Settings.
In the left navigation panel, select Resource Groups and click Add Resource Group.
Configure the general properties, such as the name and description of the resource group.
Click Add Criteria and configure the filtering parameters:
Field
Value to enter or select
Source Type
Container Observability
Sources
The single cluster that hosts the namespace, for example,
prod-eks-cluster. Use one criteria block per cluster.Entity Types and Entities
The Kubernetes entities to expose, such as nodes, services, deployments, and workloads.
Labels
Select the Namespace label key, and then select the namespace value, for example,
payments.Note
The Labels field is what produces the namespace boundary. A resource group that omits the Namespace label scopes to the entire cluster, not to a namespace.
Open the Results Preview tab to confirm that only the entities from the intended namespace are listed.
Click Save to create the Resource Group.
Step 2: Create the data access group
Data Access Groups (DAGs) in the Virtana Platform control user access to specific data sets, ensuring security and confidentiality by limiting visibility based on permissions. DAG turns the resource group into a data boundary that you can assign to users. To learn more, see the using data access groups.
Perform the steps to create the data access group:
Log in to the Virtana Platform and open Settings.
In the left navigation panel, select User Management > Data Access Groups.
Click Create Data Access Group.
In the Create Data Access Group window, update the following fields with specific values.
Field
Value to enter or select
Name
A name that identifies the namespace boundary, for example,
DAG - Payments namespace scope.Description
Enter an optional description.
Source Type
Resource Group
Source criteria
The resource group you created in Step 1, for example,
RG - Payments namespace.Note
Selecting Resource Group as the Source Type is what narrows the boundary to a namespace. Selecting Container Observability instead grants access to the whole cluster.
Click Save.
Step 3: Create the user group and assign roles
User Groups in the Virtana Platform simplify user administration by allowing roles and data access permissions to be assigned to multiple users at once. Administrator privileges are required to manage User Groups. The user group and user stages are the same as for cluster-level access, with one change: attach the namespace-scoped DAG instead of the cluster-scoped DAG. To learn more, see the managing user groups.
Perform the steps to create the user group:
In the left navigation panel, select User Management > User Groups.
Click Create User Group.
Configure the general properties, such as the name and description of the user group.
Select the appropriate role, for example, Reader for read-only monitoring.
Select the DAG created in Step 2.
Click Save.
Step 4: Map Users to the User Group
Administrators can use the Users List page to invite new users, manage user accounts, and map users to appropriate User Groups to control access and permissions. To learn more, see the inviting users to an organization.
Perform the steps to invite users to the user group:
In the left navigation panel, select User Management> Users.
Select an existing user or click Invite New User.
In the user configuration panel, map the user, for example, alice@example.com, to the Payments Team Readers User Group.
Click Save.
Access flows through the following relationship: Alice > Payments team readers > Reader role + DAG - Payments namespace scope > RG - Payments namespace > payments namespace on prod-eks-cluster. Alice can view the telemetry, topology, logs, and alerts for the payments namespace. Resources in other namespaces of the same cluster, such as orders or kube-system, are not exposed through this configuration.
Configure cluster-level access
Cluster-level access gives a user visibility into every resource and namespace in one Kubernetes cluster. Use this model for platform administrators, site reliability engineers, and infrastructure engineers who support a whole cluster. Cluster-level access needs a data access group and a user group. It does not need a resource group.
Step 1: Create the data access group
The data access group (DAG) sets the data boundary at the cluster level. Open Data Access Groups from the Users Management tab in Settings, and then follow the steps in using data access groups.
In the Create Data Access Group window, update the following fields with specific values:
Field | Value to enter or select |
|---|---|
Name | A name that identifies the cluster boundary, for example, |
Source Type | Container Observability |
Source criteria | The target Kubernetes cluster, for example, |
Users who receive this DAG can access data from the selected cluster, limited by the role in their user group.
Step 2: Create the user group
The user group pairs a role with the data access group, so it controls both what a user can do and which data the user can see. Open User Groups from the Users Management tab in Settings, and then follow the instructions available in Step 3 of Configure namespace-level access. To learn more, see themanaging user groups.
In the Create User Group window, update the following fields with RBAC-specific values:
Field | Value to enter or select |
|---|---|
User Group Name | A name that identifies the audience, for example, |
Role | Reader for read-only monitoring. For the privileges of each role, see user roles in virtana platform. |
Data Access Groups | The DAG you created in Step 1, for example, |
Step 3: Assign users to the user group
A user inherits the role and data boundary of every user group they belong to. Open Users from the Users Management tab in Settings, and then do one of the following:
To add a user who does not exist yet, click Invite New Users and select the user group you created in Step 2 as the User Group Name. For the invitation rules and the email address format, see inviting users to an organization.
To move an existing user, click the User Group value for that account and select the user group you created in Step 2. For the full set of actions on this page, see managing user groups.
Access flows through the following relationship: Alice > Production platform readers > Reader role + DAG - Production EKS > prod-eks-cluster. Alice can view the resources in prod-eks-cluster and gains no write permissions from this configuration.
Cluster-level access compared with namespace-level access
The following table compares the two access models, so that you can select the one that matches the audience you are granting access to.
Attribute | Cluster-level access | Namespace-level access |
|---|---|---|
Boundary scope | An entire Kubernetes cluster. | One or more namespaces within a cluster. |
Granularity | Broad. | Fine-grained, suitable for multi-tenant clusters. |
Required components | Data access group and user group. | Resource group, data access group, and user group. |
DAG source type | Set to Container Observability, with the cluster selected directly. | Set to Resource Group, with the namespace-filtered resource group selected. |
Typical audience | Site reliability engineers, platform operations, and infrastructure engineers. | Application developers, service owners, and external auditors. |
Isolation achieved | Separates one cluster from another. | Separates workloads and logs within the same cluster. |
Verify the configuration
After you configure RBAC, sign in as the scoped user and confirm each of the following. If any check fails, review the source criteria on the resource group and the data access group.
Data boundary. Only the permitted clusters or namespaces appear in Global View, in node maps, and in CO dashboards.
Cross-namespace restriction. An unassigned namespace, such as
kube-systemororders, returns no data or cannot be selected.Role permissions. A user with the Reader role cannot change cluster settings, edit dashboards, or modify alert policies. For the privileges of each role, see user roles in virtana platform.
Resource group mapping. For namespace-level access, the Results Preview tab of the resource group lists only entities from the intended namespace.
Note
If you change the access of a user who is already signed in, ask the user to sign out and sign back in before they validate their access. Permission changes take effect when the platform issues a new session token.