Skip to content

Securing Jenkins

Overview

Harden a Jenkins controller: authentication, authorisation (matrix / role strategies), credentials store, Cross-Site Request Forgery (CSRF) protection, markup formatting, and isolating builds from the controller.

Credential hygiene in Multibranch and pull request builds is part of security, not an afterthought.

This is a core tutorial in Module 11 · Securing Jenkins of the REBASH Academy Jenkins for Cloud & DevOps Engineers series — written for Cloud, DevOps, Platform, and SRE engineers.

Prerequisites

  • Completed prior modules in this track where linked in frontmatter
  • Git and Docker for lab workflows
  • Running Jenkins LTS from Installing Jenkins LTS when a live controller is required

Learning Objectives

By the end of this tutorial, you will be able to:

  • Distinguish authentication vs authorisation in Jenkins
  • Describe matrix/role-based access patterns at a high level
  • Use the credentials store correctly from Pipeline
  • List CSRF and controller isolation controls

Architecture

This topic’s control points and relationships are shown below.

Securing Jenkins

Theory

What it is

Authentication establishes identity (Jenkins’ own user database, LDAP, SAML, OpenID Connect). Authorisation decides permissions (Anyone can do anything — never for prod — logged-in users, matrix, role-based strategies via plugins). Credentials plugin stores secrets with IDs for Pipeline binding. CSRF protection issues crumbs for state-changing requests. Script security / sandbox limits Groovy. Builds must stay off the built-in node.

Why it matters

Jenkins often holds cloud keys, registry tokens, and production kubeconfigs. A public signup controller or disabled CSRF is an incident waiting to happen. DevSecOps reviews treat controller hardening like any other internet-facing app — plus supply-chain risk from plugins.

How it works

  1. Disable signup; require login for reads in shared controllers as policy dictates.
  2. Configure an authorisation strategy least-privilege for folders/jobs.
  3. Migrate secrets out of jobs into Credentials; audit usages.
  4. Keep CSRF enabled; beware “disable crumbs for CLI” folklore.
  5. Enforce agent-only builds; review Markup Formatter (XSS).

Handbook: Securing Jenkins.

Key concepts and comparisons

Control Purpose
Authn realm Who users are
Authz strategy What they can do
Credentials store Secret material
CSRF crumbs Browser attack mitigation
Agent isolation Protect controller
Script security Groovy safety

Multibranch: separate credential sets for untrusted PR builds.

Common pitfalls

  • “Anyone can do anything” left enabled after a lab.
  • Disabling CSRF to “fix CLI”.
  • Folder credentials exposed to every child PR job unintentionally.
  • Admin accounts shared among the whole department.

Hands-on Lab

Create a workspace for this tutorial.

mkdir -p ~/rebash-jenkins/module-11 && cd ~/rebash-jenkins/module-11

Focus: write a security checklist and unsafe-vs-safe Jenkinsfile snippets

Step 1 – Primary exercise

cat > security-checklist.md << 'EOF'
# Jenkins security checklist
- [ ] No public signup
- [ ] Authz not "Anyone can do anything"
- [ ] CSRF protection enabled
- [ ] Built-in executors = 0
- [ ] Secrets only in Credentials store
- [ ] Admin via SSO/LDAP where possible
- [ ] Untrusted PRs without deploy credentials
EOF
cat > bad-vs-good.md << 'EOF'
Bad:  sh 'curl -u admin:password https://registry/...'
Good: withCredentials([...]) { sh 'echo $TOKEN | docker login ...' }
EOF
grep -E 'CSRF|Credentials|Anyone' security-checklist.md bad-vs-good.md

Step 2 – Confirm checklist coverage

test "$(grep -c '\- \[ \]' security-checklist.md)" -ge 6 && echo 'checklist-ok'

Final cleanup

# Keep ~/rebash-jenkins/ for later tutorials; stop Compose only if you are done with the controller
# docker compose -f ~/rebash-jenkins/module-02/docker-compose.yml down   # optional; omit -v to keep JENKINS_HOME

Validation

  • Lab commands run under ~/rebash-jenkins/module-11/
  • You can explain each Theory section in your own words
  • You used current Jenkins LTS / Pipeline practices where they apply
  • You can describe one production failure mode for this topic

Code Walkthrough

Production practice for Securing Jenkins always combines:

  1. Inspect before you change (status, plan, logs, dry-run)
  2. Prefer reversible, documented changes (Git, Jenkinsfile, JCasC)
  3. Capture evidence (console logs, plan artefacts) for handovers
  4. Prefer current LTS and supported plugins over legacy shortcuts
  5. Least privilege — escalate credentials only when required

Keep runbooks short enough to follow under pressure. Automate checks; keep humans for judgement.

Security Considerations

  • Treat Jenkins credentials and cloud tokens as privileged — never commit them
  • Keep builds off the built-in node; isolate untrusted pull requests
  • Prefer short-lived auth (OIDC-style patterns, scoped RBAC) over long-lived keys
  • Validate blast radius before apply/deploy/delete operations
  • Collect audit logs; limit who can administer the controller

Common Mistakes

Anyone can do anything

Never leave this authorisation mode on a reachable controller.

Disabling CSRF

Fix CLI/auth properly; do not disable CSRF crumbs as a shortcut.

Deploy credentials on untrusted PRs

Split trusted release Pipelines from PR CI.

Best Practices

  • Encode Securing Jenkins changes as code and review them in pull requests
  • Prefer Jenkins LTS and pinned agent/tool versions
  • Keep builds off the controller; use labelled agents
  • Least privilege for credentials and cluster/cloud access
  • Destroy or stop lab resources; keep ~/rebash-jenkins/ notes for the track

Troubleshooting

Symptom Likely cause Fix
Job stuck in queue No matching agent/label or executors busy Check nodes, labels, and executor counts
Checkout / SCM failure Credentials, URL, or permissions Verify credential ID and repository access
Pipeline CPS / script error Syntax, sandbox, or library mismatch Read error line; validate Jenkinsfile; pin library version
Plugin / UI broken after update Incompatible plugin set Restore backup; disable suspect plugin on test controller
Disk full on agent/controller Workspaces or old builds Clean workspaces; trim build retention

Summary

Securing Jenkins is essential for Cloud and DevOps engineers operating Jenkins. Practise the lab until the inspection and change path is muscle memory, then continue the track.

Interview Questions

  1. Authentication versus authorisation in Jenkins?
  2. Where should secrets live?
  3. Why keep CSRF enabled?
  4. How do you limit Multibranch PR access to credentials?
  5. Which controller hardening steps would you verify first on an unknown instance?

Sample answer — question 2

In the Credentials store (global or folder), referenced by ID from Pipeline — never in Jenkinsfile plaintext.

Sample answer — question 5

Signup disabled, authz strategy, CSRF on, built-in executors, plugin currency, and whether the UI is exposed without TLS.

References