By default Operator Service for Jenkins® performs an initial security hardening of Jenkins instance via groovy scripts to prevent any well-known security gaps.

Jenkins Access Control

Currently the Operator Service for Jenkins generates a username and a random password and stores them in a Kubernetes Secret. However any other authorization mechanisms are possible and can be done via groovy scripts or configuration as code plugin. For more information take a look at getting-started#jenkins-customization.

Any change to Security Realm or Authorization requires that user called operator-service must have admin rights because the Operator Service for Jenkins calls Jenkins API.

Jenkins Hardening

The list below describes all the default security setting configured by the Operator Service for Jenkins:

  • basic settings - use Mode.EXCLUSIVE - Jobs must specify that they want to run on controller node
  • enable CSRF - Cross Site Request Forgery Protection is enabled
  • disable usage stats - Jenkins usage stats submitting is disabled
  • enable controller access control - Agent to Controller Access Control is enabled
  • disable old JNLP protocols - JNLP3-connect, JNLP2-connect and JNLP-connect are disabled
  • disable CLI - CLI access of /cli URL is disabled
  • configure kubernetes-plugin - secure configuration for Kubernetes plugin

Jenkins API

The Operator Service for Jenkins generates and configures Basic Authentication token for the Jenkins Go client and stores it in a Kubernetes Secret.


Kubernetes API permissions are limited by roles specified here.

Since the Operator Service for Jenkins must be able to grant permission for its deployed Jenkins controller to spawn pods (the Jenkins Master role), the operator itself requires permission to create RBAC resources (the Operator role).

Deployed this way, any subject which may create a Pod (including a Jenkins job) may assume the operator-role role by using its' ServiceAccount, create RBAC rules, and thus escape its granted permissions. Any namespace to which the Operator Service for Jenkins is deployed must be considered to implicitly grant all possible permissions to any subject which can create a Pod in that namespace.

To mitigate this issue Operator Service for Jenkins should be deployed in one namespace and the Jenkins CR should be created in separate namespace. See Separate Namespaces for details on that subject.

Report a Security Vulnerability

If you find a vulnerability or any misconfiguration in Jenkins, please report it.