Operations center uses the standard Jenkins security model. In other words there are two axes to security:
The security realm - which is responsible for identifying the user and reporting on any groups that are defined in the security realm that the user belongs to
The authorization strategy - which is responsible for determining the set of permissions that an identified user has on any specific object within the Jenkins object tree.
There are three modes you can select between with CloudBees Jenkins Operations Center:
All Jenkins client controllers are independent and can chose their own security realms and authorization strategies
All Jenkins client controllers will be forced to delegate their security realm to operations center but can choose their own authorization strategies.
All Jenkins client controllers will be forced to delegate their security realm to operations center and will be forced to use the same authorization strategy configuration as operations center.
Finally, authorization strategies that are operations center-aware (at the time of writing the only such authorization strategy is the CloudBees Role Based Access Control Plugin) can contextualize the authorization strategy configuration of individual client controllers based on the context within operations center that the client controller is defined in.
The following recommendations provide the greatest functionality and flexibility as well as a secure setup:
Select any security realm
Select the CloudBees Role Based Access Control Plugin as the authorization strategy
Select a markup formatter
Enable prevention of cross site request forgery exploits
0on-controller executors as jobs running on a controller to prevent jobs running on the controller from modifying the controller’s configuration
Single Sign-On (security realm and authorization strategy)for the security settings enforcement policy
This option requires that all controllers have a well configured Jenkins URL (in Manage Jenkins > Configure System > Jenkins URL). For more information see Using Single Sign On (SSO).
If you are integrating existing client controllers into operations center, it may be beneficial to allow client controllers to opt-out of the security settings enforcement policy while you decide how to transition their existing configuration to the operations center managed configuration.
Select the appropriate default authentication mapping strategy. If you have different classes of controllers you will want to enable per-controller configuration of authentication mapping. Where all controllers are managed by the operations center administrators then Trusted controller with equivalent security realm is likely appropriate. Selecting Restricted controller with equivalent security realm is appropriate for low risk controllers where the team(s) using the controller have root access to the controller. Select Untrusted controller with equivalent security realm if you have higher risk controllers.
The choice of authentication mapping strategy may affect the ability of some functionality.
For example, a controller that has the Untrusted controller with equivalent security realm will only be able to see other client controllers that are visible to unauthenticated users and the remote job trigger functionality from that controller will only be able to trigger jobs that can be triggered by unauthenticated users.
Configuring the security context in Helm charts
Security contexts are a Kubernetes object that defines permissions or capabilities of pods and containers. The
securityContext setting allows for a more finely grained security configuration. You can configure the
securityContext within the
values.yaml file of the Helm chart as shown below.
securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - all