This document explains which security settings Operator sets for Jenkins, and how to work with Jenkins access control and Kubernetes RBAC (Role Based Access Control) when using Carthago Operator for Jenkins.

Carthago Operator for Jenkins, by default, performs an initial security hardening of Jenkins instance via groovy scripts to prevent any of the well-known security gaps.

Jenkins Access Control

Currently, Carthago Operator for Jenkins generates a username and a random password and stores them in a Kubernetes Secret.

However, users can configure other authentication and authorization mechanisms with their respective Custom Resources, and with the use of groovy scripts and configuration as code plugin.

For more information, visit authentication and authorization pages of this documentation.

Any change to Security Realm or Authorization requires user called carthago to have admin rights because Carthago Operator for Jenkins calls Jenkins API directly.

Jenkins Hardening

The list below describes all the default security setting configured by Carthago Operator 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

Operator 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 Operator must be able to grant permission for its deployed Jenkins controller to spawn pods (Jenkins Controller role), it itself requires permission to create RBAC resources (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 Operator 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 should be deployed in one namespace and the Jenkins CR should be created in a separate namespace. See Separate Namespaces for details on that subject.

When you install Carthago Operator for Jenkins using Helm, the necessary RBAC resources are created automatically. If you’d like to install Carthago Operator for Jenkins using Helm, visit Installation section