Infrastructure security

On this page

Infrastructure Administration
Required access rights during execution
Access rights for customer applications

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

Component	Requires Root	Justification
Apache Mesos	Yes	Manages system resources, schedules Docker containers.
Marathon	Yes	Mesos framework scheduling components such as Castle, CJOC, 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 `1000` and customizable.
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 `1000`. Can be customized if needed in order to accommodate NFS mounts (if applicable). See `volume_user` and `volume_group` configuration attributes for more information.
Managed Master	No	Runs as uid `1000`. Can be customized if needed in order to accommodate NFS mounts (if applicable). See `volume_user` and `volume_group` configuration attributes for more information.

Apache Mesos

Yes

Manages system resources, schedules Docker containers.

Marathon

Yes

Mesos framework scheduling components such as Castle, CJOC, 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 1000 and customizable.

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

Runs as uid 1000.

Can be customized if needed in order to accommodate NFS mounts (if applicable).

See volume_user and volume_group configuration attributes for more information.

Managed Master

Runs as uid 1000.

Can be customized if needed in order to accommodate NFS mounts (if applicable).

See volume_user and volume_group configuration attributes for more information.

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.