Users, Authentication Realms, Authorization Strategies, Matrix Permissions, Folders, and Least Privilege: Guided Hands-On Workflow and Core Operations

1. Scenario and safety boundary

Use a disposable Jenkins controller bound only to 127.0.0.1. Create three synthetic personas: recovery-admin retains administration; dev-builder may read/build jobs under training/dev; auditor may read the training jobs but not build or configure them.

2. Preflight: pin the disposable controller and plugins

Continue the Chapter 02–03 baseline. Build a local image with explicit access-control plugin versions, then record the resolved image identity locally.

FROM jenkins/jenkins:2.568.3-jdk21
USER root
RUN jenkins-plugin-cli --plugins \
    matrix-auth:3.3 \
    cloudbees-folder:6.1106.v3a_d9a_6d2465e \
    credentials:1511.v2e3cb_0008ef0
USER jenkins

docker build -t jenkins-ch04:2.568.3 .
docker volume create jenkins_ch04_home
docker run -d --name jenkins-ch04 \
  -p 127.0.0.1:8080:8080 \
  -v jenkins_ch04_home:/var/jenkins_home \
  jenkins-ch04:2.568.3

docker image inspect jenkins-ch04:2.568.3 --format '{{json .RepoDigests}}'

Complete the setup wizard locally and create recovery-admin as the initial administrator. Keep port 8080 on loopback only.

3. Create synthetic users and isolate sessions

Under Manage Jenkins → Users, create dev-builder and auditor. Use unique disposable passwords. Record usernames and intended roles only; never copy password values into notes or screenshots.

Open three browser profiles/private windows. Keeping identities separate prevents an administrator cookie from contaminating a permission test.

4. Create a folder boundary and harmless jobs

Create training/dev, then Freestyle jobs hello and status. Their steps print only synthetic data. The full names are training/dev/hello and training/dev/status; use full names in evidence.

printf 'job=%s
' "$JOB_NAME"
printf 'build=%s
' "$BUILD_NUMBER"
printf 'node=%s
' "$NODE_NAME"
printf 'workspace=%s
' "$WORKSPACE"
printf 'message=synthetic access-control lab
'

If agents are already available, run these jobs there. Do not make the built-in node a long-term execution target merely to simplify the lab.

5. Configure the least-privilege matrix

In Manage Jenkins → Security, select Project-based Matrix Authorization Strategy. Preserve recovery-admin with Overall/Administer. Give anonymous users no training access. Use only the grants required by the role contract.

Matrix grants are additive; parent/global grants can flow into children. Start narrow, save, then test before adding anything else.

6. Prove allowed and denied actions

If you automate a read-only check with disposable API tokens, store tokens in environment variables and never echo them.

export JENKINS_URL='http://127.0.0.1:8080'
export DEV_USER='dev-builder'
export DEV_TOKEN='<disposable-token-not-logged>'
curl -fsS -u "$DEV_USER:$DEV_TOKEN"   "$JENKINS_URL/job/training/job/dev/job/hello/api/json?tree=fullName,url,buildable"
unset DEV_TOKEN

7. Prove that item visibility is not credential administration

As dev-builder, the user may read/build the training job but should not gain credential-management operations merely because the job is in a visible folder. No real secret is needed. If you create a credential object later, use a fake value and keep it out of logs and screenshots.

Triggering a preconfigured job and modifying the credential store are different capabilities. Grant them separately.

8. Mini challenge

Create training/release/dry-run. Let auditor read both dev and release, let dev-builder build only in dev, and keep release builds denied to dev-builder. Before changing the matrix, write which scope owns each grant and which inherited grant could defeat the design.

9. Summary

You now have an evidence-driven access model: synthetic identities, a preserved recovery administrator, explicit folder scope, project-matrix grants, and both positive and negative tests. The proof is behavior, not a screenshot of checkboxes.

Knowledge check

Official references and version notes

• Jenkins Access Control — authentication via a security realm and authorization via an authorization strategy are separate decisions.
• Jenkins Permissions — current definitions for Overall, Job, Run, View, Credentials, and Pipeline-related permissions.
• Managing Security — realms, authorization modes, matrix security, and controller-wide security settings.
• Matrix Authorization Strategy Plugin — global/project matrices, inheritance modes, and item-configuration caveats.
• Folders Plugin — folder-based item organization used by the scoped-access examples.
• Jenkins Credentials security guidance — credential scope and access minimization.
• Controller Isolation — why users who influence build code must not run routine builds on the built-in node.