Fix problem assigning admin permissions to bitbucket repositories

[jafarre-bi]

Fix admin permission assignment for new coponents

[jafarre-bi]

The problem is that, when a new repository is created, we are assigning admin permissions to a generic user group. This assignment has to be removed, but we need to validate that the resulting set of permissions is appropriate. @metmajer @clemensutschig this is not a technical decision and we would need you to validate the assigned permissions. Can you please review it? The list of assigned permissions follows.

Currently assigned permissions when the special permission set is specified on project creation:

Type	Who?	Level	Permission
Group	${global.keyuser.role.name}	project	ADMIN
Group	project.projectAdminGroup	project	ADMIN
Group	project.projectUserGroup	project	WRITE
Group	project.projectReadonlyGroup	project	READ
User	project.cdUser (default: ${bitbucket.technical.user})	project	WRITE
Group	${bitbucket.default.user.group}	repo	ADMIN
User	${bitbucket.technical.user}	repo	WRITE

Currently assigned permissions when the special permission set is not specified on project creation:

Type	Who?	Level	Permission
Group	${bitbucket.default.user.group}	project	WRITE
Group	${idmanager.group.opendevstack-users}	project	READ
User	project.cdUser (default: ${bitbucket.technical.user})	project	WRITE
Group	${bitbucket.default.user.group}	repo	ADMIN
User	${bitbucket.technical.user}	repo	WRITE

Additionally, whenever a specific CD User is specified on project creation, this user gets read permissions in all repositories in scmGlobalProperties.readableRepos (such as opendevstack/ods-jenkins-shared-library and opendevstack/ods-quickstarters).

The highlighted row is the one detected as giving admin permissions to a generic user group and has to be removed. If we do that, in case the special permission set is not specified, then the respository would not get any specific admin group or user. The only administrators would be the global bitbucket administrators. Is this fine?

[jafarre-bi]

Removed the admin permissions at repo level. These are the resuting permissions, that need to be validated:

Assigned permissions after the fix, when the special permission set is specified on project creation:

Type	Who?	Level	Permission
Group	${global.keyuser.role.name}	project	ADMIN
Group	project.projectAdminGroup	project	ADMIN
Group	project.projectUserGroup	project	WRITE
Group	project.projectReadonlyGroup	project	READ
User	project.cdUser (default: ${bitbucket.technical.user})	project	WRITE
User	${bitbucket.technical.user}	repo	WRITE

Assigned permissions after the fix, when the special permission set is not specified on project creation:

Type	Who?	Level	Permission
Group	${bitbucket.default.user.group}	project	WRITE
Group	${idmanager.group.opendevstack-users}	project	READ
User	project.cdUser (default: ${bitbucket.technical.user})	project	WRITE
User	${bitbucket.technical.user}	repo	WRITE

Additionally, whenever a specific CD User is specified on project creation, this user gets read permissions in all repositories in scmGlobalProperties.readableRepos (such as opendevstack/ods-jenkins-shared-library and opendevstack/ods-quickstarters).

[jafarre-bi]

After discussion, the decissions taken are:

• If special permissions set has been specified, we will not assign a specific admin group to the repository. It will inherit the admin group from the project.
• For the case that special permissions set has not been specified, we create a new bitbucket.default.admin.group config property and assign admin permissions to it.
• If bitbucket.default.admin.group is not specified, it will default to bitbucket.default.user.group.
• In the unlikely case that bitbucket.default.user.group is not specified, we will not assign specific admin permissions to the repository. Only the global Bitbucket administrators will have admin access to the repo.
• Auxiliary repositories (occonfig-artifacts and design) will get the same permissions as the regular repositories.

The final permission tables follow.

Assigned permissions after the fix, when the special permission set is specified on project creation:

Type	Who?	Level	Permission
Group	${global.keyuser.role.name}	project	ADMIN
Group	project.projectAdminGroup	project	ADMIN
Group	project.projectUserGroup	project	WRITE
Group	project.projectReadonlyGroup	project	READ
User	project.cdUser (default: ${bitbucket.technical.user})	project	WRITE
User	${bitbucket.technical.user}	repo	WRITE

Assigned permissions after the fix, when the special permission set is not specified on project creation:

Type	Who?	Level	Permission
Group	${bitbucket.default.user.group}	project	WRITE
Group	${idmanager.group.opendevstack-users}	project	READ
User	project.cdUser (default: ${bitbucket.technical.user})	project	WRITE
Group	${bitbucket.default.admin.group} (default: ${bitbucket.default.user.group})	repo	ADMIN
User	${bitbucket.technical.user}	repo	WRITE

[stitakis]

@jafarre-viewnext happy to review your changes once you have implemented the rules specified in your last comment

[jafarre-bi]

@jafarre-viewnext happy to review your changes once you have implemented the rules specified in your last comment

Thank you, @stitakis ! I will set the PR as ready for review as soon as I have properly tested the changes.

[jafarre-bi]

Some notes about the implementation:

The new property has been added to the application.properties as follows: bitbucket.default.admin.group=${bitbucket.default.user.group} The code just honors this property value. This is enough to maintain backwards compatibility when the new property is not present in the config map. However, this also allows users to disable the admin group by specifying the following in the config map: bitbucket.default.admin.group=

There was a problem when assigning permissions on project creation. If the same group was specified as having, for instance, write and admin permissions, The admin permissions were overwritten by the write permissions. This was actually happenning with the default user group, but the problem was hidden, because this group was getting admin permissions at repo level. It has been fixed by reversing the order in which permissions are assigned.

[jafarre-bi]

@stitakis ready for review. Thanks in advance!

[jafarre-bi]

@jafarre-viewnext I think is time to document the implemented rules. Proper documentation for this is missing and causes recurring queries on how the provision app behaves. Can you please extends https://github.com/opendevstack/ods-provisioning-app/blob/master/docs/modules/provisioning-app/pages/index.adoc to capture the new implemented rules?

Done