Jenkins Fundamentals & Role-Based Access
Run Jenkins in a container, build a job from a webhook, and stop every authenticated user being an administrator.
- Time
- 50 min
- Level
- Beginner
- Objectives
- 4 objectives
- Cost
- Free
Where this fits in the platform
Already built
This lab adds
- A pipeline defined as code rather than clicked in a UI
Which lets you
Before you start
You will need
- Docker
- Docker Compose
You do not need these already — the lab environment below provides them.
You will be able to
- Run Jenkins reproducibly with persistent state
- Trigger a build from a push rather than a button
- Grant permissions by role rather than to everyone
Cost — Free
— Jenkins in Docker on your own machine.
Nothing to pay in the browser. Open the terminal runs this against a simulated cloud — the same API calls and the same commands, with no account and no bill. The figure above applies only if you build it in your own.
The scenario#
Jenkins out of the box gives every authenticated user broad permissions, and its state lives inside a container that will be replaced.
Neither is acceptable, and both are fixed before writing a single pipeline.
Grounded in the iVolve internship labs 21–23, which are procedures that have actually been run rather than assembled from documentation.
Hands-on environment
Run this lab in a real terminal, free and in your browser. The environment is temporary and yours alone — break it as much as you like.
Open the terminalOpens in Killercoda, in a new tab — keep this page open for the steps.
Run it on your own machine
Run this lab on your own machine. One command starts the environment, with everything the lab needs already installed:
You will need:
- docker
git clone https://github.com/EgyKode/EgyKode-lab.git
cd EgyKode-lab
./egykode start cicd
./egykode shellYou need Docker and Git installed. Everything else runs inside the environment. The first start downloads it and takes a few minutes; later starts are seconds.
Not sure what you already have? Run: npm run doctor — it checks and changes nothing.
Anything you tick here is your own record. EgyKode cannot see inside that terminal, so the success criteria stay self-assessed even when the environment checks your work for you.
Jenkins that survives its container
Step 1 of 4
What you are proving: You can run Jenkins so its home survives the container being replaced
Marking this settles success criterion 1.
# compose.yaml
services:
jenkins:
image: jenkins/jenkins:lts-jdk17
ports:
- "8080:8080"
- "50000:50000" # agent port
volumes:
- jenkins_home:/var/jenkins_home
environment:
JAVA_OPTS: "-Djenkins.install.runSetupWizard=false"
volumes:
jenkins_home:docker compose up -d
docker compose exec jenkins cat /var/jenkins_home/secrets/initialAdminPasswordjenkins_home on a named volume is the whole lab in one line. Jobs,
credentials, plugins and build history all live there. Without it, docker compose down destroys your CI server — which is how people end up with a
Jenkins nobody dares upgrade.
What you are proving: You can make a commit trigger a build without anyone pressing a button
Marking this settles success criterion 2.
Install Git and Pipeline plugins, then create a Pipeline job with:
pipeline {
agent any
triggers {
githubPush()
}
stages {
stage('Checkout') {
steps { checkout scm }
}
stage('Build') {
steps { sh 'echo building; ls -la' }
}
stage('Test') {
steps { sh 'echo testing' }
}
}
post {
always { echo "finished: ${currentBuild.currentResult}" }
failure { echo 'notify here' }
}
}For the webhook, GitHub must be able to reach Jenkins. Locally that means a tunnel:
# ngrok, cloudflared, or any tunnel
ngrok http 8080
# then GitHub -> Settings -> Webhooks -> https://<tunnel>/github-webhook/The trailing slash on /github-webhook/ is required. Without it GitHub gets a
404 and the delivery shows red in the webhook's Recent Deliveries — which is the
first place to look when pushes do not trigger builds.
What you are proving: You can create an administrator and a read-only user, and demonstrate that the second cannot start a build
Marking this settles success criteria 3 and 4.
Install Role-based Authorization Strategy, then Manage Jenkins → Security → Authorization → Role-Based Strategy.
Manage and Assign Roles → Manage Roles:
| Role | Pattern | Permissions |
|---|---|---|
admin | — | Overall/Administer |
readonly | — | Overall/Read, Job/Read, Job/Discover |
Create two users under Manage Users, assign one to each, and then verify by logging in as the read-only user:
- The Build Now button is absent, not merely disabled.
Manage Jenkinsdoes not appear.
Verify by logging in, not by reading the matrix. A permissions grid that looks right and behaves differently is the normal case, and the only proof is attempting the action.
What you are proving: You can say why persistence and access control come before pipelines, not after
This step settles no success criterion on its own.
A Jenkins with jenkins_home in a container and every user an administrator
will work perfectly until the day it does not — and then there is no history to
consult and no way to tell who changed what. Both problems are ten minutes of
configuration now and a rebuild later.
The webhook fires but no build starts
The job needs githubPush() in triggers, and the URL must end in /github-webhook/. Check Recent Deliveries in GitHub for the response code.
Locked out after enabling role-based strategy
No user has Overall/Administer. Edit config.xml in jenkins_home to set <useSecurity>false</useSecurity>, restart, and reconfigure.
Plugins disappear after a restart
jenkins_home is not on a volume. Everything Jenkins knows lives there.
sh steps fail with 'command not found'
The tool is not in the container. Either install it in a custom image or run the stage on an agent that has it.
Clean up#
Run this even if you did not finish.
docker compose down
# keep the volume, or remove it with:
docker compose down -vCost of this lab: Free — Jenkins in Docker on your own machine.
Success criteria
0 of 4
The concept behind it
Next up
Lab 44 of 59 on the project path