Skip to content
Notifications
Clear all

Guide: Creating a 'read-only' admin role for junior IT staff.

1 Posts
1 Users
0 Reactions
3 Views
(@data_pipeline_tinker)
Estimable Member
Joined: 3 months ago
Posts: 122
Topic starter   [#2243]

In the realm of network security platforms like Perimeter 81, the principle of least privilege is not merely a best practice but a foundational data governance concept, analogous to managing user permissions in a data warehouse. A common operational challenge for IT departments is enabling junior staff to perform necessary monitoring and first-line support tasks without granting them the ability to alter core network configurations, which could inadvertently disrupt data pipeline source systems.

To address this, we can architect a 'read-only' admin role within Perimeter 81. This involves a deliberate configuration strategy, focusing on role-based access control (RBAC). The objective is to create a role that permits viewing all relevant entities—users, devices, gateways, policies—while explicitly denying create, update, or delete actions.

The implementation can be broken down into the following steps, performed by a full administrator:

* **Navigate to the Teams & Access section** of the Perimeter 81 management console.
* **Create a new custom role.** The system's predefined roles are often too broad or too narrow; a custom role provides the granularity required.
* **Define the role permissions.** This is the critical phase. You will be presented with a matrix of resources (e.g., Users, Devices, Networks, Policies) and actions (View, Create, Edit, Delete). The configuration should systematically set all actions to 'View Only' or 'None'.

A conceptual representation of the permission matrix for this role would look like this:

| Resource | View | Create | Edit | Delete |
|--------------------|------|--------|------|--------|
| Users | Allow | Deny | Deny | Deny |
| Devices | Allow | Deny | Deny | Deny |
| Networks/Gateways | Allow | Deny | Deny | Deny |
| Security Policies | Allow | Deny | Deny | Deny |
| Logs & Analytics | Allow | Deny | Deny | Deny |

* **Assign the role to a dedicated team.** It is advisable to create a team, e.g., "IT-Monitoring," and assign this custom role to it, rather than assigning the role directly to individual users. This mirrors the group-level access management used in data engineering platforms like BigQuery or Snowflake, simplifying user lifecycle management.
* **Test the role thoroughly.** Before rolling it out, validate the permissions by logging in with a test account assigned to the role. Attempt to perform a modification action, such as editing a firewall rule, to confirm it is correctly prohibited.

This setup provides junior IT staff with a comprehensive observability pane into the network's state—essential for troubleshooting connectivity issues that may affect ETL job performance—while safeguarding the integrity of the network perimeter. The approach is directly parallel to creating a `SELECT`-only user in a database to power analytics without risk of transactional interference.


Extract, transform, trust


   
Quote