Chapter 26: Jenkins Security, RBAC and Hardening

26.1 Why this chapter is a checklist

By Ravindra Bagale · Last updated: 25 October 2026

Why: the problem

Think of Paytm. Every payment app build goes through one Jenkins. That Jenkins can read the source code. It holds the AWS keys, the Play Store signing key and the database passwords. It can run any shell command on its agents. Now imagine that Jenkins opens with no login page. Anyone on the office Wi-Fi can open it. They can click Configure on a job and add one shell line. That line runs on the agent with all the keys. This is not a story from a film. Every year, security teams scan the internet and find thousands of open Jenkins dashboards. So the first rule of Jenkins security is simple. Jenkins is a remote command runner with your secrets inside. Treat it like a production server, not like a toy. In this lesson you will find out how open your lab Jenkins is right now, turn on login, and write the first five lines of a hardening checklist. The rest of the chapter fills in each line.

What we will build

You will start a fresh Jenkins in Docker. You will check, as an outsider, what an anonymous person can see. You will use curl to ask the Jenkins API questions without logging in. Then you will turn on the security realm and authorization, and repeat the same checks. At the end you will have a small script called open-check.sh that prints PASS or FAIL for five basic checks. You will run this script again at the end of the chapter.

What: every term in plain English

• Controller — The main Jenkins server. It shows the web page, keeps job settings and sends work to agents.
• Agent — A machine that runs the build steps. It gets commands from the controller.
• Anonymous user — Anyone who opens Jenkins without logging in.
• Security realm — How Jenkins checks who you are. For example its own user list, LDAP or Google login.
• Authorization strategy — What a logged-in person may do. For example read only, build, or configure.
• Attack surface — All the doors someone could try to open. Fewer doors means less risk.
• Hardening — Closing doors you do not need and locking the ones you keep.
• Least privilege — Give each person only the rights they need for their work. Nothing more.

How: step by step

1. Start a fresh lab Jenkins

   docker volume create jh26 && docker run -d --name j26 -p 8080:8080 -v jh26:/var/jenkins_home jenkins/jenkins:lts-jdk17
   

   What it does: A new Jenkins controller in a container.

   Output

   3f9c1b0e7a2d...
   

2. Read the first admin password

   docker exec j26 cat /var/jenkins_home/secrets/initialAdminPassword
   

   What it does: Jenkins makes a one-time password for the setup wizard.

   Output

   a3f1c9d07b2e4f6a8c1d2e3f4a5b6c7d
   

3. Finish the wizard

   Open http://localhost:8080 > paste password > Install suggested plugins > Create First Admin User: ravi
   

   What it does: The wizard turns on login with the Jenkins own user database.

   Output

   Jenkins is ready!
   

4. Check as an outsider

   curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8080/api/json
   

   What it does: Asks for the job list with no login.

   Output

   403
   

5. Look at the security page

   Manage Jenkins > Security
   

   What it does: See which realm and authorization are active.

   Output

   Security Realm: Jenkins own user database
   Authorization: Logged-in users can do anything
   

6. Turn off "Allow anonymous read access"

   Manage Jenkins > Security > Authorization > untick Allow anonymous read access > Save
   

   What it does: Outsiders get the login page, not the dashboard.

   Output

   Saved
   

7. Write the first checklist lines

   nano hardening.md
   

   What it does: Five lines: login on, signup off, anonymous no read, executors on controller 0, plugins updated.

   Output

   (file saved)
   

Example 1: Prove what an anonymous person can see, with only curl

Stack. bash, curl, Jenkins LTS in Docker

Goal. Prove what an anonymous person can see, with only curl.

open-check.sh

#!/usr/bin/env bash
# Usage: bash open-check.sh http://localhost:8080
set -uo pipefail
J="${1:-http://localhost:8080}"
code() { curl -s -o /dev/null -w "%{http_code}" "$J$1"; }
check() {
  local name="$1" path="$2" want="$3"
  got=$(code "$path")
  if [ "$got" = "$want" ]; then echo "PASS $name ($got)"; else echo "FAIL $name (got $got, want $want)"; fi
}
check "dashboard needs login"   "/api/json"            403
check "script console closed"   "/script"              403
check "people list closed"      "/asynchPeople/api/json" 403
check "signup page closed"      "/signup"              404
check "cli over http closed"    "/cli"                 403

What each line does

• set -uo pipefail — Stop on unset variables and catch failures in pipes. No -e, so one FAIL does not stop the other checks.
• curl -s -o /dev/null -w "%{http_code}" — Throw away the page and print only the HTTP status number.
• /api/json — The job list as JSON. Open Jenkins answers 200 here. Locked Jenkins answers 403.
• /script — The script console. It runs Groovy on the controller. It must never be open.
• /signup — The self signup page. 404 means signup is turned off.
• check "name" "path" want — Compares the real status with the status we want and prints PASS or FAIL.

Green output

$ bash open-check.sh http://localhost:8080
PASS dashboard needs login (403)
PASS script console closed (403)
PASS people list closed (403)
PASS signup page closed (404)
PASS cli over http closed (403)

Expected result. All five checks pass on a Jenkins that finished the wizard. Run it on any Jenkins you are given on day one.

Example 2: See the danger: the same script on an old, open Jenkins

Stack. Docker, Jenkins LTS

Goal. See the danger: the same script on an old, open Jenkins.

open-jenkins.sh

#!/usr/bin/env bash
# LAB ONLY. Start a Jenkins with the setup wizard skipped and no security.
set -euo pipefail
docker run -d --name jopen -p 8081:8080 \
  -e JAVA_OPTS="-Djenkins.install.runSetupWizard=false" \
  jenkins/jenkins:lts-jdk17
sleep 40
bash open-check.sh http://localhost:8081

What each line does

• -Djenkins.install.runSetupWizard=false — Skips the wizard. Old guides use this. It leaves Jenkins with no login at all.
• -p 8081:8080 — Second Jenkins on port 8081, so it does not clash with the first one.
• sleep 40 — Jenkins needs some seconds to start.
• bash open-check.sh http://localhost:8081 — Same five checks, now on the open one.
• LAB ONLY — Never run this on a server with a public IP address.

Green output

FAIL dashboard needs login (got 200, want 403)
FAIL script console closed (got 200, want 403)
FAIL people list closed (got 200, want 403)
PASS signup page closed (404)
FAIL cli over http closed (got 200, want 403)

Expected result. Four FAILs. Anyone who can reach port 8081 can open the script console and run commands as the jenkins user. Delete this container now: docker rm -f jopen.

Example 3: Put Jenkins behind nginx with HTTPS, so passwords never travel in plain text

Stack. nginx, certbot, Jenkins on EC2 (Ubuntu 22.04)

Goal. Put Jenkins behind nginx with HTTPS, so passwords never travel in plain text.

/etc/nginx/conf.d/jenkins.conf

server {
  listen 443 ssl http2;
  server_name jenkins.shop-lab.in;
  ssl_certificate     /etc/letsencrypt/live/jenkins.shop-lab.in/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/jenkins.shop-lab.in/privkey.pem;
  location / {
    proxy_pass         http://127.0.0.1:8080;
    proxy_set_header   Host $host;
    proxy_set_header   X-Forwarded-Proto https;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}
server {
  listen 80;
  server_name jenkins.shop-lab.in;
  return 301 https://$host$request_uri;
}

docker run line

docker run -d --name j26 -p 127.0.0.1:8080:8080 \
  -v jh26:/var/jenkins_home jenkins/jenkins:lts-jdk17

What each line does

• listen 443 ssl http2 — nginx takes HTTPS on port 443.
• ssl_certificate ... — Free certificate from Let us Encrypt, made with certbot.
• proxy_pass http://127.0.0.1:8080 — nginx passes the request to Jenkins on the same machine.
• X-Forwarded-Proto https — Tells Jenkins the user came over HTTPS, so links it makes use https.
• return 301 https://... — Anyone who types http is sent to https.
• -p 127.0.0.1:8080:8080 — Jenkins listens only on the local machine. The internet can reach it only through nginx.

Green output

$ curl -I http://jenkins.shop-lab.in
HTTP/1.1 301 Moved Permanently
Location: https://jenkins.shop-lab.in/
$ curl -sI https://jenkins.shop-lab.in/login | head -1
HTTP/2 200
$ curl -s -o /dev/null -w "%{http_code}\n" http://SERVER_IP:8080/
000

Expected result. Port 8080 is not reachable from outside (000 means no answer). The login page works on HTTPS. Also set Manage Jenkins > System > Jenkins URL to https://jenkins.shop-lab.in/.

Verify: did it work?

1. Run the checker again

   bash open-check.sh http://localhost:8080
   

   What it does: All lines should say PASS.

   Output

   PASS dashboard needs login (403)
   ...
   PASS cli over http closed (403)
   

2. Confirm the security realm

   curl -s -u ravi:$JENKINS_TOKEN http://localhost:8080/whoAmI/api/json | jq .authorities
   

   What it does: Shows you are logged in and authenticated.

   Output

   [
     "authenticated"
   ]
   

When it is red 1

Dashboard opens without a login page

Cause. Setup wizard was skipped, or "Allow anonymous read access" is ticked.

Fix, step by step

1. Manage Jenkins > Security.
2. Pick Jenkins own user database.
3. Untick Allow anonymous read access.
4. Run open-check.sh again.

When it is red 2

HTTP ERROR 403 No valid crumb was included in the request

Cause. You sent a POST with curl but no CSRF crumb or API token.

Fix, step by step

1. Use an API token with -u user:token. Tokens do not need a crumb.
2. Or fetch a crumb from /crumbIssuer/api/json first.

When it is red 3

Locked out: "Invalid username or password" for the only admin

Cause. Password forgotten on a lab Jenkins.

Fix, step by step

1. On a lab only: stop the container.
2. Recreate the volume and start fresh.
3. On a real server, use a second admin account. Always keep two admins.

Cleanup

1. Remove the open Jenkins

   docker rm -f jopen
   

   What it does: The dangerous lab container is gone.

   Output

   jopen
   

2. Keep j26

   docker ps --filter name=j26 --format "{{.Names}} {{.Status}}"
   

   What it does: You will use j26 for the rest of the chapter.

   Output

   j26 Up 12 minutes
   

Practice tasks

Homework: try at home

Recap

• Jenkins runs commands and holds secrets, so treat it as production.
• Security realm decides who you are; authorization decides what you may do.
• Never skip the setup wizard or allow anonymous read.
• Put Jenkins behind HTTPS and do not expose port 8080.
• Use open-check.sh on day one on any Jenkins.

FAQ

Is a Jenkins inside the office network safe without login?

No. Laptops get infected, and insiders make mistakes. Always log in.

Is the script console needed?

Admins use it rarely for fixes. Only admins should ever see it.

Can I use self-signed certificates?

In a lab, yes. On a team server, use a real certificate like Let us Encrypt.

Does a VPN replace login?

No. A VPN is one more lock. Keep login and roles too.

How often should I run the checker?

After every upgrade and every plugin change, and once a month.

Interview questions

1. What is the biggest risk with Jenkins?

   It runs any command and holds secrets. Anyone who can configure a job can run shell on an agent and read credentials.

2. Difference between security realm and authorization?

   Realm is authentication, who you are. Authorization is what you may do.

3. How do you check a Jenkins is not open?

   Call /api/json and /script without login and expect 403. I keep a small curl script for this.

4. Why put nginx in front of Jenkins?

   For HTTPS, a clean domain name, and to keep port 8080 private.

5. What is least privilege in Jenkins?

   Each user gets only the permissions needed for their jobs, usually through roles and folders.

Samajla ka?

Ravi Sir's Cards for this lesson

Revision cardInterview card

मराठी cards