CloudBees Jenkins Enterprise has been built with the assumption that it owns the infrastructure where it is installed. It expects to be able to install and manage software such as Apache Mesos, Marathon, Docker, etc.
| This article applies to CloudBees Jenkins Enterprise 1.x, based on Apache Mesos. CloudBees Jenkins Enterprise 2.x addresses most (if not all) of security concerns by relying on Kubernetes architecture. |
Infrastructure Administration
Any infrastructure operation that is installing (cluster-init), updating (cje upgrade) or collecting information (generating support bundle) require root access.
Required access rights during execution
CloudBees Jenkins Enterprise is composed of a set of components, some of them need root access to fulfill their role.
| Component | Requires Root | Justification |
|---|---|---|
Apache Mesos | Yes | Manages system resources, schedules Docker containers. |
Marathon | Yes | Mesos framework scheduling components such as Castle, operations center, Masters, and Elasticsearch. |
Docker | Yes | The Docker daemon itself needs to run as root. The Docker client currently runs as root. |
Palace | Yes | Mesos framework scheduling build agents containers. |
Castle | Yes | Manages volumes across the cluster. It does cgroups magic in order to dynamically attach volumes to Jenkins containers. |
Logstash | Yes | Requires access to all logs files in order to index them and forward them to Elasticsearch. |
Topbeat | Yes | Monitors system metrics and sends them to Elasticsearch. |
Elasticsearch | Yes | Pending product evolution to run it as uid |
Crons | Yes | Calls Docker for maintenance purpose (removing old containers and images). Since Docker runs as root, this component needs to run as root as well. |
operations center | No | Runs as uid Can be customized if needed in order to accommodate NFS mounts (if applicable). See |
Managed Master | No | Runs as uid Can be customized if needed in order to accommodate NFS mounts (if applicable). See |
Access rights for customer applications
Build agents are scheduled as Docker containers in a dedicated worker pool. These agents run using the uid/gid defined in the
Docker image being called. However, it is possible to override the user to use in the agent template configuration. Under options,
add a new Parameter named user. The value should have the format: <name|uid>[:<group|gid>].
Best practice is to run Docker containers as a non-root user (principle of least privilege). Therefore, it is recommended to create a user with a known uid in the Dockerfile when building Docker images used across the cluster.
For the same reason, it is discouraged to mount the Docker socket (practice known as DonD) in a Docker container or use Docker-in-Docker (DinD). These require privileged mode, which is equivalent to running them directly as root on the host.