Configuration as code (JCasC)

A reproducible, reviewable Jenkins.

Intermediate12 min · lesson 14 of 15

A Jenkins configured by clicking through the UI is a snowflake — its settings live only in JENKINS_HOME, undocumented and unreproducible, and rebuilding it means remembering every checkbox. Configuration as Code (the JCasC plugin) fixes that: it describes the entire Jenkins configuration — security realm, agents, credentials providers, tools, plugin settings — in a single YAML file you keep in version control.

jenkins.yaml
jenkins:
numExecutors: 0 # no builds on the controller
securityRealm:
local:
allowsSignup: false # no self-registration
authorizationStrategy:
roleBased: { roles: { global: [] } }
security:
scriptApproval:
approvedSignatures: [] # nothing pre-approved
unclassified:
location:
url: "https://jenkins.acme.internal/"

Reproducible and reviewable

With JCasC, standing up a fresh Jenkins is applying a file, not a day of clicking — and every configuration change goes through a pull request, so you can see who changed the security settings and when. That review trail is itself a security control: no more silent UI edits that loosen authorization or add a credential without anyone noticing. The YAML is the source of truth; the running instance is derived from it.

terminal
# point Jenkins at the config file (env var), and it applies on boot / reload
$ docker run -d --name jenkins \
-e CASC_JENKINS_CONFIG=/var/jenkins_home/jenkins.yaml \
-v jenkins_home:/var/jenkins_home \
jenkins/jenkins:lts-jdk17
Keep secrets out of the JCasC file
The config YAML lives in Git, so it must not contain plaintext credentials — reference them with variable interpolation (${SECRET}) resolved from environment variables or a secrets file at boot, never inline. JCasC describes the shape of your Jenkins; the actual secret values still come from the credentials store or an injected environment.