Security Model for Bundle Provisioning

Security Model

RHQ provides a fine-grained security model for bundle provisioning. The same role-based authorization is used as with RHQ in general, with a set of global permissions and a set of group-level permissions controlling a user's provisioning capabilities.

Global bundle permissions typically allow users to perform actions across all bundles and group-level permissions restrict a user to operating on bundles for only the groups associated with the relevant role.

Whereas RHQ's typical group-level resource permissions are applied to resources in resource groups associated with a user's roles, group-level bundle permissions are applied to bundles in bundle groups associated with the role. Whereas resource groups have resource members, bundle groups have bundle members.

The fine-grained permission model was introduced in RHQ 4.9. Prior versions had a single global permission, Manage Bundle. The Manage Bundle permission still exists and is backward compatible.

Bundle Groups

Applying fine-grained security permissions to bundle provisioning required adding a new concept to the security model: bundle groups. Similar to resource groups, bundle groups will allow RHQ to apply user permissions to a set of bundles.

The long-standing RHQ security model surrounding resources looks like this:

RESOURCE GROUPS ---> ROLES <--- USERS
                       ^
                       |
                  permissions

An RHQ admin can define a role (which has certain permissions enabled, like Manage Inventory, Control, Configure Write, et. al.). If a permission is a global permission, it does not involve resource groups; rather, it takes affect globally (e.g. Manage Inventory). If a permission is a resource permission (e.g. Control), it is restricted in that it applies only for resources found in resource groups assigned to the role that provides the permission.

What this means for the new Deploy Bundles To Group permission (which will be described below) is that it restricts the user to only deploy viewable bundles to authorized resource groups.

If we want to allow for a user to deploy a viewable bundle to an authorized resource group, two things need to be true:

The user needs a role associated with a bundle group having the bundle as a member. This association makes the bundle viewable by the user. (It implicitly grants the View Bundles In Group permission for bundles in the bundle group.)

The user needs a role associated with the target resource group and the role must be granted Deploy Bundles To Group permission

Note that this can involve multiple roles, one associated with the resource group, and one associated with the bundle group. The model looks like this:

                  BUNDLE GROUPS
                       |
                       v
RESOURCE GROUPS ---> ROLES <--- USERS
                       ^
                       |
                  permissions

Associating with a Role

Like resource groups, only a user with Security Manager permission can associate bundle groups with a role.

Bundle assignment

A bundle can be assigned to multiple bundle groups. Like a resource assigned to multiple resource groups, the assignment is a reference, not a copy. Just as the same resource can be assigned to zero or more resource groups, the same bundle can be assigned to zero or more bundle groups. Changes to a bundle, like a new bundle version, or deletion of a bundle, are reflected in all of its assigned bundle groups.

A bundle is made up of its bundle versions. The addition or removal of a bundle version is reflected in all bundle groups in which the bundle is associated. Put differently, it is not possible to have different bundle versions of a bundle in different bundle groups.

Unassigned Bundles

Not every bundle must be assigned to a bundle group. Unassigned bundles are those not assigned to any bundle group. They can be manipulated by users granted with certain global bundle permissions. This can be useful when applying a lighter security model, or as a staging area for bundles, prior to being assigned to bundle groups.

Note that if an assigned bundle is unassigned from its last bundle group, it will join the unassigned bundles, it is not deleted.

Fine-Grained Bundle Permissions

Global Permissions

Manage Bundle

This permission has existed since bundle provisioning was introduced. It allows a user to perform any bundle task and is useful when fine-grained security is not required. With the introduction of fine-grained bundle permissions this is now a convenience permission only and is not used for authorization checks. Instead, when granted, it in turn grants all other global bundle permissions.

This permission grants:
- Manage Bundle Groups
- Create Bundles
- Delete Bundles
- Deploy Bundles
- View Bundles

Manage Bundle Groups

This permission allows bundle group create and delete.
This permission allows any bundle to be assigned to any bundle group.
This permission allows any bundle to be unassigned from any bundle group.
This permission grants:
- View Bundles

Note that only users with Security Manager permission can associate bundle groups with roles.

Create Bundles

This permission allows bundle creation in any viewable bundle group.
- This includes the initial bundle version or subsequent bundle versions.
This permission allows any viewable bundle to be assigned to any viewable bundle group.

When creating an initial bundle version the newly created bundle must be viewable by the creator. If the user has View Bundles permission the new bundle can be left unassigned, otherwise the new bundle MUST BE assigned to a bundle group associated with the user's roles.

Non-initial bundle version creation can be performed only on the user's viewable bundles. The new version will be viewable via any bundle groups for which the bundle has been previously assigned.

Delete Bundles

This permission allows deletion of any viewable bundle.
This permission allows deletion of any viewable bundle version.
This permission allows any viewable bundle to be unassigned from its bundle group.

Bundle deletion removes everything related to a bundle, so it will no longer be present in any way.

Bundle version deletion removes everything related to only that bundle version. The Bundle will still exist. The bundle version removal is reflected in all bundle groups for which the bundle is assigned.

Deploy Bundles

This permission allows deployment of any viewable bundle version to any viewable resource group.
- The target resource group must be valid for bundle deployment (compatible group for a resource type supporting bundle deployment).

View Bundles

This permission allows view of any bundle.
- This includes unassigned bundles.

Bundle Permissions

Create Bundles In Group

This permission allows bundle creation in bundle groups associated with the role.
This permission allows any viewable bundle to be assigned to bundle groups associated with the role.
- This includes the initial bundle version or subsequent bundle versions.

Initial bundle versions must be assigned to a bundle group for which the user holds this permission. Subsequent bundle versions will be viewable via any bundle group for which the bundle has been assigned.

Delete Bundles In Group

This permission allows bundle deletion from bundle groups associated with the role.
This permission allows any viewable bundle to be unassigned from bundle groups associated with the role.

Bundle deletion removes everything related to a bundle, so it will no longer be present in any way.

Assign Bundles To Group

This permission allows any viewable bundle to be assigned to bundle groups associated with the role.

Unassign Bundles From Group

This permission allows any viewable bundle to be unassigned from bundle groups associated with the role.

If this was the last bundle group for which the bundle was assigned, it becomes an unassigned bundle.

Deploy Bundles To Group

This permission allows deployment of any viewable bundle version to resource groups associated with the role.
- The target resource group must be valid for bundle deployment (compatible group for a resource type supporting bundle deployment).

Although considered a bundle permission this permission could be considered a resource group permission. It provides authorization to deploy bundles to only specific resource groups. The user can deploy any viewable bundle, not just those assigned to bundle groups associated with this role.

View Bundles In Group

This permission allows view of bundles assigned to bundle groups associated with the role.

This is an implied permission. A user can always view bundles assigned to bundle groups associated with the role.

Creating Bundles

There is a distinction to be made when creating an initial bundle version (that is, creating bundle version "1.0" where the bundle itself is also created) and when uploading a new bundle version for an existing bundle (e.g. uploading bundle version "2.0"). That table below shows what is allowed when creating an initial version.

The View Bundles In Group column represents whether the user can view bundles in at least one bundle groups. In other words, is there at least one bundle group associated with one of his roles.

Initial Bundle [Version] Creation

Create Bundles	View Bundles	Create Bundles In Group	View Bundles In Group	→	Can Be Unassigned	Can Be Assigned	Additional Comments
	N/A		N/A	→			No create is possible.
				→			Can't create until some sort of view permission is granted.
				→			Initially assigned to an associated bundle group.
	N/A		N/A	→			Newly created bundles must be assigned to a bundle group associated with the role.
		N/A	N/A	→			Can be unassigned, or assigned to any bundle group. Create Bundles In Group and View Bundles In Group are irrelevant.

When creating a new bundle version for an existing bundle the rule is simple. There are no changes to bundle assignment. The new bundle version will be viewable by the same users that could formerly see the bundle.

Deleting Bundles

Analogous to creating bundles, this table shows the permissions needed to delete bundles:

Delete Bundles	View Bundles	Delete Bundles In Group	View Bundles In Group	→	Additional Comments
	N/A		N/A	→	No delete is possible.
				→	Can't delete because no bundles can be seen.
				→	Can delete bundle [version]s in any bundle group associated with any of the user's roles.
	N/A		N/A	→	Can delete bundle [version]s in bundle groups associated with the relevant role.
		N/A	N/A	→	Can delete any bundle [version]. Delete Bundles In Group and View Bundles In Group are irrelevant.

Use Cases

Here are some use cases that help illustrate how the bundle security model can be utilized.

But first, all use cases must start with an admin user with manage Security permission creating users and roles and assigning bundle permissions to those roles. In addition, that admin user (or a user with Manage Bundle Groups permission) must create bundle groups and associate them with the appropriate role(s). The permissions assigned to the roles and the bundles assigned to the bundle groups will be different depending on the use case. But realize that an admin user must initially set up the security arrangements.

User Deploying His Own Bundle To Specific Resource Group.

You can do this several ways. Here are some possibilities. With one role:

                  Bundle Group A
                        |
                        v
Resource Group X ---> Role R <--- User U
                        ^
                        |
               Create Bundles In Group
               Deploy Bundles To Group

or two roles:

Bundle Group A
     |
     v
  Role R1 <--- User U       Resource Group X ---> Role R2 <--- User U
     ^                                               ^
     |                                               |
Create Bundles In Group                     Deploy Bundles To Group

or another way with two roles, using global bundle permissions and no bundle groups:

Resource Group X ---> Role R2 <--- User U          Role R3 <--- User U
                         ^                            ^
                         |                            |
                Deploy Bundles To Group          Create Bundles
                                                 View Bundles

Actions By User: User U creates an unassigned bundle. He can create and see the unassigned bundle because he has View Bundles. User goes through the deploy-bundle-wizard and is able to deploy to Resource Group X. No bundle groups are involved.

User Deploying Another User's Bundle To Specific Resource Group

You can do this with one role:

                  Bundle Group A
                        |
                        v
Resource Group X ---> Role R <--- User U
                        ^
                        |
               Deploy Bundles To Group

or two roles:

Bundle Group A
     |
     v
  Role R1 <--- User U      Resource Group X ---> Role R2 <--- User U
                                                    ^
                                                    |
                                           Deploy Bundles To Group

Actions By User: User cannot create bundles. User selects a bundle from all bundle groups for which he has access. In this case that is Bundle Group A (remember that View Bundles In Group is implied and does not need to be set explicitly). He can then deploy the viewable bundles to any resource group for which he has Deploy Bundles To Group permission (in this case, Resource Group X).

Team Leader Creates Bundles, Team Members Deploy Those 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

Actions By User TeamLeader: Team Leader creates a bundle in BundleGroup A. Note that TeamLeader cannot deploy the bundles - he can only create them.

Actions By User TeamMember1: This user cannot create bundles, nor add/remove bundles from the bundle group, however, this user can deploy any bundle found in Bundle Group A to Resource Group X. Note that team members can only see bundles associated with Bundle Group A - no others are visible.

Deployment Manager Gives Teams Bundles Which They Can Deploy

Bundle Group A
     |
     v
  Role R1 <--- User TeamLeader
     |
     v
Create Bundles In Group
Delete Bundles In Group

Bundle Group A
Bundle Group B                                       Bundle Group B
     |                                                      |
     v                                                      v
  Role R2 <--- User DeployManager  Resource Group X ---> Role R3 <--- Users: TeamMember1, TeamMember2
     ^                                                      ^
     |                                                      |
Assign Bundles To Group                            Deploy Bundles To Group
Unassign Bundles From Group

Actions By User TeamLeader: User TeamLeader can create (or delete) bundles in Bundle Group A. But he cannot deploy them or assign them to any other groups.

Actions By DeployManager: User DeployManager cannot create bundles, but he can view all bundles created by TeamLeader (or anyone else assigning bundles to Bundle Group A). DeployManager can add assign any Bundle A bundles to Bundle Group B. This allows him to let anyone associated with Role R3 deploy those bundles. DeployManager can also unassign bundles from Bundle Group B, thus disallowing team members from deploying them. So, in short, DeployManager is the one who dictates which bundles can be deployed by whom, simply by assigning bundles to the appropriate bundle group.

Actions By User TeamMember1: TeamMember1 (and TeamMember2 for that matter) cannot create any bundles and cannot add any bundles to groups. But TeamMember1 can deploy bundles from Bundle Group B to Resource Group X.

Note that Deploymanager can assign or unassign bundles from Bundle Group A as well. This could optionally be avoided by introducing another role, R4, which provided only view permission to Bundle Group A. Then, assign R4 to DeployManager and do not associate Bundle Group A with R2

Allow A User To See All Bundles In the System And Deploy Them Anywhere Accessible To User

Role R1 <--- User U
   |
   v
View Bundles
Deploy Bundles

Notice that the user's role R1 need not have any resource groups or bundle groups associated with it. The two global permissions allow the user to see all bundles and to deploy them to any resource group the user has access to. So, while this role need not have any resource groups, the user still must have other roles that give him access to resource groups - the idea here is that any resource groups this user U has access to can have any bundle deployed to it by user U.

Allow A User To See All Bundles In the System But Only Deploy Them To Specific Resource Groups

You can do this with one role:

Resource Group X ---> Role R <--- User U
                        ^
                        |
                 View Bundles
               Deploy Bundles To Group

or two roles:

Resource Group X ---> Role R1 <--- User U               Role R2 <--- User U
                         ^                                 ^
                         |                                 |
                Deploy Bundles To Group             View Bundles

Actions by User U: The user cannot create or delete bundles nor can the user assign or unassign bundles from bundle groups. However, the user can see all bundles in the system and can deploy those bundles to Resource Group X (but only to Resource Group X).

Allow a User To Manage All Bundle Groups In The System

Role R1 <--- User U
   |
   v
Manage Bundle Groups

This will allow user U to create and delete bundle groups as well as assigning/unassigning any bundle to/from any bundle group. However, note that this user has no ability to create or delete bundles nor can the user deploy bundles. This user can only operate on bundles that already exist.

Allow a User To Create And Delete Any Bundle

Role R1 <--- User U
   |
   v
Create Bundles
Delete Bundles
View Bundles

This will allow user U to create unassigned or assigned (to any bundle group) bundles. And to delete any bundle (assigned or unassigned). It also allows the user to assign or unassign any bundle to or from any bundle group. However, the user has no ability to deploy bundles.

Allow a User To Only Delete Certain Bundles The User Can See

You can do this with one role:

Bundle Group A
     |
     v
  Role R1 <--- User U
     ^
     |
Delete Bundles From Group

The user is restricted to being able to delete (or unassign) those bundles in Bundle Group A.

Allow Team Members To Update Each Others Bundles

Bundle Group A
     |
     v
  Role R1 <--- User U1, U2, ..., Un
     ^
     |
Create Bundles In Group
Delete Bundles From Group

This allows all users Ux to create and delete bundles (including uploading bundle versions for existing bundles) but ONLY for those bundles that the users can see. And this means only those bundles associated with Bundle Group A. If a user wants to create a new bundle, they can only associate them with Bundle Group A.
Note also these users Ux cannot deploy any bundle anywhere - they are restricted to only creating and deleting them.

See All Bundles But Only Create Bundles in Certain Bundle Groups

Bundle Group A ---> Role R1 <--- User U               Role R2 <--- User U
                         ^                                 ^
                         |                                 |
                Create Bundles In Group             View Bundles

Be Able To Create In Certain Bundle Groups But Not Be Able To Create In Other Viewable Groups

Bundle Group A ---> Role R1 <--- User U       Bundle Group B ---> Role R1 <--- User U
                         ^
                         |
                Create Bundles In Group

Be Able To Delete From Certain Bundle Groups But Not Be Able To Delete From Other Viewable Groups

Bundle Group A ---> Role R1 <--- User U       Bundle Group B ---> Role R1 <--- User U
                         ^
                         |
                Delete Bundles From Group

Unsupported Use Cases

None currently