Jenkins
Jenkins is kind of a complicated beast when you first start playing with users and rights. Jenkins has an internal setup to be taken into account. In the Manage Jenkins -> Manage and Assign roles -> Manage Roles section, local roles are defined.
At first, it seems logical to use the same names here as used in the IAM system (Keycloak), but it becomes complicated quickly. Therefore, the setup uses explicitly assigned local roles with the local_ prefix and mappings are created between those local roles and the Keycloak roles in the Assign Roles section.
Local users cannot be defined in this setup. They are defined inside the identity store (usually LDAP), where the user is linked to a group. Keycloak links groups to roles and the role name is exposed as a group-membership to Jenkins in the [group-membership] section inside the userInfo part in the JWT.
For the installation background, see .
The following roles are defined locally:
- local_admin: a local user with all rights on all objects
- local_user: a local user that is allowed to use the Jenkins basic functionality
- local_read_only: a local user that cannot change anything, but is permitted to view
Under the same paradigm, local roles are defined per pipeline:
- local_netcicd_run: a local user permitted to start, stop and view the NetCICD jobs
- local_netcicd_dev: a local user permitted to execute all tasks related to the NetCICD jobs: start, stop, modify, etc.
- local_netcicd-developer-toolbox_run: a local user permitted to start, stop and view the NetCICD-developer-toolbox jobs
- local_netcicd-developer-toolbox_dev: a local user permitted to execute all tasks related to the NetCICD-developer-toolbox jobs: start, stop, modify, etc.
Specifically for the agent:
- local_netcicd-agent
The mapping of IAM roles to local roles is as follows:
You can log into jenkins as one of the users defined in Keycloak. Depending on the role of the user, it has rights on one or more pipelines, and depending on the role, the user can either just run the pipeline, or modify it.
As soon as a commit is made to git, the Jenkins pipeline gets triggered by Gitea and runs. Jenkins will first create a CML setup and deploy there, after this, it will reconfigure a physical lab and deploy there. All deployments are tested and the test results are written to Nexus, a read-only repository with the git commit id as the identifier. This way, when it is known which commit runs in the infrastructure, you can retrieve the test reports for that commit.