Defining Jenkins roles to set Jenkins pipeline access
Prerequisites
It will required modify the current Jenkins jobs distribution in the jenkins-jobs and emp-jenkins-jobs repositories to be divided by business area instead of, as right now, by teams (where we are using so deprecated team names that doesn't exist anymore).
Reference Documents
| Reference | Document Location |
|---|---|
| REF01 | PC-1536: Spike with PoC |
| REF02 | Manage and assign roles |
| REF03 | Tech Control 017 |
Problem Description
The current Jenkins configuration allow to whoever access to whatever Jenkins pipeline, and in some cases, the possibility to deploy in the staging/production environments whatever service version.
Background
We started to create some pipelines or automatic process in GitHub actions but our main continuous integration (CI) and continuous delivery (CD) tool in Ebury still being Jenkins.
After review the different tech controls implemented recently, we have one that impact directly in our Jenkins administration.
TECH-017: Risk of unauthorised changes in Jenkins due to the uncontrolled access management to the system that could cause service disruption to client management-related business processes.
With our current Jenkins configuration and jobs distribution we can’t manage the Jenkins pipelines access properly because the same pipeline is used to the CI and the CD in the different environments, and they are accessible for everyone.
Solution
To solve this problem we need to change different areas: - Pipelines distribution. - Right now, we have one pipeline that based in conditions is going to execute the PRs validation, the staging deployment or the production one. If we want to manage the pipelines divided on “PRs”, “Staging” and “Production” we need to have different jobs definition for that. Example: [EburyPipelinePythonService].(https://github.com/Ebury/jenkins-devops/blob/master/vars/eburyPipelinePythonService.groovy) - We could have three different pipelines defined in the jenkins-devops library and in that way, we have isolated pipelines with a clear scope. Also, it’s require include Jenkinsfiles in the services. - Jenkins jobs distribution. - Right now, we have five different main sections “deployments”, “development”, “ebox”, “infra” and “metrics”. The main issue exist in the “development” section because is divided in folders based in the teams names (a lot of them doesn’t exist now). - We’ll refactor the Jenkins jobs distribution without change main sections but changing the “development” section according to the current business areas (in the same way than Jenkins split). In that way, we can have easy access to all the Jenkins jobs by area without remember to which “old” team the repository was assigned to. Apart from that, it will help to define roles based in path patterns. - Jenkins user/roles configuration. - Right now, we have a few roles not used, the main ones are “admins” and “users” that means that everyone can access to whatever pipeline in Jenkins. - We’ll need to create different roles based in business areas (or teams if we want to) and assign the existing people to the proper area or team. - We’ll need to change the current Jenkins configuration to create different path patterns that in combination with the roles restrict the access to the Jenkins pipelines.
Note: To cover the tech control only are required the points 2 and 3, the first one is only in case that we want only certain group of people in each business area could execute Jenkins pipelines to PRs, Staging or Production.
Service Ownership
- The initial implementation shouldn't affect to any existing service because the pipelines still being the same, we only change the visibility to the users (developers) and the folder distribution inside of Jenkins.
- Who is going to manage that? The Code Owners related to the repositories ansible-playbook-jenkins and ansible-playbook-emp-jenkins because are the people responsible to approve the suggested changes confirming it with the team lead related.
Alternatives
- Other option is to integrate permissions through Google accounts and based on them restrict the access to the Jenkins pipelines but every time that we need to do a change related to the access it'll be under the IT team instead of the Jenkins code (ansible-playbook-jenkins and ansible-playbook-emp-jenkins repositories)
- Another possibility, thanks @earnubs, using the Keycloak Jenkins plugin and move out the Jenkins user creation outside of Jenkins code to use the metada in HiBob. With that we are allowing access to Jenkins at the same moment that we're creating a new user in our organisation so that means less steps in our onboarding process.
Caveats
The main concern with the proposed solution is the list user maintenance but this can be managed in the same way that we do during the onboarding process where each user include yourself in the ansible-playbook-jenkins and ansible-playbook-emp-jenkins repositories
Operation
- We should create the necessary roles and groups patterns based in the business areas.
- Once the roles has been created, we can distribute the people through the roles based in the business area.
- In parallel, update the Jenkins jobs distribution according to the groups pattern defined.
- Finally, remove the group patterns unnecessary and re-define the folder/credentials distribution.
Security Impact
This change doesn't affect to the Security team directly but for sure, increase the security in Jenkins taking into account that we're restricting the access to the Jenkins jobs depending on the business area for each user.
Performance Impact
N/A
Developer Impact
Each user should maintain his/her position in case to be moved to another business area. Example: from Moneyflows to FX. If this change isn't done in the Jenkins code, the user can't access to the proper Jenkins jobs pipelines.
Data Contracts
N/A
Deployment
We can distribute the work in two phases: - Jenkins configuration - Jenkins jobs distribution
Dependencies
N/A
Based on RFC Template Version 1.1