In large organizations, observability data—like metrics, logs, and traces—becomes a shared playground for many teams. However, figuring out who can access or modify that data quickly becomes a tangled mess. When access rules are fuzzy, one group can unknowingly adjust another group's dashboards or alerts, creating confusion and sometimes leaking sensitive details. Granting broad permissions and making a bad-faith move can jeopardize the entire system.

This is where Role-Based Access Control (RBAC) comes into play. RBAC provides a way to organize permissions by role, ensuring each user or team only has the “keys” they need. It helps organizations limit access to sensitive data and comply with security standards such as GDPR and HIPAA. 

In Kloudfuse, RBAC is built right into the platform to address precisely this challenge. By assigning people to roles (and teams to groups) and defining the capabilities of those roles, Kloudfuse makes observability access management much simpler. 

Understanding RBAC Fundamentals

At its core, RBAC (Role-Based Access Control) is about mapping who can perform specific actions via defined roles. Kloudfuse defines a role as “a collection of permissions that define what actions a user can perform within the system.” 

Features of RBAC

These three features of RBAC make it scalable and easy to manage in dynamic environments:

1. Service-to-Service Authentication: RBAC isn’t just for people; it also applies to backend services communicating with each other. With service-to-service authentication, each service can be assigned roles that define what it's allowed to access or trigger in another service. Starting from version 3.4, Kloudfuse has added the ability to create service accounts to securely interact with other systems or APIs.
   
   

2. Group Sync: Managing user access manually doesn't scale. Group sync enables you to automatically map identity provider groups to Kloudfuse groups and admin, editor and viewer roles. This ensures that users always have the correct permissions based on their organizational group membership.
   
   

3. Audit Logs: Kloudfuse logs every permission change, role update, and access attempt. Audit logs include login activity, admin actions like team and role changes, and updates to dashboards, alerts, and folders. Audit logs provide a transparent trail of who did what and when, helping teams stay compliant, secure, and accountable.

Roles in RBAC

In practical terms, Kloudfuse provides three primary built-in roles: Admin, Editor, and Viewer. Each role comes with a preset bundle of permissions:

1. Admin: It’s the super-user role. Admins can manage users and groups, configure system settings, and have full read/write access across Kloudfuse. Simply put, an Admin “can change roles and permissions” and perform any action on dashboards, alerts, and data.
   
   

2. Editor: It’s the power-user role. Editors can create and edit dashboards, alerts, queries, etc., but cannot manage other users or system-level settings. In Kloudfuse terms, Editors “can make some changes” – they can build and modify content, but won’t see user-management or system-admin options.
   
   

3. Viewer: It’s the read-only role. Viewers can see most dashboard and alert pages, but cannot make any edits. As the docs put it, Viewers “can only view data, but cannot make any changes”. This is ideal for stakeholders who need insight but shouldn’t risk making any changes.
   
   

By default, Kloudfuse assigns new users the Editor role (though you can change this default). You can always update a user’s role in the UI, for example, an existing Editor can be elevated to Admin by simply selecting the new role and saving.

Permissions in RBAC

Behind these roles are a set of specific permissions (read, write, delete, etc.) that each role grants on dashboards, alerts, folders, logs, and other resources. For example, an Admin might have rights like “Add Admin user” or “Configure user,” whereas an Editor would not. Kloudfuse groups all such permissions under the roles, so you don’t have to attach individual rights to each person. 

It’s essential to distinguish between how we control access to data and how we control access to features like dashboards and alerts. Data access should be handled through scope filters—so people only see what they’re supposed to, like data for their team or environment. On the other hand, access to artifacts like dashboards and alerts should stick to traditional roles and permissions using RBAC.

Benefits of RBAC

Unlike the traditional access-control list (ACL), which hands out permissions one-by-one to every user, role-based access control (RBAC) organizes those permissions into tidy job roles. ACLs permit extremely granular tweaks. For example, Alice can edit Dashboard X, while Bob is limited to Alert Y; however, that level of detail quickly becomes a tangled web once you add more users and resources. 

RBAC side steps that spiral by assigning whole bundles of permissions to a role and then linking that role to individual staff or teams, so scaling up feels almost effortless. Because the system is so straightforward, it also lines up nicely with two key security ideas:

• Least Privilege

Each user (or team) should get only the access they absolutely need, no more. Kloudfuse’s RBAC encourages this by making it easy to grant exactly the role needed and nothing extra. This reduces the risk of accidental or malicious misuse of resources. For example, if someone only needs to view reports, they should be assigned to the Viewer role and not have Editor or Admin privileges.

• Separation of Duties (SoD)

Critical tasks are split among roles so that no single person can both initiate and approve sensitive changes. For instance, the team that can configure alerts might be different from the team that approves them, preventing one person from both creating an alert and notifying all users without oversight. Kloudfuse’s RBAC framework is designed to support this principle by clearly separating the Admin role (who might create or assign roles) from the daily data consumers (Editors/Viewers).

Let’s take a closer look at how Kloudfuse’s RBAC is structured and how roles and permissions shift when multiple teams are involved.

Kloudfuse RBAC Architecture: Roles and Permissions Matrix

The table below outlines Kloudfuse's three-tier role-based access control system by mapping specific capabilities to Admin, Editor, and Viewer roles.

1. Admin privileges include user and team management: They can add or remove users, change a user's role, and configure user settings. They can also read and write all dashboards, alerts, and metrics across the platform. 

2. Editors lack the user-management powers but have broad access to create and edit observability content. A typical Editor can edit existing dashboards and alerts or save new log queries, but cannot add another Admin user or alter group membership. 

3. Viewers have the most limited capabilities: They can navigate the dashboards and alert views, but every data-edit action is disabled for them. 

In organizations with multiple teams, users often belong to several groups, each with distinct roles and data access policies. In groups, concepts like role Inheritance and permission stacking overtake.

• Role Inheritance: In multi-team scenarios, Kloudfuse supports group-based role assignments. You create a Team for each department or function, add users to the team. Any user in "Team X" then inherits that team's role privileges. For instance, if the "DevOps" team has the Editor role, all DevOps engineers are assigned the Editor role. If one person is in two teams(for example, they work on both a "Backend" and a "Security" team), they receive the union of those teams’access, effectively the highest role they hold. 

In other words, a user will have Admin powers if any of their groups grant Admin; otherwise, they will have Editor powers if any group grants Editor, and Viewer powers otherwise. This union behavior ensures a user doesn't accidentally lose needed access by being in multiple teams.

• Permission Stacking: Kloudfuse also lets roles "stack" in the sense of filter policies. If a user belongs to multiple groups with different data filters, they see data according to all of them. If a user belongs to multiple teams with different data policies, they see data allowed by any of the policies. In other words, policies are combined using logical OR.. The net effect is that Kloudfuse merges both the broad role privileges and the scoped data filters when a user spans teams. This flexible matrix of roles-and-policies gives admins fine-grained control over both "what actions" a user can do and "what data" they can see.

This flexible group-based approach makes it straightforward to implement multi-team access control in practice. Let’s check it out next.

Step-by-Step Implementation: Setting Up Multi-Team Access

Let's walk through setting up RBAC for our example with four teams: Frontend, Backend, SRE, and Security. We'll build this systematically, starting with the foundation and adding layers of control.

Assign Roles to Users

Before creating teams, establish the three core access levels that will govern what users can do in Kloudfuse. Access the Users interface by signing in to Kloudfuse with an Admin account and navigating to Admin → Users from the top menu.

Fig 1: Selecting User in the Admin Tab in Kloudfuse

For our example, you'll want to: 

1. Assign SRE team Admin roles for full system oversight

2. Assign Editor roles to Frontend and Backend engineers for dashboard creation

3. Set the Security team as Admins for audit capabilities

4. Keep Marketing or Business users as Viewers for dashboard consumption.

This foundation matters because roles determine the baseline capabilities. Getting this right prevents having to retroactively adjust permissions later as your organization grows. If you have a small team, assigning roles directly to users is an appropriate option. As already discussed, each user in Kloudfuse has one of three roles: Admin, Editor, or Viewer. By default, users are assigned the Editor role, but you can change this in a few clicks.

To change a user’s role:

1. Locate the user in the list.
   
   

2. Hover over their Role, and you’ll see an Edit icon appear.

Fig 2: Hovering over the Desired User to Change Role

3. Click the icon to open the user’s details and in the Role section, click Change Role.

4. Select the new role (e.g., from Editor to Admin) and click Save.

Fig 3: Selecting and Saving Role

When users first join Kloudfuse, their names may not be set. Assigning a clear name helps teams identify and manage users more easily.

To assign a name:

1. In the same user detail view, scroll to the Name section.
   
   

2. Click the Edit icon.

Fig 4: Renaming User with Kloudfuse

3. Type in the user’s full name and click Save.

When multiple people require the same roles, organizing them in a group makes more sense.

Create Teams

Groups are how you organize users into logical teams and apply consistent policies across team members. Navigate to Admin → Teams and create your team structure by clicking Add New Group for each team. 

Fig 5: Selecting Teams in Admin

You'll want to create teams like frontend_team, backend_team, sre_team, and security_team, each with their respective team email addresses. Once in the Teams tab, you can Create Teams easily:

• Click Create Team.
  
  

• Fill in the required fields, such as the Name of the team.
  
  

• Click Save.

Fig 6: Naming Team

Once your teams are created, populate them with team members by selecting each team and adding the appropriate users. You'll assign team leads as Admins who can manage team membership, while regular team members get standard "Member" permissions within the team.

To add a member to the team:

• On the team’s detail page, click Add Member.
  
  

• Select a user from the drop-down or search by username.
  
  

• Choose their role (Member by default, or Admin), then click Add Member.

Fig 7: Adding Team Members in the Team

Currently, each team member can have one of two roles:

• Admin can manage the team
  
  

• Member has standard access with no permission to change settings

The power of teams becomes apparent when you realize they allow you to manage permissions at scale. Instead of setting individual user permissions for dozens of team members, you modify the team, and all members inherit the changes automatically.

Currently, each group member can have one of two roles:

• Admin can manage the group
  
  

• Member has standard access with no permission to change settings

The power of groups becomes apparent when you realize they allow you to manage permissions at scale. Instead of setting individual user permissions for dozens of team members, you modify the group, and all members inherit the changes automatically.

Organize Content with Folders

Folders provide the organizational structure that keeps each team's dashboards and alerts separate and secure. Navigate to Admin → Folders and create team-specific folders like "Frontend Dashboards," "Backend Services," "SRE Operations," "Security Monitoring," and "Shared Dashboards" for company-wide metrics. 

Fig 8: Going to Folders in the Admin Section

Here’s how to create a simple folder:

• Click Add New Folder
  
  

• Enter a name like SRE-Team-Folder, then click Create New Folder

Once created, the folder appears in the Folders list, ready for permissions.

Fig 9: Creating a New Folder

Setting folder permissions correctly is where the magic happens. Once your folders are created, you need to configure who can access each one. Here's how to set up the permissions:

1. In the Folders interface, hover over the folder name you want to configure

2. Click "Add Permission to Folder" to add team-specific access

3. Choose "Group" as the permission type, search for your team group (SRE-Team), and select the appropriate permission level (Admin, Edit, or View)

4. Click Save to apply the permissions

Fig 10: Adding Permissions to the Folder

This organizational approach prevents teams from accidentally modifying each other's work while maintaining visibility where needed. The structure scales naturally as your teams grow and add new services or monitoring requirements.

Implement Data Filtering with Policies

Policies represent the most powerful feature in Kloudfuse's RBAC system because they filter what data each team can see, ensuring teams only access relevant information. Navigate to Admin → Policies and create data scope policies that match your infrastructure.

Fig 11: Navigating to Policies

Create policies like frontend_data_access that filter by app_type = "frontend" or service = "web-app", and backend_data_access that filter by app_type = "backend" or service = "api". 

Fig 12: Creating Access Policy

You might also want a production_only policy that filters by environment = "production" and a security_audit_access policy with broad access for comprehensive audit capabilities.

Applying these policies to your groups creates the final layer of access control. The Frontend team gets both frontend_data_access and production_only policies, while the Backend team receives backend_data_access and production_only. The SRE team gets broad access with minimal filtering, and the Security team is granted security_audit_access for comprehensive monitoring. With Kloudfuse 3.4, you can assign RBAC policies to both users and service accounts. So, now if the team has 

Best Practices and Common Pitfalls

When rolling out RBAC in Kloudfuse, a few guiding practices help maintain order:

• Principle of Least Privilege: Always start users on the minimum role they need. If someone only needs to view data, make them a Viewer. Don’t give out Admin privileges lightly. For example, you might make new hires Editors until proven trustworthy, or restrict Editor roles to team leads. Regularly review roles to prevent the IT admin list from quietly ballooning.
  
  

• Avoid Role Explosion: Resist creating too many nearly-duplicate roles or groups. Kloudfuse’s fixed Admin/Editor/Viewer scheme rarely needs a custom role. Instead of duplicating roles, use groups and policies. For instance, don’t create separate roles for “Frontend Editor” and “Backend Editor”; use one Editor role, but individual groups and folder/policy filters for each team. This keeps the number of distinct roles small and manageable.
  
  

• Folder and Policy Hygiene: As you create folder structures and policies, document their purpose. Give policies clear names (e.g., only_pods_in_prod) and track which groups they’re attached to. It’s easy to lose track of a stray filter blocking data.
  
  

• Troubleshooting Tips: If a user reports they can’t access a dashboard or metric, first, confirm their role (using Admin→Users). If their role seems correct, verify their group assignment and policies. Remember, new changes often require the user to refresh the page or even re-login. One common issue is forgetting that filters combine with AND – if a user is in two groups with conflicting filters, they might see no data at all. Also note that newly added users won’t appear in the UI until their first successful login. If a folder remains inaccessible, check if it was marked as private by its creator.
  
  

• Regular Audits: Kloudfuse provides auditing capabilities for compliance. Administrators can review authentication and authorization logs to see who did what. For example, you can view login events in the kfuse-auth logs and RBAC actions in the user-mgmt-service logs. In practice, schedule periodic reviews of user roles, group policies, and audit logs. This catches drift (say, someone leaving the team but still in a group) and ensures that role assignments remain appropriate over time.

By adhering to these practices, you’ll avoid the classic pitfall of permission bloat (too many over-powered accounts) and ensure Kloudfuse’s RBAC works as intended. Kloudfuse’s documentation reinforces these ideas – for instance, it notes that the RBAC approach “ensures that users only have the access necessary for their roles,” greatly reducing security risk.

Conclusion

Implementing RBAC in Kloudfuse pays off in both security and efficiency. By controlling access via roles and groups rather than ad-hoc permissions, we simplify management. Grouping permissions into roles “makes it easier to manage and audit access controls” in large organizations. On the security side, RBAC enforces that users can only touch what they need, reducing the chance of accidents or data leaks.

From a business standpoint, RBAC yields a strong ROI. Teams can self-serve: they create their own dashboards, alerts, and queries without bottlenecks. With RBAC and self-service in Kloudfuse, over 500 engineers at Innovaccer manage observability independently, eliminating the need for a central team. The burden on the central monitoring team dropped dramatically, allowing them to focus on infrastructure rather than providing hand-holding access. Over time, this speeds up issue resolution, lowers support costs, and increases adoption of the observability tools.

Looking ahead, scale your RBAC strategy as you grow. Continuously refine groups and policies, as new services may require new filters and new teams may form. Always pair growth with a review of roles and access. Kloudfuse’s architecture (including new features like stream-specific RBAC policies) is built to expand with you. With a solid RBAC framework in place, your multi-team observability deployment can be both secure and agile, allowing everyone to view the data they need without stepping on each other’s toes. Read more about Kloudfuse to get familiar, as starting out is as easy as a breeze.