Role-Based Access Control (RBAC)

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:

• RBAC Management

  • Manage Users
  • Service Accounts
  • Manage Folders
  • Manage Teams
  • Manage Policies

• RBAC Configuration

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

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.