Users, Authentication Realms, Authorization Strategies, Matrix Permissions, Folders, and Least Privilege: Configuration, Design Choices, and Tradeoffs

1. Access control is architecture, not checkbox collection

A matrix can be syntactically valid and still be a poor system design. The architecture must answer who owns identities, where permissions are granted, how people leave or change teams, how automation authenticates, how emergency administration works, and how policy survives upgrades.

Prefer a small number of explicit trust boundaries. Avoid global grants that compensate for unclear ownership, and avoid extra authorization plugins unless their policy model solves a real requirement.

2. Internal users versus external identity

Authentication and authorization remain orthogonal. An external realm can authenticate users while Matrix Authorization decides permissions. Never assume a realm change preserves the meaning of old group names.

3. Matrix versus role-oriented authorization

Matrix Authorization is direct: principals/groups are rows and permissions are columns, globally or on items. It is explicit but can become large. Role-oriented plugins can introduce reusable roles and resource patterns, but they add a plugin-specific policy language, lifecycle, and migration concern.

4. Global versus folder-scoped rights

Global grants have the widest blast radius and should represent capabilities genuinely needed everywhere. Folder-scoped grants work well when folders correspond to stable ownership. In project-based matrix authorization, permissions are inherited by default from global and parent entities, so a child matrix does not automatically subtract a broad parent grant.

Use stable paths such as teams/payments and teams/search, not transient personal folders, when policy depends on hierarchy. Record full item names because moving items changes context.

5. Why Job/Configure deserves special treatment

Job/Configure is not merely “edit metadata.” It can influence SCM checkout, build steps, Pipeline definition, parameters, triggers, agent selection, and integration settings. Jenkins’ controller-isolation guidance treats people who can configure build code as part of the execution trust model.

If users can configure jobs, keep built-in-node executors at zero, use reviewed agent boundaries, constrain credentials, and understand what executable configuration they can change.

6. Human administrators versus service identities

Human administrators should be individually attributable. Automation identities need their own owner, scope, rotation, and audit trail.

7. Credentials are a separate design axis

Do not use folder permissions as a substitute for credential design. Ask separately: who can manage credentials, which jobs can reference them, who can modify those jobs, and on which agents the credentials can be exposed during execution.

Credential-management authority and job-trigger authority are different risks. Keep both narrow.

8. Worked design: four teams, one controller

9. Change control and rollback

Authorization changes are controller configuration. Capture current state, preserve a tested recovery administrator, take an appropriate backup/snapshot, make one narrow change, and verify under multiple identities. When policy later moves to JCasC, source-of-truth becomes versioned configuration rather than ad hoc UI changes; Chapter 26 covers that architecture.

Jenkins documents an emergency access-control reset, but that intentionally removes protection and belongs only in isolated recovery—not normal administration.

10. Summary

The target is a comprehensible trust model: accountable identities, explicit inheritance, stable ownership folders, tightly controlled Configure authority, separate credential governance, narrow service identities, and a tested recovery path.

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.