Least privilege in Jenkins has four parts: grant users only the permissions their role needs, keep builds off the controller, store credentials where only the right jobs can see them, and give each credential minimal rights in the system it opens. Most Jenkins incidents get worse because one of these four was left wide open.
Why does the default need hardening?
Jenkins documents that anonymous users have no permissions by default but, in the default authorization setup, logged-in users have full control. That suits a laptop and not a team server. The Jenkins security guide recommends a security realm backed by your directory, such as Active Directory or LDAP, plus a finer-grained authorization strategy like Matrix Authorization Strategy. It also warns that granting Overall/Administer to anonymous is similar to "Anyone can do anything".
Which permissions should each role get?
Think in roles, not people. A constructed layout:
- Developers: Job/Read, Job/Build, Job/Workspace on their team's folder only.
- Team leads: add Job/Configure in that folder.
- Release engineers: Job/Build on the release folder, plus Credentials/Use there.
- Platform admins: Overall/Administer, held by two or three named accounts, never shared.
- Everyone else: Overall/Read at most.
Folders are the practical unit. Permissions and credentials can be set on a folder so a team administers its area without touching others. A role-based plugin helps once matrix rows get long.
Where should builds run?
Not on the controller. The controller holds credentials, job configuration and the keys that decrypt them. Jenkins controller isolation guidance says to select the Built-In Node, set its number of executors to 0, and run builds on separate agents or clouds. A build that executes on the controller runs as the Jenkins process user and can read what that user can read.
Use ephemeral agents where you can, so a compromised job leaves nothing behind for the next one.
How do credentials stay narrow?
Jenkins stores credentials encrypted on the controller and, in Pipeline projects, hands them around by credential ID so users do not see the values. That helps, but access to a job that can use a credential is access to the credential: a pipeline can send it anywhere. So scope matters.
Place a credential in the folder that needs it, not in the global store. Give it a descriptive ID and one purpose. Restrict who can create credentials, since the Credentials/Create permission lets a user add and configure them, and restrict who can edit pipelines that consume sensitive ones. Mask secrets in logs, and remember masking is a courtesy, not a boundary: a script can transform the value and print it.
What about the tokens inside those credentials?
This is the half teams skip. A Jenkins credential holding a GitHub token, cloud key or registry password is only as safe as that token's own scope. Create each with the least rights the job needs: read-only repo access for build jobs, push access to one registry path for the publish job, a deploy role limited to one environment. Prefer short-lived tokens issued at run time to long-lived static keys, and rotate the rest on a schedule. Give Jenkins user API tokens to a service account per integration, not a person's account, so offboarding does not break builds and a leak points to one integration.
What to do
- Replace "logged-in users can do anything" with matrix or role-based authorization.
- Connect Jenkins to your directory and remove local shared accounts.
- Reserve Overall/Administer for a few named admins.
- Set the controller's executors to 0 and build on agents.
- Move credentials into folders and limit Credentials/Create and Use.
- Reissue every token with the narrowest scope, and set an expiry or rotation date.
- Use service accounts for integrations and API tokens.
- Review plugins and keep them patched, since many Jenkins advisories are plugin issues.
- Audit permissions quarterly.
Quick check
Do masked credentials protect against a malicious pipeline?
No. Masking hides the exact string in logs. Anyone who can change a pipeline that uses the credential can still exfiltrate it, so limit who can edit those jobs.
Is setting controller executors to 0 enough on its own?
It is an important step, but not sufficient. You also need scoped credentials, restricted permissions and patched plugins.
Sources
Last reviewed: 18 October 2026.
