Roles and Permissions

Roles and Permissions: Role-Based Access Control (RBAC) in rConfig V8

Role-Based Access Control (RBAC) in rConfig V8 provides granular control over user permissions, addressing the challenge of securing multi-user environments where different personnel require varying levels of access to sensitive network configuration data. Organizations can leverage RBAC to implement least privilege access, enforce segregation of duties, and maintain audit trails of who can perform which operations.

RBAC restricts network access based on the roles of individual users within an enterprise. Rather than assigning permissions individually to each user, administrators define roles with specific permission sets and assign users to those roles. This scalable approach simplifies permission management, ensures consistency across user groups, and adapts easily as organizational needs evolve.

Understanding RBAC Concepts

Roles

Roles are named collections of permissions that define what actions users can perform within rConfig. Each role represents a job function or responsibility level, grouping related permissions logically. Users assigned to a role automatically inherit all permissions associated with that role.

Benefits of role-based permissions:

• Simplified management: Assign one role instead of dozens of individual permissions
• Consistency: All users in the same role have identical access
• Scalability: Add new users by assigning existing roles without permission configuration
• Audit clarity: Easily identify what any user can do by checking their role
• Reduced errors: Less granular permission assignment reduces misconfiguration risk

Permissions

Permissions define specific operations users can perform on system entities. rConfig implements five standard permission types applied to each entity:

View: Ability to see entity listings and navigate to entity pages. Without View permission, users cannot access the entity section at all.

Create: Ability to add new entity instances. For example, Create permission on Devices allows adding new devices to inventory.

Read: Ability to view detailed information about entity instances. Distinct from View which shows listings, Read shows full details of individual items.

Update: Ability to modify existing entity instances. Update permission on Commands allows editing command definitions.

Delete: Ability to remove entity instances. Delete permission on Tags allows removing tags from the system.

All: Convenience toggle that enables or disables all five permission types simultaneously for an entity.

Entities

Entities represent the major functional areas and data types within rConfig. Permissions are assigned per-entity, allowing fine-grained control. Key entities include:

Core infrastructure:

• Device: Network devices managed by rConfig
• DeviceCredentials: Authentication credentials for devices
• Vendor: Device manufacturer definitions
• Tag: Organizational labels for categorizing resources

Configuration management:

• Config: Downloaded device configurations
• ConfigChange: Configuration change tracking and history
• Command: Command definitions for device interaction
• Category: Command grouping and organization
• Snippet: Configuration templates and snippets

Compliance and policy:

• PolicyDefinition: Compliance policy rules and logic
• PolicyAssignment: Assignment of policies to devices
• PolicyComplianceResult: Compliance check outcomes
• PolicyComplianceReport: Aggregated compliance reporting

Automation and integration:

• Task: Scheduled and manual task definitions
• Taskdownloadreport: Task execution results and logs
• Template: Configuration templates
• TrackedJob: Background job tracking

System administration:

• User: User account management
• Role: Role and permission management
• Permission: Permission definitions
• Setting: System configuration settings
• Backup: System backup operations
• ActivityLog: Application event logging
• UserLogActivity: User authentication and activity

API and integrations:

• RestApiToken: API authentication tokens
• RestApiLog: API request logging
• ApiConnection: External API connection definitions
• ApiCredential: API authentication credentials
• ApiEndpoint: API endpoint configurations

Advanced features:

• Ldap: LDAP authentication configuration
• Zabbix: Zabbix integration settings
• ZabbixExtractStaging: Zabbix data import staging
• IntegrationConfigured: Active integration configurations
• IntegrationOption: Integration configuration options
• IntegrationDeviceLoaderStaging: Device import staging

Note

The entity list reflects rConfig V8 and is subject to expansion as new features are introduced. Custom integrations or plugins may add additional entities to the permission system.

Predefined System Roles

rConfig V8 includes three predefined system roles covering common access patterns:

Admin Role

The Admin role provides complete system access including all administrative capabilities:

Permissions: Full access (View, Create, Read, Update, Delete) to all entities

Typical use cases:

• System administrators managing rConfig infrastructure
• Senior network engineers with full operational authority
• Security personnel requiring complete visibility for auditing
• Implementation consultants during deployment phases

Responsibilities:

• User and role management
• System configuration and settings
• Integration setup and maintenance
• Backup and disaster recovery operations
• Security monitoring and incident response

Caution

Limit Admin role assignment to personnel genuinely requiring full system access. Excessive admin accounts increase security risk and complicate audit trails. Most operational users should receive User or custom role assignments instead.

User Role

The User role provides standard operational access for network configuration management tasks:

Permissions: Full access to operational entities (devices, configurations, commands, compliance), restricted access to administrative entities (cannot manage users, roles, system settings)

Typical use cases:

• Network engineers performing daily configuration management
• Operations staff downloading and reviewing configurations
• Compliance analysts running policy checks and reviewing results
• Team leads managing device inventory and task scheduling

Limitations:

• Cannot create or modify user accounts
• Cannot change role definitions or permissions
• Cannot modify system-wide settings
• Cannot access sensitive integration credentials
• Cannot execute system backups or restore operations

Guest Role

The Guest role provides read-only access for visibility without modification capabilities:

Permissions: View and Read access to most entities, no Create, Update, or Delete permissions

Typical use cases:

• Management personnel reviewing compliance status
• Junior team members observing operations before full access
• Auditors examining configuration management processes
• External consultants requiring visibility without modification rights
• Cross-functional teams needing network configuration insights

Limitations:

• Cannot modify any data or configuration
• Cannot download configurations or execute commands
• Cannot schedule tasks or execute operations
• Cannot access administrative functions
• Ideal for reporting and monitoring purposes only

System Role Characteristics

System roles (Admin, User, Guest) are hardcoded and cannot be deleted. Administrators can deactivate system roles to prevent assignment to new users, but existing users retain their roles. Deactivating the Admin role is not recommended as it may leave the system without administrative access.

To view system role permissions:

1. Navigate to Roles from the main navigation
2. Locate the role to examine
3. Click the three-dot menu icon
4. Select Edit
5. Review the permission matrix showing all entity permissions

Creating Custom Roles

Custom roles enable organizations to define permission sets aligned with specific job functions, operational requirements, or security policies not covered by predefined roles.

When to Create Custom Roles

Consider custom roles in these scenarios:

Specialized job functions: Teams with unique responsibilities requiring specific permission combinations (e.g., compliance-only analysts, configuration auditors, vendor management coordinators).

Segregation of duties: Compliance frameworks requiring separation of responsibilities (e.g., users who create policies cannot approve them, users who configure devices cannot manage credentials).

Geographic or organizational divisions: Different regions or business units requiring distinct access patterns based on operational scope.

Least privilege enforcement: Standard roles provide more access than needed, and custom roles restrict to minimum necessary permissions.

Third-party integration: External systems or services requiring API access with limited scope to specific entities and operations.

Creating Custom Roles

To create a new custom role:

1. Navigate to Roles from the main navigation
2. Click New Role
3. Complete the role definition form:
   • Role Name: Descriptive identifier (e.g., “Compliance Analyst”, “Read-Only Network Engineer”)
   • Description: Detailed explanation of role purpose and intended users
   • Status: Active (default) or Inactive for staged roles not yet ready for assignment
4. Configure permissions using the permission matrix:
   • Entity rows: Each row represents a system entity
   • Permission columns: All, View, Create, Read, Update, Delete
   • Toggle All: Convenience switch enabling/disabling all permissions for the role
   • Individual toggles: Select specific permissions per entity
5. Click Save to create the role

The new role becomes immediately available for user assignment.

Permission Matrix Strategy

When configuring custom role permissions, use these strategies:

Start with minimum access: Begin with no permissions and add only those required. This ensures least privilege by default.

Grant View broadly, other permissions selectively: Most roles benefit from broad View access for situational awareness, with Create/Update/Delete restricted to operational areas.

Consider permission dependencies: Some operations require multiple permissions. For example, running compliance checks requires Read access to Devices, PolicyDefinitions, and PolicyAssignments.

Test role thoroughly: Create test user accounts with the custom role and validate they can perform intended operations without accessing restricted areas.

Document permission rationale: Maintain internal documentation explaining why each permission was granted, facilitating future reviews and audits.

Custom Role Examples

Compliance Analyst Role:

• Full access: PolicyDefinition, PolicyAssignment, PolicyComplianceResult, PolicyComplianceReport
• Read access: Device, Config, Vendor, Tag
• View access: All other entities
• Rationale: Analysts create and manage policies, review compliance, but don’t modify device configurations

Configuration Auditor Role:

• Full Read access: Config, ConfigChange, Device
• View access: All other entities
• No Create, Update, or Delete permissions
• Rationale: Auditors review configurations and changes without modification capabilities

Device Manager Role:

• Full access: Device, DeviceCredentials, Tag, Vendor
• Read access: Config, Task
• View access: All other entities
• No access: PolicyDefinition, Setting, User, Role
• Rationale: Manages device inventory and credentials without policy or system administration access

Assigning Roles to Users

User Role Assignment

Each user is assigned exactly one role determining their system permissions. To assign or change a user’s role:

1. Navigate to Users from the main navigation
2. Locate the user to modify
3. Click the three-dot menu icon in the user row
4. Select Change Role
5. A dialog displays showing the current role
6. Select the new role from the dropdown
7. Click Save to apply the change

Role changes take effect immediately for new sessions. Users currently logged in should log out and back in to activate new permissions.

Role Assignment Considerations

Single role assignment: Users can have only one role at a time. Permissions from that role apply comprehensively. If a user requires permissions from multiple roles, create a custom role combining necessary permissions.

Role change impact: Changing a user’s role immediately affects their access. Ensure role changes align with actual job function changes to prevent operational disruption.

Temporary elevated access: For temporary administrative needs, consider creating time-limited admin accounts rather than elevating existing user accounts and remembering to downgrade later.

Review role assignments regularly: Quarterly access reviews should validate each user’s assigned role remains appropriate for their current responsibilities.

Entity-Level Role Restrictions

Device and Snippet Role Assignment

Beyond system-wide role permissions, rConfig V8 supports entity-level role restrictions for Devices and Snippets. This provides additional granularity by limiting which devices or snippets specific roles can access.

How entity-level restrictions work:

1. Assign roles to specific devices or snippets during creation or editing
2. Users with those roles see only devices/snippets where their role is assigned
3. Users without assigned roles see no devices/snippets (unless they have Admin role)
4. Admin role bypasses entity-level restrictions and sees all devices/snippets

Use cases for entity-level restrictions:

Multi-tenant environments: Service providers managing customer devices can restrict each customer’s operations team to only their devices.

Geographic segmentation: Regional teams see only devices in their geographic responsibility area.

Vendor-specific teams: Cisco specialists see Cisco devices, Juniper specialists see Juniper devices, preventing cross-vendor configuration errors.

Sensitive device isolation: High-security devices (production core routers, firewalls) restricted to senior engineers, while access switches visible to junior staff.

Snippet library organization: Configuration snippets organized by team, with each team accessing only their approved templates.

Configuring Entity-Level Role Restrictions

For Devices:

1. Navigate to device creation or edit form
2. Locate the Assigned Roles section
3. Select one or more roles that should access this device
4. Save the device
5. Only users with assigned roles (plus Admins) can now view/manage this device

For Snippets:

1. Navigate to snippet creation or edit form
2. Locate the Assigned Roles section
3. Select one or more roles that should access this snippet
4. Save the snippet
5. Only users with assigned roles (plus Admins) can now view/use this snippet

For detailed entity-level role assignment procedures, see:

• Device Management Documentation
• Snippet Management Documentation

Managing Roles

Viewing Role Details

To examine role configurations:

1. Navigate to Roles from the main navigation

2. The role list displays all roles with:

   • Role Name: Identifier for the role
   • Description: Purpose and intended use
   • Status: Active or Inactive
   • Assigned Users: Count of users currently assigned to the role
   • Actions: Edit, deactivate, or delete options

3. Click the role name or Edit icon to view full permission matrix

Editing Role Permissions

To modify existing role permissions:

1. Locate the role in the Roles list
2. Click the three-dot menu icon
3. Select Edit
4. Modify the permission matrix:
   • Toggle individual permissions per entity
   • Use Toggle All to quickly enable/disable all permissions
   • Update role name or description if needed
5. Click Save to commit changes

Permission changes affect all users assigned to the role immediately. Users logged in when permissions change must log out and back in for new permissions to apply.

Caution

Exercise caution when modifying roles with many assigned users. Permission reductions may disrupt ongoing operations for multiple users simultaneously. Consider creating new roles with desired permissions and migrating users gradually instead of modifying active roles.

Deactivating Roles

To prevent new assignments while preserving existing ones:

1. Navigate to Roles
2. Locate the role to deactivate
3. Click the three-dot menu icon
4. Select Deactivate

Deactivated roles:

• Cannot be assigned to new users
• Remain assigned to existing users with full permissions intact
• Remain visible in the roles list with “Inactive” status
• Can be reactivated at any time

Use deactivation when phasing out roles, temporarily suspending role use, or preventing accidental assignment during role redesign.

Deleting Custom Roles

To permanently remove custom roles:

1. Navigate to Roles
2. Verify no users are assigned to the role (Assigned Users column shows 0)
3. Click the three-dot menu icon
4. Select Delete
5. Confirm deletion when prompted

Caution

Roles with assigned users cannot be deleted. Reassign all users to different roles before deletion. System roles (Admin, User, Guest) cannot be deleted under any circumstances.

Deleted roles are permanently removed and cannot be recovered. Document role permissions before deletion if you may need to recreate similar roles later.

Troubleshooting

Symptom: User Cannot Access Expected Features

Diagnosis: Verify user’s role and required permissions.

Possible Causes:

• User assigned role lacking necessary permissions
• Entity-level role restrictions preventing access to specific devices/snippets
• Session established before recent permission changes
• User attempting to access admin features without admin role

Resolution Steps:

1. Verify user’s assigned role in Users list
2. Check role permissions match required operations
3. If entity-level restrictions apply, verify user’s role is assigned to relevant devices/snippets
4. Have user log out and back in to refresh session permissions
5. Assign different role or modify role permissions if access is legitimately required

Symptom: Custom Role Cannot Be Deleted

Diagnosis: Verify role has no assigned users.

Possible Causes:

• Users still assigned to the role
• Database constraint preventing deletion
• Attempting to delete system role (not possible)

Resolution Steps:

1. Check Assigned Users column for the role
2. If count > 0, identify assigned users via Users list
3. Reassign all users to different roles
4. Verify Assigned Users shows 0
5. Retry deletion
6. If system role, use deactivation instead as deletion is not possible

Symptom: Permission Changes Not Taking Effect

Diagnosis: User sessions cache permissions requiring refresh.

Possible Causes:

• User logged in when permissions changed
• Browser caching old permission state
• Application cache not cleared after permission changes
• Database replication lag in distributed deployments

Resolution Steps:

1. Have affected users log out completely
2. Clear browser cache and cookies
3. Log back in to establish new session with updated permissions
4. If issue persists, clear application cache:

   php /var/www/html/rconfig8/current/artisan config:clear
   php /var/www/html/rconfig8/current/artisan cache:clear

5. Review System Logs for permission-related errors

Symptom: RBAC Data Appears Corrupted

Diagnosis: Permission table may need refresh or repair.

Possible Causes:

• Database corruption affecting permissions table
• Incomplete migration after rConfig upgrade
• Manual database modifications introducing inconsistencies
• Disk failure or filesystem issues

Resolution Steps:

Caution

Contact rConfig support before executing RBAC data refresh commands. These commands modify permission structures and should only be run under guidance to prevent unintended access changes.

1. Document current role configurations and user assignments
2. Create complete database backup
3. Contact [email protected] with issue description
4. Support will provide guidance on executing:

   php /var/www/html/rconfig8/current/artisan rconfig:update-rbac-data

5. Verify role permissions after refresh
6. Reapply any custom role configurations if needed

Best Practices

Security

Apply least privilege principle: Assign the minimum role necessary for users to perform their job functions. Default to User or custom roles rather than Admin unless administrative access is genuinely required.

Limit Admin role assignments: Maintain a small, well-documented list of admin users. Every additional admin increases security risk and complicates audit trails.

Review role assignments quarterly: Conduct regular access reviews to identify role assignments that no longer align with job responsibilities. Downgrade or remove access proactively.

Document role purpose: Maintain clear documentation of each custom role’s purpose, intended users, and permission rationale. This facilitates reviews and knowledge transfer.

Implement segregation of duties: Use custom roles to enforce separation of responsibilities required by compliance frameworks (e.g., policy creators cannot approve policies).

Audit permission changes: Monitor the ActivityLog for role creation, modification, and deletion events. Unauthorized permission changes indicate potential security incidents.

Organization

Use descriptive role names: Name roles after job functions or responsibilities rather than departments. “Compliance Analyst” is clearer than “Team B Member” and remains valid through organizational changes.

Create role hierarchies logically: Design custom roles that build upon each other (e.g., Junior Engineer, Senior Engineer, Lead Engineer) with incremental permission additions at each level.

Standardize role definitions: Establish organizational standards for common roles (e.g., all regional deployments use identical role definitions) to simplify management and user transfers.

Test custom roles before production use: Create test user accounts with new custom roles and validate they can perform intended operations before assigning to production users.

Maintain role documentation: Document which teams use which roles, typical user counts, and escalation procedures for access requests. Store this documentation in accessible locations for operations teams.

Compliance

Map roles to job descriptions: Align role definitions with formal job descriptions and responsibility matrices. This demonstrates access controls match organizational structure for auditors.

Retain role change history: Maintain detailed records of role creation, modification, and deletion including business justification, approval authority, and implementation date.

Generate role assignment reports: Produce quarterly reports of all users, assigned roles, and last login dates for compliance audits and management review.

Implement role approval workflows: Establish formal procedures for requesting custom role creation including business justification, security review, and approval requirements.

Document exception access: When users require temporary elevated access, document the business justification, approval authority, duration, and removal date for audit trails.

Related Documentation

• Users - User account management and role assignment
• SSO Configuration - Single Sign-On integration with role mapping
• LDAP Configuration - LDAP authentication with role assignment
• Application Log - Viewing role and permission change events
• Device Management - Entity-level role assignment for devices
• Snippet Management - Entity-level role assignment for snippets

Summary

Role-Based Access Control in rConfig V8 provides the foundation for secure multi-user environments through predefined and custom roles, granular permission management, and entity-level access restrictions. Organizations can leverage RBAC to implement least privilege access, enforce segregation of duties, and maintain comprehensive audit trails of who can perform which operations.

Key takeaways for effective RBAC implementation:

• Use predefined roles (Admin, User, Guest) for common access patterns to simplify management
• Create custom roles when job functions require specific permission combinations not covered by predefined roles
• Apply least privilege by assigning minimum necessary permissions and restricting Admin role to genuine administrators
• Leverage entity-level restrictions for devices and snippets when multi-tenant or geographic segmentation is required
• Review role assignments quarterly to ensure access remains aligned with current job responsibilities

Effective RBAC implementation balances security with operational efficiency, enabling authorized personnel to perform their duties while preventing unauthorized access to sensitive network configuration management capabilities. Regular review and refinement of role definitions ensures the permission model evolves with organizational needs.