Users, Authentication Realms, Authorization Strategies, Matrix Permissions, Folders, and Least Privilege: Diagnostics, Failure Modes, Security, and Performance

1. Start with the denied action, not a bigger role

When someone reports “Jenkins access is broken,” identify the exact principal, object, permission, and request. Do not respond by granting Overall/Administer. A correct diagnosis narrows the failure to authentication, missing read prerequisites, wrong scope, inheritance, plugin behavior, or a genuinely missing permission.

2. Evidence-first diagnostic sequence

1. Preserve the original denial message/status and acting identity.
2. Confirm Jenkins core, Java, and authorization-plugin versions.
3. Confirm security realm and authorization strategy.
4. Verify Overall/Read and object Job/Read prerequisites.
5. Inspect global, parent-folder, and item grants plus inheritance.
6. Check plugin-defined permissions or credential scope if involved.
7. Apply the smallest causal change.
8. Retest both the needed action and a nearby action that must remain denied.

The final negative test prevents a common regression: fixing “cannot build” by accidentally granting “can configure and administer.”

3. Failure mode: routine users have Overall/Administer

Overall/Administer implies almost all other Jenkins permissions and enables sensitive administration. If developers only need to build or configure a project, full admin is disproportionate.

Repair: preserve one recovery administrator, define the real job/folder permissions, remove the broad grant from the routine account, then prove the intended build flow still works while admin actions are denied.

4. Failure mode: anonymous or authenticated wildcard grants

anonymous applies to unauthenticated requests. authenticated applies to every logged-in account. Powerful grants to either can expand unexpectedly when network exposure or the security realm changes.

Repair: test an unauthenticated incognito session before/after. Remove unnecessary anonymous grants. Document why every account is trusted if you use broad authenticated grants.

5. Failure mode: relying on a hidden button

UI presentation is not the security boundary. For important denials, test the protected action under the intended identity and verify Jenkins rejects it server-side. Seeing a folder does not prove Build, Configure, or Credentials permissions.

6. Failure mode: locking out all administrators

A bad matrix or realm change can remove the last usable administrator. Jenkins documents emergency procedures to disable access control by editing controller configuration while Jenkins is stopped. That process intentionally starts Jenkins unsecured, so it is an emergency repair only.

For the lab, stop the controller, snapshot JENKINS_HOME, follow the documented recovery procedure if you intentionally simulate lockout, restore a secure admin/matrix, and immediately re-enable access control.

7. Failure mode: Job/Configure plus built-in-node execution

A user may lack Administer yet still control executable job configuration. If builds run on the built-in node, that code shares controller filesystem permissions. Jenkins strongly recommends setting built-in executors to zero and using agents.

Repair: move routine builds to isolated agents and review who has Job/Configure. Permission design and execution isolation are two layers of one trust model.

8. Intentionally broken example: find the causal grant

Observed:
  principal = dev-builder
  object    = controller
  action    = administrative page
  result    = allowed

Inspection:
  global matrix:
    authenticated -> Overall/Administer   # root cause

  folder training/dev:
    dev-builder -> Job/Read, Job/Build    # not the cause

The child folder is not the cause. Because dev-builder is authenticated, the global wildcard grant gives administrative power first. Remove the global Overall/Administer grant from authenticated, preserve recovery-admin, then retest both a legitimate developer build and the denied admin action.

9. Performance and operability

Do not weaken authorization because a matrix “looks large.” The dominant risks are often operability: one-off user rows, stale accounts, unclear inheritance, and ownerless service identities. Prefer stable group-based grants where reliable groups exist, periodic access reviews, and policy-as-code later when ready.

10. Summary

Repair access-control failures by narrowing: identity, object, permission, scope, inheritance, smallest correction, then positive and negative retests. Keep recovery available, but never normalize unsecured mode or full-admin grants as troubleshooting shortcuts.

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.