Hello Community 🙂
I'd like to know what you think the best practice would be for using Boundaries and Policies in our customer's case.
Our customer recently moved from Managed to SAAS and previously could restrict users to specific Management Zones and permission levels. Today, we want to organize the users by "User Groups" with differing "Permissions" and "Policies" with "Boundaries". (We're using one environment in the account)
What do I mean by this?
1. Groups for permission levels - here we don't mind using the default policies for "Standard Users", "Pro Users", and "Admin Users".
2. Groups to differentiate between "team" access ranges that were (and are currently) filtered with existing Management Zones - Team1MZ, Team2MZ, etc.
Examples for users in our environment:
Team1Lead - Pro Users, Team1
Team1Members - Standard Users, Team1
Team2Lead - Pro Users, Team2
Team2Members - Standard Users, Team2
SpecialUser (Multi-team access) - Pro Users, Team1, Team2, etc.
Admin - Admin User (Access to everything and anything)
Each user has their permission level (standard, pro, or admin), and at least one more User Group for their selective team(s) access.
Since we're trying to avoid using "Roles" (as recommended in the documentation), what would be the best approach to this by utilizing Boundaries, Policies, and Groups?
*It seems as though Boundaries can be defined using "environment:management-zone startsWith "Team#";" , so it seems like less of an issue when it comes to defining Boundaries, but when it comes to applying them to Permissions I get lost.
Which do you think is the most correct approach to implement?
Option A- Create 2 Groups per Team:
- A single permission level (Team1Lead has "Pro Users" and Team1Members has "Standard Users") and restrict it with the team's access Boundary.
For example:
Group "Team1Lead", Permission "Pro User" with Boundary "Team1"
Group "Team1Member", Permission "Standard User" with Boundary "Team1"
*Is this correct enough for environment-wide use?
Option B- Create 2 Groups per Team:
- A single permission level (Standard User/Pro User) + a single "All-inclusive" Policy with *all* permission statements restricted by the team's access Boundary.
For example:
Group "Team1Lead", Permissions "Pro User" + "All-inclusive" (with Boundary "Team1")
Group "Team1Member", Permissions "Standard User" + "All-inclusive" (with Boundary "Team1")
*Does the Boundary on "All-inclusive" also restrict the user's permissions in this case?
Option C- Create 3 permission-level Groups, and another group per individual boundary:
- Each user gets grouped into exactly one appropriate permission-level, and (at least one) relevant teams.
For example:
Group "Standard Users"
Group "Pro Users"
Group "Admin Users"
Group "Team1", Permissions <all policy statements split into default policies, each with Boundary "Team1">
Group "Team2", Permissions <all policy statements split into default policies, each with Boundary "Team2">
Option D- Something else?
All in all, I think my question really boils down to:
When a user has duplicate policy statements through different Permissions (within a single Group, or multiple Groups), how do different Boundaries apply? Does it restrict access (intersection of rules)? Does it allow more access (union of rules)?
If a user is in the "Admin Users" group but also is in a group with only "View Logs" for Team1 Boundary, is the user an Admin or is the user only able to view Team1 logs?
Would love to hear your advice! 🙂
Thanks.
Asaf Axelrod
