27.8. Extended Example: Using Bundle Groups and Access Control within the Provisioning Process
Roles define interactions between different entities: resources (through resource groups), users, and bundles (through bundle groups). As Section 27.1.5, “Provisioning and Agent User System Permission” notes, with provisioning, these relationships breakdown along the lines of the different parts of the provisioning lifecyle: bundle/user relationships are most critical for creating bundle versions, while bundle/resource relationships are most critical for deploying bundles.
Roles can be layered; the access controls that are in effect are the cumulative rules for all roles which a user is assigned to. This means that if a single user belongs to multiple roles which each allow access to different resource groups, the user has access to all of the resource groups listed in those roles. The same is true for bundle groups.
This means that the resource groups and bundle groups defined in roles work in tandem to define the allowed provisioning paths for a user. Section 9.1.3, “Access and Groups” touches on this relationship. For instance, if a user belongs to one role which grants access to Resource Group A and another role which grants him access to Bundle Group B, the user can deploy the bundles in Bundle Group B to the resource in Resource Group A — but not other bundles or other resources.
This building-block approach to roles allws administrators to define very complex relationships between resources, bundles, and other users in very manageable ways.
Note
Limit the configuration of a single role as much as possible. It may be beneficial to use entirely separate roles for resource groups/permissions and bundle groups/permissions. This can make it more clear what access a particular role is granting and in what area, which makes it easier to maintain for users.
There are many different permutations of access controls for deploying bundles. The roles defining bundle permissions should echo and reinforce the provisioning workflow, following who creates bundles, who deploys bundles, and in what environments.
These examples outline simple, representative workflows. These can be adapted to the infrastructure, application lifecycle, and user groups within your organization.
27.8.1. Global v. Group Permissions for Creating and Deploying
Global bundle permissions grant the user access to all bundles on the system, regardless of associated groups.
The global view and create permissions allows the user to create bundles independent of bundle groups. The global deploy permission allows the user to deploy bundles to any resource groups that the user can view, even if they are not associated with the role.
Example 27.2. A User Deploys Bundles Anywhere
Role R1 <--- User U | v View Bundles Create Bundles Deploy Bundles
With global deploy permissions, the user must still have roles which define what resource groups the user can see. However, those resource groups do not need to be specified in the bundle role.
Group permissions restrict the given action to groups specified within the role itself. This is true for both bundle creation permissions (create bundles in group) and bundle deploy permissions (deploy bundles to resource group).
To restrict deployment to specified resource groups, use the deploy to group permission, which requires an explicit resource group in the role.
Example 27.3. Deploy Bundles to a Specific Resource Group: Single Role
Resource Group X ---> Role R <--- User U
^
|
View Bundles
Deploy Bundles To Group
The global permission view bundles allows the user to see any bundles on the system; it simply restricts the ability to deploy those bundles to a single resource group. The global permission could be set in a different, but the resource group must still be specified in the same role as the deploy bundles to group permission.
Example 27.4. Deploy Bundles to a Specific Resource Group: Two Roles
Resource Group X ---> Role R1 <--- User U --> Role R2
^ ^
| |
Deploy Bundles To Group View Bundles
27.8.2. Permissions and the Application Development Workflow
There are two parts to the application provisioning workflow: creating bundle versions in JBoss ON and then deploying those versions on selected resources.
Those two tasks can be divided between different groups within an organization. For example, a development group could created bundles, but the production group is responsible for deploying them. Or a QE lead could create the bundles in JBoss ON, while the QE team is responsible for deploying them to test systems.
While global deploy and create permissions can be set, more than likely, a real environment will restrict most users to actions within specified groups.
The first conceptual part is to create a permission that allows a user to create bundles in a specific group. A global permission to view all bundles can be set in a second role, since that permission could logically be applied to multiple users who all have different bundle groups to manage. (This falls uder the principle of keeping each single role as simple as possible.)
Example 27.5. Creating Bundles in a Specific Bundle Group
Bundle Group A ---> Role R1 <--- User U ---> Role R2
^ ^
| |
Create Bundles In Group View Bundles
If multiple team members are responsible for updating each others' bundles or of maintaining a community bundle, then those users can simply be added to the same create role for the given bundle group. This example also specifies a delete permission.
Example 27.6. Multiple Users Updating Each Others' Bundles
Bundle Group A
|
v
Role R1 <--- User U1, User U2, User U3
^
|
Create Bundles In Group
Delete Bundles From Group
This role arrangement is egalitarian, with each member of the role having equal rights over the other role users' bundles, within the same bundle group.
In many workflows, there will one person or set of people responsible for maintaining bundles, while another group is responsible for deploying those bundles. In that case, one group belongs to a role with create bundles in group permissions to a given bundle group, while a separate set of users belong to a role with deploy bundles to group permissions for that bundle group and a specified resource group.
Example 27.7. Team Lead Creates Bundles - Team Members Deploy Bundles
Bundle Group A Bundle Group A
| |
v v
Role R1 <--- User TeamLeader Resource Group X ---> Role R2 <--- Users TeamMember1, TeamMember2
^ ^
| |
Create Bundles In Group Deploy Bundles To Group
This arrangement divides the create and deploy aspects of the application provisioning cycle.
The arrangement of the users in separate roles and the division of the types of permissions is crucial. The same arrangement could be made with global permissions, rather than restricting either or both roles to a single bundle group or resource group, but that division of responsibility would still exist.
