Lesson content
Read, practise, then check your understanding
Security and User Management
Jenkins often has access to source code, signing material, production systems, and deployment credentials. Its security model combines a security realm for authentication, an authorization strategy for permissions, protected credentials, request defenses, and operational controls.
Core ideas
- Integrate a maintained identity provider and require strong authentication for administrators.
- Role-based or matrix authorization should follow least privilege and separate administration from job use.
- Credentials should be scoped, rotated, audited, and bound only around the step that consumes them.
- Agent connections and network placement must reflect workload trust because agents execute repository-controlled commands.
How it works
Disable anonymous capabilities unless explicitly required, use TLS, protect administrative endpoints, keep CSRF defenses enabled, and create API tokens instead of reusing passwords. Review who can configure jobs: pipeline authors can often cause credentials available to a job to be used.
Configuration example
pipeline {
agent any
stages {
stage('Publish') {
steps {
withCredentials([string(credentialsId: 'registry-token', variable: 'TOKEN')]) {
sh '''
set +x
./publish.sh "$TOKEN"
'''
}
}
}
}
}
The sample is intentionally small. In a real installation, replace hostnames, labels, credentials, retention, and commands with reviewed values from your own platform standards.
Production guidance
- Never print, archive, or interpolate credential values into Groovy command strings.
- Audit permission and credential changes, plugin installation, script approvals, and failed logins.
- Patch promptly, segment the controller, and maintain a tested incident response and rotation procedure.
The chapter quiz follows this lesson and tests both terminology and safe operating choices.
Knowledge check
Answer every question correctly to complete this chapter.
0 of 10 checks passed
Your progress is saved on this device.