Bundle Permissions

This was a working copy of the design page. This page is now to be considered obsolete. Look at the main documentation page for the latest information that supercedes this page

We need a more fine-grained security model surrounding bundle deployments (BZ 988553). This design page explains how we can do it.

Before you try to understand this page, you should first understand the current Bundle feature - read the feature page Provisioning and watch the Bundle Demo to understand what the bundle subsystem can do today.

Bundle Groups

To apply fine grained security permissions to the bundle subsystem will require adding a new concept to the security subsystem - bundle groups. Similar to resource groups, bundle groups will allow RHQ to apply user permissions to a set of bundles.

Today's 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 newly proposed DEPLOY_BUNDLES_TO_GROUP permission (which will be described below) is that it restricts the user to only deploy bundles to resource groups that that user has access to.

If we want to allow for a user to deploy a bundle to an allowed resource group, not only does the resource group need to be assigned to a role that is assigned to the user, but the bundle to be deployed must be in a bundle group that is attached to a role that is assigned to a user (note: the role doesn't have to be the same as the one the resource group is attached to). Today, we do not have this concept of a bundle group. We would have to add a new relationship between role and bundle - this is where bundle groups come in:

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

WARNING! Any change to the security model involves large amounts of risk. Not only because it involves security, but also because it is used in so many places. We have role queries in every subsystem. Even if we only add to the model (and leave alone what already exists), we would need to carefully study the changes and perform some quality testing to ensure we don't break existing queries and security checks.

If we have that new bundle group relationship to roles, then this would allow things like having an admin user create a new role with permission DEPLOY_BUNDLES_TO_GROUP, assign resource groups to that role, assign bundle groups to that role, then give that role to any user. That user would then be able to deploy those bundles that are members of the bundle group but only to those resource groups assigned roles that the user is assigned. More examples will be explained below in the Use Cases section of this document.

New Fine-Grained Bundle Permissions

Global Level Permissions

MANAGE_BUNDLE

Implies all other bundle-related permissions.
This is for backward compatibility - it can do EVERYTHING bundle-wise.
We may want to rename this during a db upgrade to something else - to indicate it may be deprecated.

MANAGE_BUNDLE_GROUPS

This permission is required to CRUD bundle groups (bundle groups are a new entity introduced in order to implement these new features).
Currently, this means it can add and remove members of the group.
This implies Global.VIEW_BUNDLES - user can see all bundles.
This seems analogous to INVENTORY_MANAGER permission for resources/resource groups.

DEPLOY_BUNDLES_TO_GROUP

This is to allow a user to deploy bundles the user can see to any resource group the user can see.

VIEW_BUNDLES

You can view all bundles, no matter what group, if any, a bundle is in.
This permission is useful for a user that wants to add bundles to bundle groups.
Use case: this can be used to allow users to see all bundles but with the restriction of only allowing the user to deploy to those resource groups that he has access to (DEPLOY_BUNDLES_TO_GROUP permission)

CREATE_BUNDLES

A user can create bundles (which also means uploading bundle versions).
At create time, the new bundle MUST BE assigned to bundle group(s) the user can see.
- A newly created bundle must be assigned to at least one of the bundle groups the user can see (note: if the user has Global.VIEW_BUNDLES permission, he can see all bundles). The bundle group assignment is not done when the bundle being uploaded is merely a new version of a previously existing bundle since all bundle versions have the same group membership as the bundle they belong to.
If the new bundle is really a bundle version for an EXISTING bundle, the user MUST have permission to see that bundle in order to update it.
- This means that there must exist at least one bundle group that the bundle is assigned to and that the user can see. Notice that the bundle can be part of other bundle groups that the user cannot see and this will still be allowed. As long as there is at least one user-visible bundle group that the bundle is assigned, you can update the bundle with a new bundle version.
IFF the user has Global.VIEW_BUNDLES, the user can opt to not put the bundle in any group
IFF the user has Global.VIEW_BUNDLES, the user can opt to put the bundle version in any existing bundle.

CREATE_BUNDLES is a global permission because we need to support the use-case of someone being able to create a bundle (or bundle version) and not assign it immediately to a bundle group. Since this use case does not involve a bundle group, obviously, a bundle-group-level permission will not work. Therefore, this global permission exists.

DELETE_BUNDLES

A user can delete any bundle (or bundle version) he can view.
A user with this permission will also need Global.VIEW_BUNDLES in order to delete bundles that are not in any group.
If you delete a bundle version, nothing has to be done with groups. If you delete the bundle itself, all of its versions will be deleted and that bundle will be removed from any groups it was a member of.

DELETE_BUNDLES is a global permission because we need to support the use-case of someone being able to delete a bundle (or bundle versions) that are not currently associated with any bundle group. Since this use case does not involve a bundle group, obviously, a bundle-group-level permission will not work. Therefore, this global permission exists.

Bundle Group Level Permissions

ASSIGN_BUNDLES_TO_GROUP

A user can add any bundle he can see to the bundle group (allowing him to "copy" bundles from one bundle group to another).
The user needs Global.VIEW_BUNDLES permission to add bundles that are not in any group.

UNASSIGN_BUNDLES_FROM_GROUP

A user can remove bundles from the bundle group (this does not delete the bundles, it only removes them from a bundle group).

VIEW_BUNDLES_IN_GROUP

This is an implied permission. If you are in a role that has a bundle group associated with it, you are immediately allowed to view the bundles assigned to that bundle group.

CREATE_BUNDLES_IN_GROUP (new!)

Provides the user the ability to create new bundles (or update existing bundles by adding new bundle versions to existing bundles) but only for those bundles in the bundle group where this permission is granted.

DELETE_BUNDLES_FROM_GROUP (new!)

Provides the user the ability to delete bundles (or bundle versions) but only for those bundles in the bundle group where this permission is granted.

Note that we didn't originally place those two group-level permissions above (CREATE_BUNDLES_IN_GROUP/DELETE_BUNDLES_FROM_GROUP) in the design because it could become confusing from a security standpoint as to who has permission to do what. If a bundle is in multiple bundle groups and some of those bundle groups are associated with multiple roles, a user need only have CREATE or DELETE permission for one of those roles/groups to be able to manipulate those bundles, even if he doesn't have those permissions on other roles. This could be confusing and may cause an admin user to accidentally give permissions that should not be granted.

Resource Group Level Permissions

DEPLOY_BUNDLES_TO_GROUP

The user can deploy bundles he can see to the resource group. This includes bundles in the user's bundle groups. If the user has VIEW_BUNDLES, the user can deploy any bundle.
Note that a bundle group and a resource group need NOT be associated with the same role. If bundle group A is associated with role A and resource group B is associated with role B, as long as DEPLOY_BUNDLES_TO_GROUP is enabled for role B, you can deploy any bundle in bundle group A to resource group B.

Creating Bundles

There is a distinction to be made when creating an initial bundle (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 verison "2.0"). Here are tables to show what is allowed and disallowed when creating or updating bundles when certain permissions are assigned to a given user.

In both the tables below, the VIEW_BUNDLES_IN_GROUP column represents the bundle group permission and the CREATE_BUNDLES and VIEW_BUNDLES columns represent the global permissions. If a permission column is checked, that means the user is granted those permissions.

The "In No Groups" column means if the bundle is to be created but not assigned to any group (or, for the "Updating" table, if the bundle to be updated with a new bundle version already exists but is not assigned in any group). If this column is checked, it means the operation is allowed if the checked permissions are effective for the given user.

The "In At Least 1 Group" column means if the bundle is to be created and assigned to at least one group (or, for the "Updating" table, if the bundle to be updated with a new bundle version already exists and is assigned to at least one bundle group). If this column is checked, it means the operation is allowed if the checked permissions are effective for the given user.

Initial Bundle Creation

CREATE_BUNDLES	VIEW_BUNDLES	VIEW_BUNDLES_IN_GROUP	→	In No Groups	In At Least 1 Group
			→
			→
			→
			→

Updating Bundle By Creating New Bundle Version For Existing Bundle

CREATE_BUNDLES	VIEW_BUNDLES	VIEW_BUNDLES_IN_GROUP	→	In No Groups	In At Least 1 Group
			→
			→
			→
			→

Deleting Bundles

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

DELETE_BUNDLES	VIEW_BUNDLES	VIEW_BUNDLES_IN_GROUP	→	In No Groups	In At Least 1 Group
			→
			→
			→
			→

What to do with existing MANAGE_BUNDLE permission

Today, there is a coarse-grained, "uber-permission" MANAGE_BUNDLE. If you have this global permission, you can create, delete, deploy and pretty much do anything in the bundle subsystem. We would leave this in the code for backward compatibility. If a user has MANAGE_BUNDLE, it would imply the user has all of the new proposed permissions (VIEW_BUNDLES, DEPLOY_BUNDLES_TO_GROUP, etc.) and can do anything and everything in the bundle subsystem.

We may want to rename MANAGE_BUNDLE permission to indicate this is a very powerful permission. We may even consider deprecated this permission, unless we have some users that still want this capability. For now, we will leave it.

Supported Use Cases

Here are some use cases that help illustrate how the new bundle permissions and bundle groups 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 must create bundle groups (or have a user with MANAGE_BUNDLE_GROUPS permission create bundle groups) and then associate the bundle group(s) 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 with one role:

                  Bundle Group A
                        |
                        v
Resource Group X ---> Role R <--- User U
                        ^
                        |
              Global.CREATE_BUNDLES,
              BundleGroup.VIEW_BUNDLES_IN_GROUP,
              Resource.DEPLOY_BUNDLES_TO_GROUP

or two roles:

Bundle Group A
     |
     v
  Role R1 <--- User U       Resource Group X ---> Role R2 <--- User U
     ^                                               ^
     |                                               |
BundleGroup.VIEW_BUNDLES_IN_GROUP,      Resource.DEPLOY_BUNDLES_TO_GROUP
Global.CREATE_BUNDLES

or three roles:

Bundle Group A
     |
     v
  Role R1 <--- User U      Resource Group X ---> Role R2 <--- User U          Role R3 <--- User U
     ^                                              ^                            ^
     |                                              |                            |
BundleGroup.VIEW_BUNDLES_IN_GROUP      Resource.DEPLOY_BUNDLES_TO_GROUP  Global.CREATE_BUNDLES

Actions By User: User U creates a bundle. Because the user has no BundleGroup.ASSIGN_BUNDLES_TO_GROUP permission, an admin must add his bundle to Bundle Group A. User goes through the deploy-bundle-wizard and is able to deploy to Resource Group X.

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
                        ^
                        |
              BundleGroup.VIEW_BUNDLES_IN_GROUP,
              Resource.DEPLOY_BUNDLES_TO_GROUP

or two roles:

Bundle Group A
     |
     v
  Role R1 <--- User U      Resource Group X ---> Role R2 <--- User U
     ^                                              ^
     |                                              |
BundleGroup.VIEW_BUNDLES_IN_GROUP      Resource.DEPLOY_BUNDLES_TO_GROUP

Actions By User: User cannot create any bundles. User selects a bundle from all bundle groups he has access to (in this case, Bundle Group A) and can deploy them to any resource group to 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
     ^                                                   ^
     |                                                   |
Global.CREATE_BUNDLES,                         BundleGroup.VIEW_BUNDLES_IN_GROUP,
BundleGroup.VIEW_BUNDLES_IN_GROUP,             Resource.DEPLOY_BUNDLES_TO_GROUP
BundleGroup.ASSIGN_BUNDLES_TO_GROUP

Actions By User TeamLeader: Team Leader creates a bundle. Because TeamLeader has BundleGroup.ASSIGN_BUNDLES_TO_GROUP permission on Role R1, he can add his new bundle to Bundle Group A since Bundle Group A is associated with Role R1. NOTE: TeamLeader cannot add any bundles that he, himself, did not create to Bundle Group A because he does not have Global.VIEW_BUNDLES and cannot see any other bundles - therefore, TeamLeader cannot give permissions to team members to deploy any other bundles. Note also that TeamLeader cannot deploy any bundles - he can only create them and assign them to bundle groups.

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

Role R1 <--- User TeamLeader
   |
   v
Global.CREATE_BUNDLES

Bundle Group A                                       Bundle Group A
     |                                                      |
     v                                                      v
  Role R2 <--- User DeployManager  Resource Group X ---> Role R3 <--- Users: TeamMember1, TeamMember2
     ^                                                      ^
     |                                                      |
Global.VIEW_BUNDLES,                             BundleGroup.VIEW_BUNDLES_IN_GROUP,
BundleGroup.VIEW_BUNDLES_IN_GROUP,               Resource.DEPLOY_BUNDLES_TO_GROUP
BundleGroup.ASSIGN_BUNDLES_TO_GROUP,
BundleGroup.UNASSIGN_BUNDLES_FROM_GROUP,

Actions By User TeamLeader: User TeamLeader can create bundles. But he cannot deploy them or assign them to any groups.

Actions By DeployManager: User DeployManager cannot create bundles, but he can see all bundles created by TeamLeader (and any other user associated with Role R1). DeployManager can add any of those bundles he can see to Bundle Group A. This allows him to give the ability to let anyone associated with Role R3 to be able to deploy those bundles. DeployManager can also remove bundles from Bundle Group A, thus disallowing team members from deploying it. 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 A to Resource Group X.

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

This is a simple one. Just give the user in question a role with the global permissions VIEW_BUNDLES and DEPLOY_BUNDLES.

Role R1 <--- User U
   |
   v
Global.VIEW_BUNDLES,
Global.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
                        ^
                        |
              Global.VIEW_BUNDLES,
              Resource.DEPLOY_BUNDLES_TO_GROUP

or two roles:

Resource Group X ---> Role R1 <--- User U               Role R2 <--- User U
                         ^                                 ^
                         |                                 |
            Resource.DEPLOY_BUNDLES_TO_GROUP    Global.VIEW_BUNDLES

Actions by User U: The user cannot create or delete bundles nor can the user add or remove 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

This is another simple one. Just give the user in question a role with the global permissions MANAGE_BUNDLE_GROUPS, which will imply that RHQ will also give the user the global permission VIEW_BUNDLES.

Role R1 <--- User U
   |
   v
Global.MANAGE_BUNDLE_GROUPS,
Global.VIEW_BUNDLES

This will allow user U to create and delete bundle groups as well as adding and removing any bundle 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

This is another simple one. Just give the user in question a role with the global permissions CREATE_BUNDLES, VIEW_BUNDLES and DELETE_BUNDLES.

Role R1 <--- User U
   |
   v
Global.CREATE_BUNDLES,
Global.VIEW_BUNDLES,
Global.DELETE_BUNDLES

This will allow user U to create bundles, and delete any bundle (whether or not those bundles are in bundle groups). The VIEW_BUNDLES allows the user to see all bundles, and DELETE_BUNDLES allows the user to delete all those bundles the user can see. However, note that this user has no ability to assign bundles to groups and the user cannot 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
     ^
     |
Global.DELETE_BUNDLES,
BundleGroup.VIEW_BUNDLES_IN_GROUP

or two roles:

Bundle Group A
     |
     v
  Role R1 <--- User U                  Role R2 <--- User U
     ^                                    ^
     |                                    |
BundleGroup.VIEW_BUNDLES_IN_GROUP   Global.DELETE_BUNDLES

The user is restricted to being able to see only those bundles in Bundle Group A. The user is also given the global permission to delete bundles. Therefore, since the user can only see bundles in Bundle Group A, it means the user can only delete bundles found in Bundle Group A.

Allow Team Members To Update Each Others Bundles

Bundle Group A
     |
     v
  Role R1 <--- User U1, U2, ..., Un             Role R2 <--- User U1, U2, ..., Un
     ^                                             ^
     |                                             |
BundleGroup.VIEW_BUNDLES_IN_GROUP            Global.CREATE_BUNDLES,
                                             Global.DELETE_BUNDLES

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 (that is because they have Global.CREATE_BUNDLES without Global.VIEW_BUNDLES).
Note also these users Ux cannot deploy any bundle anywhere - they are restricted to only creating and deleting them.

Newly Supported Use Cases (new!)

These used to be unsupported - but now with the CREATE/DELETE bundle-group permissions, they are supported.

See All Bundles But Only Create Bundles in Certain Bundle Groups

To be able to see all bundles, a user needs either Global.VIEW_BUNDLES or have BundleGroup.VIEW_BUNDLES_IN_GROUP for all bundle groups that exist.

To be able to create bundles, a user coud be given Global.CREATE_BUNDLES. But with this, the user is able to create bundles in any viewable bundle group - and since the user can see all bundles/bundle groups, it means the ability to create in any bundle group.

The alternative is to give the user the BundleGroup.CREATE_BUNDLES_IN_GROUP permission which is associated with only a select set of bundle groups. With this, the user is only able to create bundle versions for those bundles that are in the bundle groups associated with their roles that gave them the permission. It also allows the user to create new bundles - but the user must put the new bundle (i.e. its first version) in a bundle group on which they have this permission.

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

To be able to view bundle groups, a user must have BundleGroup.VIEW_BUNDLES_IN_GROUP on those groups.

Similar with the above use case, this use case is supported by giving the user the BundleGroup.CREATE_BUNDLES_IN_GROUP permission which is associated with only a select set of bundle groups. With this, the user is only able to create bundle versions for those bundles that are in the bundle groups associated with their roles that gave them the permission. It also allows the user to create new bundles - but the user must put the new bundle (i.e. its first version) in a bundle group on which they have this permission.

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

Similiar to the previous use-case, only it involves BundleGroup.DELETE_BUNDLES_FROM_GROUP rather than the create permission. But the situation is the same in all other respects.

JBoss Community Archive (Read Only)

RHQ 4.9

Bundle Permissions

Bundle Groups

New Fine-Grained Bundle Permissions

Global Level Permissions

MANAGE_BUNDLE

MANAGE_BUNDLE_GROUPS

DEPLOY_BUNDLES_TO_GROUP

VIEW_BUNDLES

CREATE_BUNDLES

DELETE_BUNDLES

Bundle Group Level Permissions

ASSIGN_BUNDLES_TO_GROUP

UNASSIGN_BUNDLES_FROM_GROUP

VIEW_BUNDLES_IN_GROUP

CREATE_BUNDLES_IN_GROUP (new!)

DELETE_BUNDLES_FROM_GROUP (new!)

Resource Group Level Permissions

DEPLOY_BUNDLES_TO_GROUP

Creating Bundles

Deleting Bundles

What to do with existing MANAGE_BUNDLE permission

Supported Use Cases

User Deploying His Own Bundle To Specific Resource Group.

User Deploying Another User's Bundle To Specific Resource Group

Team Leader Creates Bundles, Team Members Deploy Those Bundles

Deployment Manager Gives Teams Bundles Which They Can Deploy

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

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

Allow a User To Manage All Bundle Groups In The System

Allow a User To Create And Delete Any Bundle

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

Allow Team Members To Update Each Others Bundles

Newly Supported Use Cases (new!)

See All Bundles But Only Create Bundles in Certain Bundle Groups

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

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