Authentication, Authorization, and Folder Roles

Scenario: A correct login is followed by an over-broad item regex that exposes another team's deployment job.

"Logged in" and "allowed to do this" are two separate checks

A very common beginner confusion is treating "I can log into Jenkins" and "I'm allowed to do this specific thing" as the same fact. They're deliberately not. Jenkins splits this into two distinct systems working together: figuring out who you are (authentication) and figuring out what you're allowed to do (authorization) - and mixing these up is a real source of security misconfigurations.

Analogy: Think of a large office building again. Showing your ID badge to the security guard at the front door (authentication) proves you're a legitimate employee - but it doesn't automatically mean every door in the building unlocks for you. Whether you can actually get into the finance department's records room (authorization) depends on a completely separate system: your badge's specific access-control permissions, checked door by door. Being let in the front door and being allowed into every room are not the same thing, and Jenkins keeps these exactly as separate as a real badge-access system does.

Getting comfortable with this split - realm (who) versus authorization strategy (what) - makes the rest of this section's regex and permission details much easier to reason about.

Pipeline example

// Overall/Read permits entry; folder Item permissions
// decide which jobs the identity may use.

Authentication and authorization are genuinely different systems

A security realm establishes identity - through an identity provider (IdP), LDAP, local Jenkins user accounts, or a trusted reverse proxy (as used on this platform). Authorization then grants specific permissions on top of that established identity: Overall/Read or Overall/Administer, and item-level permissions like Item/Read, Item/Build, Item/Configure, Item/Delete, Run/Replay, Item/Workspace, Agent/, View/, and Credentials/. Matrix authorization grants permissions directly per user or group; role-based strategies usually bind whole permission sets to a regex pattern matching item names, which is what's used to give each learner on this platform access to only their own folder. Being successfully authenticated only gets someone in the door - they still need the specific* permissions required for whatever they're trying to do inside their own folder.

Regex patterns are a security detail, not a formatting detail

The exact regex pattern used to anchor a role matters enormously. A pattern meant to grant a team access to everything under team-a should be anchored like ^team-a($|/.)$ and then tested* against both team-admin (should not match - a different, similarly-named item) and any nested job inside team-a (should match). Item/Configure is effectively code-execution authority, because whoever holds it can alter Pipeline steps - including adding a step that binds a credential they shouldn't otherwise have access to. Run/Replay and the ability to modify a trusted shared library are similarly powerful, for the same reason. Overall/Read lets someone into Jenkins at all, but it does not by itself justify visibility into every item or every credential on the controller.

$ curl -u learner1 https://jenkins.internal/job/u-team-a2/
HTTP/1.1 403 Forbidden

$ curl -u learner1 https://jenkins.internal/job/u-team-a/
HTTP/1.1 200 OK

This is exactly the kind of test worth running deliberately: a similarly-named neighbor folder (u-team-a2) correctly returns 403, while the actual intended folder (u-team-a) returns 200 - proving the regex anchoring is doing its job and not accidentally matching a lookalike name.

Verify from a non-administrator's seat

Administrators bypass many ordinary denial paths by design, so testing as an administrator will never reveal a permission gap that only affects regular users - you have to log in (or script requests) as a representative, ordinary test identity. Attempt listing folders, reading configuration, triggering a build, configuring a job, replaying a run, viewing a workspace, binding a folder credential, and reaching into a neighboring folder - all as that test identity, not as yourself. Preserve one audited, strongly-authenticated emergency administrator path, rather than giving broad administrative rights to daily-use accounts "just in case."

A pitfall: trusting a header that wasn't actually verified

When a reverse proxy supplies identity headers (as covered in the shared-platform section), Jenkins must accept that traffic only from the known, trusted proxy's network address, and must strip any copy of those same headers a client tried to supply directly to the controller - otherwise a malicious request could simply set its own "I am admin" header and skip authentication entirely, a real and serious class of vulnerability in reverse-proxy setups generally, not unique to Jenkins. Review group membership and role assignments with the same scrutiny as reviewing a code change, since a role misconfiguration is functionally a security bug. A genuinely least-privilege rule should be able to explain, for each permission it grants, why that permission exists - and should come with a repeatable negative test proving that a similarly-named neighboring resource stays correctly inaccessible.

Goal: Practice the concrete behavior in jenkins-credentials-binding. Learn sections have no Jenkins terminal; the Jenkins lab opens the real shared service in a new full-screen tab inside your private folder.