9.4. Extended Example: View All Resources, Edit Some Resources
For security and for management practices, access should be limited to what is necessary for a given user. Security starts at restricting access as the default and then explicitly granting defined rights (read, modify, delete) to specific resources.
While it is possible to create a set of access control rules which define everything that is required for a user (or set of users), these rules in practice are cumbersome, complicated, and easily outdated or inaccurate. Access controls are a definition of a relationship; frequently, the different relationships that a user has are too complex to be defined in a single role.
The effect of roles is cumulative. The total level of access for a user is the sum of all of the roles they belong to — access to resources in all of the specified resource groups, the permissions granted to those roles.
Because the effects are cumulative, it is most effective to design access controls in a layered way, using small roles that define a very specific set of access and then adding those roles to users incrementally.
This layered approach allows administrators to define and effectively maintain complex relationships, both at a macro-level along personnel and infrastructure divisions and at a micro-level with different relationships to and between different resources.
The Setup
Example Corp. has three major groups associated with its IT infrastructure: development, QE, and production. Each group requires information from the other teams to help maintain their configuration, manage performance settings, and roll out new applications, but they should only be able to manage their own systems.
Within each group, there are two separate application management tasks: updating and deploying new versions of the application and managing system configuration for optimal performance.
The Plan
Tim the IT Guy first defines the different relationships that need to be expressed within the access controls:
- Everyone needs to be able to view performance data for all stacks within the infrastructure.
- The individual divisions need write access to their own systems.
- At least some administrators within each group require the ability to update system configuration.
- At least some administrators within each group require the ability to create and deploy bundles to manage applications within their own groups.
The first step is to define the required groups, with the minimum required resources in each group. In a simplified structure:
- A mixed group which contains all of the resources within each given stack environment. The stacks include platforms, Postgres databases, EAP servers, web contexts, and other resources used to manage the production environment.This results in three groups: Dev Stack, QE Stack, and Production Stack.
- An "all stacks" nested group which includes all three stack groups.This group is not for all resources — it only includes the stack groups, excluding JBoss ON-related resources and other managed resources not relevant to those stacks.
- Since these environments include application development, each organization also requires its own bundle group to maintain deployments.
- There has to be a mechnism to promote bundles between environments. Tim the IT Guy creates "Promote Bundles" group where bundles can be added when they are ready to be moved into a different environment.
Each of the resource and bundle groups could be broken down, if different users within the same division require different levels of access to individual resources.
Then, different users require different kinds of access. Tim the IT Guy then maps the different permissions that are required:
- View-only rights to all resources, including configuration view-only rights
- Edit rights to resources within the stacks for monitoring, alerts, drift, operations, and inventory
- Edit rights to resources within the stacks for configuration
- View bundle rights within the stacks
- Create and deploy bundle rights within the stacks
There are essentially three types of users within each functional group:
- Regular users
- Administrators which manage resource configuration
- Administrators which can create (promote) bundles between groups
The roles are going to corrspond to each resource and bundle group with permissions set for the minimal requirements for that group (local view and edit). For the administrators, the additional permissions — configuration and promoting content — are going to be added by creating additional roles with only the additional permissions.
For a regular user, he adds roles for all resources and bundles and resources within his stacks.
Dev Stack
Bundle Group
|
Role BG1
|
V
Regular Joe
^ ^
| |
Role RG1 Role RG2
| |
"All Stack" Dev Stack
Resource Resource
Group Group
For the "All Stack" role, he adds read-only permission for all inventory areas and configuration.
^
|
Role RG1 <------Permissions
| |
"All Stack" View.alerts
Resource View.inventory
Group View.measurements
View.etc...
View.configuration
For the stack group, Tim the IT Guy sets permissions to edit every functional area (measurements, alerts, operations, events) except for configuration, which is reserved for administrator users. The resource group also includes the permission to deploy bundles to the resources in the group. The ability to deploy bundles is separate from the ability to create bundles.
^
|
Role RG2 <------Permissions
| |
Dev Stack Edit.alerts
Resource Edit.inventory
Group Edit.measurements
Edit.etc...
Deploy.bundles
Last, he adds permissions to view and create bundles within the regular user's bundle group.
Dev Stack
Bundle Group
|
Role BG1 <-----Permissions
| |
V View.bundles
Create.bundles
In this configuration, an administrator has two extra tasks: managing resource configuration within their stacks and promoting bundles to the next work group. The administrator is added to all of the roles of the regular user, plus additional roles for the additional tasks.
Tim the IT Guy creates one additional role to define the configuration permission. This grants configuration editing only to resource groups the administrator can see (the ones in his work groups).
"Regular Joe" roles
|
V
Group Lead <------Role RG3
|
Permissions
|
Edit.configuration
Last, each administrator is added to the role for each bundle group. The bundle group roles only grant access to the bundle group to create content, not to view, deploy, or delete it. This allows administrators to promote content between work groups, but not to deploy it or affect resource configuration.
Dev Stack Permission:
Bundle Group Create.Bundles
\ /
\ /
Role BG1
|
V
Role BG2 ----> Group Lead <---- Role BG3
/ \ / \
/ \ / \
QE Stack Permission: Prod Stack Permission:
Bundle Group Create.Bundles Bundle Group Create.BundlesThe Result
Users within each group are granted access to view whatever performance and configuration information they need, but they can only make changes to resources within their specified group. Only administrators within each group can make configuration changes.
Application deployment is limited within each functional area (development, QE, and production). Specific administrators which are allowed to create content in other groups, but not to deploy it.
