Jenkins Security and User Management

A Jenkins server with no security configured is a risk to your entire infrastructure. Anyone who reaches the URL can run arbitrary commands on your build servers. Proper security configuration locks down access, controls what each user can do, and protects sensitive credentials.

Think of Jenkins security like the access control system in an office building. A visitor badge gets you to the lobby. An employee badge gets you to your floor. An IT badge gets you to the server room. Everyone has exactly the access they need — no more.

The Security Warning: Enable Security First

Fresh Jenkins installations may run with security disabled. Check this immediately after installation.

Go to: Manage Jenkins → Security
Enable security: ✓ (must be checked)
Security Realm: Jenkins' own user database
Authorization: Matrix-based security (or Role-based strategy)
Save

Never leave Jenkins accessible on a network with security disabled. The built-in Groovy console allows executing any command on the server as the Jenkins system user.

Security Realm: Who Can Log In

The Security Realm answers the question: how do users prove their identity? Jenkins supports several options.

Authorization: What Each User Can Do

Authorization answers: once a user is logged in, what are they allowed to do? Jenkins provides several authorization strategies.

Strategy 1: Matrix-Based Security

A permission grid where you grant specific permissions to individual users or groups. This is the most flexible option for small to medium teams.

Matrix-based security example:

  Permission         | anonymous | developer | qa-team | admin
  -------------------|-----------|-----------|---------|-------
  Overall/Read       |     ✓     |     ✓     |    ✓    |   ✓
  Job/Build          |           |     ✓     |    ✓    |   ✓
  Job/Configure      |           |           |         |   ✓
  Job/Create         |           |     ✓     |         |   ✓
  Job/Delete         |           |           |         |   ✓
  Credentials/Create |           |           |         |   ✓
  Credentials/View   |           |     ✓     |    ✓    |   ✓
  Manage Jenkins     |           |           |         |   ✓

Anonymous = not logged in
developer = members of the dev team
qa-team   = QA engineers
admin     = administrators only

Strategy 2: Role-Based Access Control (RBAC)

The Role Strategy plugin lets you define named roles and assign users to them. This scales better for large teams because you manage roles, not individual users.

Roles defined in Jenkins:

  Role: developer
    Permissions: Job/Build, Job/Read, Job/Workspace

  Role: release-manager
    Permissions: Job/Build, Job/Read, Job/Configure, Credentials/View

  Role: admin
    Permissions: All permissions

  Role: viewer
    Permissions: Overall/Read, Job/Read only

Users assigned to roles:
  alice   → developer, release-manager
  bob     → developer
  charlie → viewer (external stakeholder)
  diana   → admin

Project-Level Roles

RBAC also supports project-level roles. A developer can have full access to their team's jobs but read-only access to other teams' jobs.

Pattern-based project role:

  Role: frontend-developer
    Job Pattern: frontend-.*   (matches: frontend-build, frontend-deploy, etc.)
    Permissions: Job/Build, Job/Read, Job/Configure

  Role: backend-developer
    Job Pattern: backend-.*
    Permissions: Job/Build, Job/Read, Job/Configure

  alice (frontend developer):
    Global role: viewer (read-only everywhere)
    Project role: frontend-developer (full access to frontend jobs only)

Creating and Managing Users

Create a user:
  Manage Jenkins → Users → Create User
  Fill: username, password, full name, email

View all users:
  Manage Jenkins → Users

Delete a user:
  Manage Jenkins → Users → [user] → Delete

Reset a user's password:
  Manage Jenkins → Users → [user] → Configure
  Enter new password → Save

Users can also self-register if you enable that option
in the Security Realm settings (not recommended for production).

API Tokens for Automation

API tokens let scripts and external tools authenticate with Jenkins without using a password. Each user generates their own token.

Generate an API token:
  Log in as that user
  Click your username (top right) → Configure
  Under "API Token" → Add new Token
  Give it a name → Generate
  Copy the token immediately — it is shown only once

Use the token:
  curl -u username:api-token http://jenkins:8080/job/my-job/build
  curl -u alice:1136ab7cd8ef901234 http://jenkins:8080/api/json?pretty=true

Revoke a token:
  Same page → Click the X next to the token → Save

Securing the Jenkins Controller

Disable the Built-In Node

The Jenkins controller should not run builds. Set its number of executors to zero so all builds run on dedicated agents.

Manage Jenkins → Nodes → Built-In Node → Configure
Number of executors: 0    ← Change from default (2) to 0
Save

Content Security Policy

Jenkins serves build artifacts and HTML reports. Browsers may execute scripts in those files. Set a Content Security Policy header to prevent this.

Manage Jenkins → Script Console

System.setProperty(
    "hudson.model.DirectoryBrowserSupport.CSP",
    "sandbox; default-src 'none'; img-src 'self'; style-src 'self';"
)

CSRF Protection

Cross-Site Request Forgery (CSRF) protection is enabled by default. Keep it enabled. It prevents malicious websites from triggering Jenkins actions in a logged-in user's browser.

Manage Jenkins → Security
✓ Prevent Cross Site Request Forgery exploits (keep this checked)
Crumb Algorithm: Default Crumb Issuer

Audit Logging

The Audit Trail plugin logs every action in Jenkins — who built what, who changed configuration, who added credentials. This is essential for compliance and troubleshooting.

Install: Audit Trail plugin
Configure: Manage Jenkins → System → Audit Trail
Log Location: /var/log/jenkins/audit.log
Log File Count: 5
Log File Size MB: 100

Sample audit log entries:
  2024-05-10 14:32:11  alice    Started build: order-service #45
  2024-05-10 14:35:22  alice    Approved deployment: order-service #45
  2024-05-10 14:40:05  bob      Changed configuration: payment-service
  2024-05-10 14:55:17  diana    Added credential: prod-deploy-key

Security Best Practices Summary

✓ Enable security immediately after installation
✓ Use LDAP or SSO instead of local accounts for large teams
✓ Use Role Strategy plugin to manage permissions at scale
✓ Set controller executors to 0 — never run builds on the controller
✓ Store all secrets in Jenkins Credentials — never in Jenkinsfiles
✓ Keep Jenkins and all plugins updated
✓ Enable CSRF protection
✓ Install Audit Trail plugin for compliance logging
✓ Use HTTPS — never expose Jenkins over plain HTTP on a network
✓ Restrict the Jenkins UI behind a firewall or VPN
✓ Grant minimum necessary permissions to each user or role

Key Points

• Enable security immediately — an unsecured Jenkins instance can execute commands on your infrastructure.
• The Security Realm controls who can log in. Use LDAP or SAML SSO for enterprise environments.
• Matrix-based security and the Role Strategy plugin control what each user can do.
• API tokens let automation scripts authenticate with Jenkins without sharing passwords.
• Set controller executors to zero, enable CSRF protection, and install Audit Trail for a secure production setup.