Authorization: Role-Based Access Control

RBAC simplifies the management of permissions by associating permissions with roles rather than with individual users. Users are assigned roles based on their job responsibilities, and these roles determine what actions they can perform and what resources they can access. This approach makes it easier to manage permissions, enforce policies, and maintain security as organizational roles and responsibilities change.

RBAC is an effective and scalable approach to managing user access within a system. By defining roles with specific permissions and assigning these roles to users, organizations can enhance security, simplify access management, and ensure that users only have the access they need for their job functions.

Explore further Kloudfuse documentation on RBAC:

Pillars of Role-Based Access Control

Kloudfuse implements a comprehensive RBAC system built on the traditional four pillars of access control, enhanced with additional components for enterprise-scale observability platforms.

Core RBAC Pillars

The foundation of Kloudfuse RBAC consists of these essential components:

Roles - Predefined sets of permissions (Admin, Editor, Viewer)
Permissions - Specific actions users can perform within the system
Users - Individual accounts that are assigned roles and permissions
Role Assignments - The mechanism that links users to their designated roles

Enhanced Kloudfuse Components

Beyond the core RBAC model, Kloudfuse provides additional access control mechanisms:

Teams - Groups of users with collective permissions and hierarchical management
Folders - Organizational containers that provide granular access control for dashboards, alerts, and Kloudfuse objects
Policies - Data access filters that define what information user groups can view
Service Accounts - Non-human accounts for system integrations and automated processes

Together, these components create a flexible and scalable permission system suitable for complex observability environments.

Roles

Definition: A role is a collection of permissions that define what actions a user can perform within a system.
Examples: Common roles include Administrator, Editor, and Viewer. Each role has a specific set of permissions associated with it.

Role Permissions Matrix

The following table details the specific permissions available to each role in the Kloudfuse platform:

Permissions

Admin

Editor

Viewer

USER & ACCESS MANAGEMENT

View/Delete Users

Modify User Roles

Create/Edit/Delete Teams (as Team Admin)

Create/Edit/Delete Teams (as Team Member)

View Teams

All Teams

Own Teams Only

View/Create/Edit/Delete Service Accounts

View/Create/Edit/Delete Policies

View Folders

Create/Edit/Delete Folders

All Folders

Based on Folder Permissions

DATA ACCESS

View Metrics Explorer

View Logs Explorer

View APM Explorer

View Events Explorer

View RUM (Real User Monitoring)

View Infrastructure Monitoring

DASHBOARDS & VISUALIZATION

View Dashboards

Create/Edit/Delete Dashboards

Based on Folder Permissions

ALERTING & MONITORING

View Alerts

Create/Edit/Delete Alert Rules

Based on Folder Permissions

Create/Edit/Delete Alert Contact Points

Create/Edit/Delete Alert Notification Channels

Create/Edit/Delete SLOs

PLATFORM CONFIGURATION

Create/Edit/Delete RUM Applications

Create/Edit/Delete Lookup Tables

Create/Edit/Delete Scheduled Views

Create/Edit/Delete Saved Log Queries

Create/Edit/Delete Rate Control

Create/Edit/Delete Data Scrubbing

Create/Edit/Delete Favorite Facets

= Full access
= Edit/Modify access with restrictions
= Read-only access
= No access

Permission may be further refined through folder-level permissions and policies.

Permissions

Definition: Permissions are the rights or privileges granted to perform certain actions or access specific resources.
Examples: Permissions might include read, write, delete, or execute rights on dashboards and alerts, or access to specific applications and data.

Users

Definition: Users are individuals who interact with the system. Each user is assigned a role based on their job function and needs.
Examples: An Admin or SRE may be assigned roles that grant access to a specific namespace, folder, dashboards, or alerts.

Role Assignments

Definition: Role assignments involve linking users to specific roles. This mapping determines what roles a user holds and, consequently, what permissions they have.
Examples: Assigning a user the role of "Administrator" grants them access to all administrative functions, whereas assigning them the role of "Viewer" restricts them to only seeing traces.

Other Important Concepts in RBAC

In addition to the Pillars, Kloudfuse supports the following concepts in RBAC:

Separation of Duties (SoD)

Definition: SoD is a principle to ensure that no single role has enough permissions to misuse the system or commit fraud. It helps in preventing conflicts of interest.
Examples: The role responsible for approving payments should not be the same role that processes payments.

Least Privilege

Definition: This principle involves granting users the minimum level of access necessary to perform their job functions, reducing the risk of accidental or malicious misuse of resources.
Examples: A user who only needs to view reports should not have permission to edit or delete them.

Access Control Lists (ACLs) vs. RBAC

ACLs: Define permissions for specific resources, specifying which users or roles can access each resource and what actions they can perform.
RBAC: Groups permissions into roles and assigns these roles to users, making it easier to manage and audit access.

Benefits of RBAC

Using RBAC in your suite of observability tools provides significant benefits:

Simplified Management

By grouping permissions into roles, RBAC simplifies the process of managing and auditing access controls, especially in large organizations.

Enhanced Security

Ensures that users only have access to the resources and functions necessary for their roles, reducing the risk of unauthorized access.

Compliance

Helps organizations meet regulatory requirements and standards by providing clear role-based access policies and audit trails.

RBAC Use Cases

Kloudfuse enables your organization to realize these important functions:

Allow certain users to only read level access for all objects: This can be set at the level of a user or group, by assigning the Viewer role.
Allow certain users read-write access to all objects: This can be set at the level of the user or group, by assigning Editor or Admin role.
Allow users access to any objects they create: This is on by default; as a user creates an object, Kloudfuse automatically grants that user full access to that object, regardless of their role. All other users get access to the new object based on their assigned roles.
Allow administrators to create policies: Policies are a set of filters (key, operation and value) for each user group. If a user belongs to multiple groups, they get access to all assets as a union; the filters combine in an implicit OR operation to determine which object data the user can access.

Hierarchy of permissions

Kloudfuse determines a user’s access to a folder based on the highest permission level granted across all sources, including direct user permissions, group memberships, and assigned roles within a folder.

To prevent a user from accessing a folder or dashboard, consider their role in the organization, folder permissions, and dashboard permissions.

You cannot override organization administrator permissions; they can access all resources.
User’s permissions on a folder apply to all dashboards and subfolders.
An explicitly set lower permission level is ineffective if a more permissive rule applies higher in folder/dashboard hierarchy.