Role-Based Access Control (RBAC)
Last updated
Last updated
Role-Based Access Control (RBAC) in groundcover gives you a flexible way to manage who can access certain features and data in the platform. By defining both default roles and policies, you ensure each team member only sees and does what their level of access permits. This approach strengthens security and simplifies onboarding, allowing administrators to confidently grant or limit access.
Policies are the foundational elements of groundcover’s RBAC. Each policy defines:
A permission level – which actions the user can perform (Admin, Editor, or Viewer-like capabilities).
A data scope – which clusters, environments, or namespaces the user can see.
By assigning one or more policies to a user, you can precisely control both what they can do and where they can do it.
groundcover provides three default policies to simplify common use cases:
Default Admin Policy
Permission: Admin
Data Scope: Full (no restrictions)
Behavior: Unlimited access to groundcover features and configurations.
Default Editor Policy
Permission: Editor
Data Scope: Full (no restrictions)
Behavior: Full creative/editing capabilities on observability data, but no user or system management.
Default Viewer Policy
Permission: Viewer
Data Scope: Full (no restrictions)
Behavior: Read-only access to all data in groundcover.
These default policies allow you to quickly onboard new users with typical Admin/Editor/Viewer capabilities. However, you can also create custom policies with narrower data scopes, if needed.
A policy’s data scope can be defined in two modes: Simple or Advanced.
Simple Mode
Uses AND logic across the specified conditions.
Applies the same scope to all entity types (e.g., logs, traces, events, workloads).
Example: “Cluster = Dev AND Environment = QA,” restricting all logs, traces, events, etc. to the Dev cluster and QA environment.
Advanced Mode
Lets you define different scopes for each data entity (logs, traces, events, workloads, etc.).
Each scope can use OR logic among conditions, allowing more fine-grained control.
Example:
Logs: “Cluster = Dev OR Prod,”
Traces: “Namespace = abc123,”
Events: “Environment = Staging OR Prod.”
When creating or editing a policy, you select permission (Admin, Editor, or Viewer) and a data scope mode (Simple or Advanced).
A user can be associated with multiple policies. When that occurs:
Permission Merging
The user’s final permission level is the highest among all assigned policies.
Example: If one policy grants Editor and another grants Viewer, the user is effectively an Editor overall.
Data Scope Merging
Data scopes merge via OR logic, broadening the user’s overall data access.
Example: Policy A => “Cluster = A,” Policy B => “Environment = B,” so final scope is “Cluster A OR Environment B.”
Metrics Exception
For metrics data only, groundcover uses a single policy’s scope (not a combination). This prevents creating an overly broad metrics view when multiple policies are assigned.
By combining multiple policies, you can support sophisticated permission setups—for example, granting Editor capabilities in certain clusters while restricting a user to Viewer in others. The user’s final access reflects the highest permission among their assigned policies and the union (OR) of scopes for all data types except metrics.
In summary:
Policies define both permission (Admin, Editor, or Viewer) and data scope (clusters, environments, namespaces).
Default Policies (Admin, Editor, Viewer) provide no data restrictions, suitable for quick onboarding.
Custom Policies allow more granular restrictions, specifying exactly which entities a user can see or modify.
Multiple Policies can co-exist, merging permission levels and data scopes (with a special rule for metrics).
This flexible system gives you robust control over observability data in groundcover, ensuring each user has precisely the access they need.