I85PREP
⌘ K
CJE study materials
CJE study resources

CJE: User Management, Security, and Access Control

CJE · Work through your exam, one topic at a time.

All guide sections

User Management, Security, and Access Control

What this domain covers

CJE questions here separate two ideas beginners merge: authentication (the security realm that decides who you are) and authorization (the strategy that decides what you may do). You also need the credentials model, CSRF protection, and the controller/agent trust boundary.

Core rules

  • Security realm. Managed under Manage Jenkins → Security: Jenkins' own user database, LDAP, Active Directory, Unix user/group, or delegation to the servlet container. A realm plus an authorization strategy is required once you leave the wizard.
  • Authorization strategies. Anyone can do anything; Legacy mode; Logged-in users can do anything; Matrix-based security; Project-based Matrix Authorization Strategy (per-folder/job ACLs); and Role-Based Strategy from the role-strategy plugin (global, item, and agent roles).
  • Permission names are hierarchical: Overall/Administer, Overall/Read, Job/Read, Job/Build, Job/Configure, Job/Workspace, Run/Update, Agent/Configure, Credentials/View, SCM/Tag. Job/Build does not imply Job/Read, and an explicit deny beats an inherited allow.
  • Credentials plugin stores Username with password, SSH username with private key, Secret text, Secret file, Certificate (PKCS#12) and GitHub App entries. Scope matters: Global credentials are usable by withCredentials; System credentials are only for Jenkins-internal use (agent connection, SCM checkout) and pipelines cannot resolve them. Domains restrict credentials to a folder.
  • Tokens and CSRF. Users create API tokens instead of handing scripts their password. The crumb issuer protects POSTs; enable "Enable proxy compatibility" when a reverse proxy strips headers.
  • Agent → controller access control limits what code running on an agent may call on the controller; the Groovy sandbox and script approval do the same for pipeline code.

Worked example

A platform team wants each squad to see only its own folder. Create a folder per squad, enable Project-based Matrix Authorization Strategy, and on that folder grant the squad group Overall/Read, Job/Read, Job/Build, Job/Workspace, and Credentials/View, keeping Overall/Administer for a small admins group. Reasoning: matrix permissions inherit down folders, so folder-level grants avoid editing every job and prevent squads reading each other's logs or replaying each other's builds.

Traps

Setting an authorization strategy but forgetting the realm (or the reverse) and locking yourself out; assuming "Logged-in users can do anything" is safe because a login exists; expecting withCredentials to resolve a System-scoped credential, which surfaces as "credential not found"; leaving the inbound agent port open with agent-to-controller restrictions disabled.