Operations Center acts as a gateway between each of the Client Masters. Any request from one Client Master to another Client Master will be routed through Operations Center. Each request will be tagged with the authentication that originated the request. Because different Client Masters can have different levels of trust or indeed could use completely different authentication or authorization strategies it is necessary for the Operations Center administrator to define the default authentication mapping strategy and optionally define specific mapping strategies for individual Client Masters.
In general, requests from a Client Master have one of two origins:
User requests driven via the UI. These requests will be tagged with the authentication of the user making the request. An example of one of these requests would be using the path browser to select a job to trigger.
Build driven requests. For a default installation of Jenkins or CloudBees Jenkins Enterprise these requests will be tagged with the SYSTEM authentication. The authentication of a build can be modified. For example the Authorize Project plugin allows jobs to be configured to run as: ANONYMOUS, a specific user, or the user who triggered the build.
Requests from a Client Master to another Client Master will be mapped twice. The first mapping will be to convert the source Client Master’s authentication into the authentication for Operations Center. The second mapping will be to convert Operations Center’s authentication into the authentication for the target master.
Cluster-wide Triggers and Authentication Mapping
To be able to trigger a job on a target master, the user and the mapped authentication must have the required permissions:
Authentication mapping also takes place for requests originating from Operations Center to Client Masters, such requests will be mapped once.
Cluster Operations and Authentication Mapping
When running a cluster operation that has been configured as a job on Operations Center, on a default installation of Operations Center the defined cluster operation will run using the SYSTEM authentication. It is expected that the Operations Center administrator will either: * restrict the BUILD permission on the cluster operation to those users that are permitted to perform the operation; or * install the Authorize Project plugin on Operations Center and configure the job to run with the appropriate authentication
Because ad-hoc cluster operations do not have a ‘job’ against which to either configure the project authorization or control the permissions Operations Center provides a built-in authorization for ad-hoc cluster operations. When running an ad-hoc cluster operations from Operations Center the authentication of that ad-hoc cluster operation will always be tagged with the authentication of the user triggering the ad-hoc operation.
Authorize Project plugin and Credentials
When using the Authorize Project plugin the credentials available to the job may be different from when the job runs as SYSTEM.
By default, if the authentication that the build is running as has the Job/Build permission then the credentials should include all those credentials within the scope of the build job and also include any credentials defined in that user’s personal credential store.
There are two system properties that enable additional permissions to control the credentials available:
Enabling the Credentials/UseOwn and Credentials/UseItem permissions should (assuming that the plugins using the credentials are using the credentials API correctly) allow fine grained control over what credentials a job has access to when using the Authorize Project plugin (or any other plugin that provides authorization for jobs)
The available authentication mapping strategies depends on how you have configured the Client master security on Operations Center:
With Do not enforce security settings on masters there is no guarantee that the Client Master is even using the same security realm. As such a username
johnmay refer to different users. In some cases it may be possible to map, for example, an user-id to/from an email address. Alternatively there may be a few specific users that the Operations Center administrator is prepared to define static mappings for.
With either Single Sign-On (security realm only) or Single Sign-On (security realm and authorization strategy) we have a guarantee that the Client Master is using the same security realm and thus the usernames can be mapped.
The strategies are then broken down in terms of the level of trust the Operations Center administrator is prepared to forward to the Client Master.
The highest level of trust assumes that the SYSTEM authentication of the Client Master can act as SYSTEM on Operations Center.
An intermediate level of trust would be where the administration of a client master has been delegated to some of that Client Master’s users. Those users would thus have Jenkins/Administer on the Client Master but not on Operations Center. As such they could use their super-user permissions as a route to gain additional permissions on Operations Center. By selecting an authentication mapping that maps SYSTEM when coming from the Client Master into ANONYMOUS the Operations Center administrator can effectively remove the risk. Typically with this mapping the user authentication can be trusted and thus an idempotent mapping of usernames (if the security realms are equivalent) would be appropriate.
The lowest level of trust is to map all authentication coming from the Client Master to the ANONYMOUS authentication. This level of trust is appropriate when the Client Master integrity is unknown to the Operations Center administrator. For example, where a skunkworks project team wants their client master connected to Operations Center and the Operations Center administrator does not know what plugins that team will be installing.
When selecting any strategy other than the highest level of trust, it is almost guaranteed that you will need to install the Authorize Project plugin or an equivalent plugin on all Client Masters as well as on Operations Center if any inter-Client Master operations will be required.
This is because the build jobs will be running as SYSTEM and when their authentication is mapped through Operations Center that will be converted to ANONYMOUS which more than likely does not have the required permissions on the target Client Master.
Changing the authentication mapping strategy
The authentication mapping is installed into the remoting channel as the very first step of establishing the remoting connection between the client and Operations Center.
For security reasons the authentication mapping of a connection cannot be updated while the connection is active.
If you reconfigure the authentication mapping, the new authentication mapping will only be picked up once the Client Master has been disconnected from and reconnected to Operations Center.