ShellGenius Shared Jenkins Isolation

Scenario: Many learners need authentic UI access without viewing or configuring another learner's work.

Why your Jenkins labs feel private even on a shared server

Every learner on this platform uses the same Jenkins controller - there isn't a separate Jenkins server spun up per person. That might sound like it should mean you can see everyone else's work, but you can't, and understanding how that isolation is built is genuinely useful architecture knowledge, not just platform trivia.

Analogy: Think of a large shared office building with one lobby and one building directory, but each company has its own locked floor. The lobby security desk (the identity proxy) checks your badge once and tells the elevator which floor you're allowed to reach - it never lets you type in a floor number yourself. Your floor (a private Jenkins folder, like u-abc123) contains only your own jobs. The building's cleaning crew, though, still has a master key to every floor for maintenance - similarly, a Jenkins admin (or a process running with high enough privilege inside a shared agent) can still see more than the RBAC UI suggests, which is exactly why "the UI hides other folders" isn't the whole isolation story.

This distinction - what the permission system shows you versus what's technically reachable underneath - is worth understanding early, because it's the difference between "isolation as a nice UI feature" and "isolation as an actual security boundary."

Pipeline example

// Stable proxy identity -> matching folder role
// ^u-abc123($|/.*)

Folder visibility is only one layer of isolation

On a shared service like this one, an identity gateway (a reverse proxy) authenticates a stable learner ID, and Jenkins' own authorization system maps that ID to a private folder. Folder roles need carefully anchored item-name patterns: a pattern meant to match folder u-abc123 must include that folder and everything inside it, without also accidentally matching a similarly-named folder like u-abc1234. Overall/Read permission is what lets someone into Jenkins at all, while Item/Read, Item/Build, Item/Configure, Item/Workspace, and Credentials/* permissions are what actually control whether a specific action is allowed on a specific item. Always test neighboring, similarly-named folders and nested jobs explicitly when setting up a permission pattern - regex mistakes here are a common, subtle source of accidental cross-tenant access.

Folders are not complete sandboxes on their own

Pipeline is executable code, running under whatever identity the agent process itself has. Two learners sharing the same underlying agent machine might be able to observe each other's running processes, writable shared caches, files left behind by another build, a reachable Docker socket, a cloud metadata endpoint, or an internal network - even though the Jenkins UI correctly hides one folder's jobs from the other learner. This is why real isolation on a shared platform layers several things together: ephemeral, short-lived execution per build; distinct workspaces and distinct service-account identities; resource quotas; restricted outbound network access; and removing any path for an ordinary learner to reach Jenkins' own administrative functions.

Trusting the proxy correctly is the whole ballgame

The system must accept identity headers (like "this request is from learner u-abc123") only from the known, trusted proxy's network address, and strip out any copy of those same headers that a client tried to supply directly - otherwise, anyone could simply set their own "I am admin" header and walk straight past authentication. Direct access to the controller that bypasses the proxy entirely must be blocked outright. Folders and roles should be created idempotently (safe to re-run without side effects), so a learner reconnecting later returns to exactly the same scope they had before, not a fresh or duplicated one. Every configuration change, build cause, credential binding, and administrative action should be auditable - without ever storing an actual secret value in that audit trail. Ordinary learners should never be granted access to the Script Console or the ability to modify trusted shared libraries, both of which are effectively full administrative code execution.

A pitfall: testing isolation only from the "happy path"

A common mistake when standing up multi-tenant isolation is testing only "can learner A see their own folder correctly?" and calling it done. Real isolation testing has to be adversarial: deliberately try, as an ordinary learner, to list another folder's contents, trigger or configure its job, view its workspace, bind its private credential, read a cache another tenant left behind, or consume every available executor so nobody else can run anything. Denying folder enumeration in the UI while still permitting cross-tenant filesystem access on a shared agent is not isolation - it's just isolation's appearance. Per-tenant timeouts, artifact-size limits, and concurrency controls matter too, so that one learner's accidental fork bomb or runaway loop can't make the shared Jenkins instance unusable for everyone else at once.

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.