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 StartCopy Anchor Link

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

TeamsCopy Anchor Link

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

Creating a TeamCopy Anchor Link

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

Team RolesCopy Anchor Link

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 StructureCopy Anchor Link

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

PermissionsCopy Anchor Link

Permissions control what actions users can perform.

Permission ModelCopy Anchor Link

Permissions are defined as:

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

Available ResourcesCopy Anchor Link

raw_data is the original object each collector reported for a CI, such as a pod spec with its environment values. Superadmins and members of a team holding * with the * action (the seeded Admins team) can read it. A team holding configuration_items:read (the seeded Viewers team), or * with only read, cannot. To let a team read source payloads without wider rights, grant it raw_data with read. Signed-in users without access see an explanation on the CI's Raw Data tab instead of the payload.

credentials follows the same rule. A team holding * with read, write and delete ticked one by one cannot open Settings → Credentials; grant it credentials with the actions it needs, or * with the * action.

Available ActionsCopy Anchor Link

Setting Team PermissionsCopy Anchor Link

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 SetsCopy Anchor Link

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 ScopesCopy Anchor Link

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

Scope ModelCopy Anchor Link

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 MatchingCopy Anchor Link

Setting Team ScopesCopy Anchor Link

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 ConfigurationsCopy Anchor Link

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 DefaultCopy Anchor Link

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.

Related CIs Outside a User's ScopeCopy Anchor Link

Views that follow relationships from a CI the user can see never show them a related CI outside their data scopes. That CI is left out entirely: no name, ID, type, source or score of it is sent to the browser, and any walk stops at it, so a CI the user can see that is reachable only through a hidden one is left out too. Each view shows a count instead:

A count still tells the user that hidden CIs exist next to a CI they can see, and comparing counts across filters or depths can narrow down where. That is an accepted cost of reporting counts. Users without data scope restrictions always see a count of zero, and the API returns the same counts in each response's hidden_neighbours field.

UsersCopy Anchor Link

User accounts are created automatically the first time someone signs in through your tenant's identity realm (JIT provisioning).

Managing UsersCopy Anchor Link

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

User PropertiesCopy Anchor Link

Direct PermissionsCopy Anchor Link

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

Direct Data ScopesCopy Anchor Link

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

Deactivating UsersCopy Anchor Link

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 AdminCopy Anchor Link

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

Audit LogCopy Anchor Link

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

Viewing the Audit LogCopy Anchor Link

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

ExportingCopy Anchor Link

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

Logged EventsCopy Anchor Link

Best PracticesCopy Anchor Link

Team DesignCopy Anchor Link

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 DesignCopy Anchor Link

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 DesignCopy Anchor Link

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

SecurityCopy Anchor Link

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

TroubleshootingCopy Anchor Link

User can't see any dataCopy Anchor Link

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 modifyCopy Anchor Link

Check their effective permissions:

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

Changes not taking effectCopy Anchor Link

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 superadminsCopy Anchor Link

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