Yellow Pages

This repository is an early draft of automated RBAC deployment within OSC. As of today, nothing is being activelly deployed from this repository, but over couple of next weeks we expect that according to contenten of accounts/..., groups/... and resources/... we deploy:

• GitLab RBAC
• MTR
• OTC

No secrets can be commited into this repository. Obviously, public keys are not secrets.

Input from the TEAM

Create a file in accounts/your.email@domain.tld.yaml. The content should pass pre-commit hook validation according to schema.

Become member of a group in groups/name.yaml by placing your email into respective list. The file you modify should pass schema validation.

If you miss an attribute, resource, team, or want to contribute pipeline, your contribution is welcomed.

Entry process for gitlab.devops.telekom.de

Once the new member has access to DevOps GitLab (what is a part of standard T-Systems on-boarding process), one of current owners of the OSC grants developer rights to yellow-pages.

After the user is member of OSC group, he needs to follow the following procedure:

1. Create yaml file in /accounts folder naming the file by your e-mail address, eg. name.surname@t-systems.com.yaml
2. Fill in all the required information. The actual set of information to be filled can be found in the same repository under /schemas/accounts.json. Name and the e-mail address are the mandatory items without which the request will not be approved.
3. Add your e-mail address in member section of appropriate yaml file under /groups depending on where you want to have an access (eg. kyma-senior.yaml if you want to have the access to kyma repositories with senior-relevant rights).
4. Add your e-mail address in appropriate role section of OSC.yaml file under /resources/cas-devs/ depending on which role you need to have in OSC GitLab. Expiration date: If the access is requested only for restricted time after which you will be offboarded from OSC, enter appropriate expiration date in the same section of your yaml file in /accounts as your e-mail address. If the access to specific group is requested only for restricted time, enter appropriate expiration date in the same section of /groups as your e-mail address. If the access to specific resource is requested only for restricted time, enter appropriate expiration date in the same section of /resources/subfolder_of_resource as your e-mail address.
5. Create commit into new branch.
6. Create merge request and describe in Description field the reason for which you need the access.
7. Assign the merge request to one of the owners of the group.
8. Wait for the approval.

Once the merge request is created, dedicated approvers need to approve it and the last approved merges the request if eligible. In case the access cannot be granted, merge request is rejected/denied. After the merge, the pipeline runs, and the access is granted to requested group(s).

Change process for gitlab.devops.telekom.de

If user needs to change his access rights/groups the following procedure must be applied:

1. Add/remove your e-mail address in member section of appropriate yaml file under /groups depending on where you need to have/not to have an access (eg. kyma-senior.yaml if you need to have the access to kyma repositories with senior-relevant rights).
2. If the change of role is needed, add your e-mail address in appropriate role section of OSC.yaml file under /resources/cas-devs/ and remove it from section of original role. Expiration date: If the access is requested only for restricted time after which you will be offboarded from OSC, enter/remove/change appropriate expiration date in the same section of your yaml file in /accounts as your e-mail address. If the access to specific group is requested only for restricted time, enter appropriate expiration date in the same section of /groups as your e-mail address. If the access to specific resource is requested only for restricted time, enter appropriate expiration date in the same section of /resources/subfolder_of_resource as your e-mail address.
3. Create commit into new branch.
4. Create merge request and describe in Description field the reason for which you need the access or no longer need it.
5. Assign the merge request to one of the owners of the group.
6. Wait for the approval.

Once the merge request is created, dedicated approvers need to approve it and the last approved merges the request if eligible. In case the access cannot be granted, merge request is rejected/denied. After the merge, the pipeline runs, and the access is granted/removed in respective group(s).

Removal process for gitlab.devops.telekom.de

Once it is known that the user will be offboarded from OSC project the squad lead checks all access groups of user and set expiration date of each access to user's exit day or the last day of user's assignment at OSC. In case squad lead does not have appropriate access to GitLab, he can delegate this activity to any owner of group.

The following steps are to be followed:

1. Enter desired expiration date in the same section of user's yaml file in /accounts as user's e-mail address.
2. Check each json file under /groups to see which group is the user member of.
3. For each group enter desired expiration date in the same section of group's json file in /groups as user's e-mail address.
4. Check each json file under /resources/subfolder_of_resource to see which resource is the user member of.
5. For each resource enter desired expiration date in the same section of resource's json file in /resources/subfolder_of_resource as user's e-mail address.
6. Create commit into new branch.
7. Create merge request and describe in Description field the reason for which the removal is needed.
8. Assign the merge request to one of the owners of the group.
9. Wait for the approval.

Once the merge request is created, dedicated approvers need to approve it and the last approved merges the request if eligible. In case the removal cannot be performed, merge request is rejected/denied. After the merge, the pipeline runs, and the expiration date is applied for requested user/group(s)/resource(s).