RBAC Administration

This guide covers how to administer Role-Based Access Control (RBAC) in Parascope. You must be a superadmin to access these features.

Quick Start

1. Create teams that map to your organizational structure
2. Assign permissions to teams based on what they need to do
3. Set data scopes to control which infrastructure each team can see
4. Add users to teams as they log in

Teams

Teams are the primary way to manage access in Parascope. Users inherit permissions and data scopes from all teams they belong to.

Creating a Team

1. Go to Settings → Teams
2. Click Create Team
3. Enter a name and description
4. Click Create

Team Roles

Each team member has a role:

Team admins can manage their own team's membership. Only superadmins can change team permissions and scopes.

Recommended Team Structure

Organize teams by function or access needs:

Infrastructure Team
├── Permissions: configuration_items (read, write), collectors (read, write)
├── Data Scopes: kubernetes, proxmox, ceph
└── Members: Platform engineers

Application Team
├── Permissions: configuration_items (read)
├── Data Scopes: kubernetes
└── Members: Application developers

Operations Team
├── Permissions: configuration_items (read), collectors (read)
├── Data Scopes: all sources
└── Members: SRE, on-call engineers

Permissions

Permissions control what actions users can perform.

Permission Model

Permissions are defined as:

• Resource: What the permission applies to
• Actions: What operations are allowed

Available Resources

Available Actions

Setting Team Permissions

1. Go to Settings → Teams → select a team
2. Scroll to Permissions
3. Click Edit
4. Add or remove permission entries
5. Click Save

Example Permission Sets

Read-only access:

configuration_items: [read]
collectors: [read]
sources: [read]

Operator access:

configuration_items: [read, write]
collectors: [read, write]
sources: [read, write]

Full access (non-admin):

configuration_items: [read, write, delete]
collectors: [read, write, delete]
sources: [read, write, delete]
correlations: [read, write, delete]

Data Scopes

Data scopes control which CIs a user can see. This is Parascope's primary data isolation mechanism.

Scope Model

Scopes are defined by:

• Source: The data source type (kubernetes, proxmox, ceph, netbox, openstack)
• Scope ID: A specific cluster or instance within that source

Scope Matching

Setting Team Scopes

1. Go to Settings → Teams → select a team
2. Scroll to Data Scopes
3. Click Edit
4. Add or remove scope entries
5. Click Save

Example Scope Configurations

Infrastructure team (all sources):

source: null, scope_id: null  (full access)

Kubernetes-only access:

source: kubernetes, scope_id: null

Single cluster access:

source: kubernetes, scope_id: production
source: kubernetes, scope_id: staging

Multi-source limited access:

source: kubernetes, scope_id: production
source: proxmox, scope_id: pve-cluster-1

Deny by Default

If a user has no data scopes (directly or via teams), they see no CIs. This is the "deny by default" model.

To give a user access to everything, add a scope with source: null, scope_id: null.

Users

User accounts are created automatically when users first log in via SSO (JIT provisioning).

Managing Users

1. Go to Settings → Users
2. Use search to find users by email or name
3. Click a user to view/edit details

User Properties

Direct Permissions

You can assign permissions directly to a user (bypassing teams). This is useful for special cases but teams are preferred for maintainability.

Direct Data Scopes

Similarly, you can assign data scopes directly to a user.

Deactivating Users

Deactivating a user:

1. Prevents them from logging in
2. Immediately revokes all active sessions
3. Immediately revokes all API tokens

The user's data and audit trail are preserved.

Bootstrap Admin

The first superadmin is configured during your Parascope onboarding. When the designated administrator first logs in via SSO, they automatically become a superadmin. This user can then create additional superadmins and configure the system.

Audit Log

All security-related events are logged to the audit log.

Viewing the Audit Log

1. Go to Settings → Audit Log
2. Use filters to narrow results:
   • Event type
   • User
   • Date range
   • IP address

Exporting

Click Export CSV to download the audit log for external analysis or compliance reporting.

Logged Events

Best Practices

Team Design

1. Map teams to responsibilities: Infrastructure, applications, security, etc.
2. Start restrictive: Give minimum necessary access
3. Use team admins: Delegate team membership management
4. Document team purposes: Use descriptions to explain what each team is for

Permission Design

1. Prefer teams over direct permissions: Easier to audit and maintain
2. Group related permissions: Users who need to manage collectors probably also need to manage sources
3. Separate read and write: Not everyone who can view should be able to modify

Scope Design

1. Organize by environment: production, staging, development
2. Organize by domain: infrastructure, applications, databases
3. Be specific: Prefer specific scopes over full access
4. Review regularly: Ensure scopes still match organizational needs

Security

1. Limit superadmins: Only give superadmin to users who truly need it
2. Review audit logs: Check for unusual activity regularly
3. Rotate tokens: Encourage users to rotate tokens periodically
4. Deactivate promptly: Deactivate users when they leave or change roles

Troubleshooting

User can't see any data

Check their effective scopes:

1. Go to Settings → Users → select user
2. Review their teams and direct scopes
3. Ensure at least one scope grants access to the expected source

User can see data but can't modify

Check their effective permissions:

1. Review their teams' permissions
2. Ensure they have write action on the relevant resource

Changes not taking effect

Permissions and scopes are evaluated on each request. If changes aren't working:

1. Have the user log out and back in
2. Check that the team is active
3. Check that the user is active in the team

Locked out superadmins

If all superadmins are locked out, contact your Parascope administrator or support to restore access.