How do you harden Jenkins security using the Script Security plugin, role-based access control, credentials management, and agent isolation to prevent unauthorized code execution and credential leakage?

Think of a government building with security clearances. Not every employee can access every floor (RBAC). Documents are stored in safes that only authorized personnel can open, and the safe contents are never photocopied into public reports (credential masking). Visitors must pass through a screening room where their actions are monitored and restricted (Script Security sandbox). Each department works in isolated offices so a breach in one does not compromise another (agent isolation). Jenkins security requires the same layered approach because Jenkins pipelines execute arbitrary code with access to credentials and infrastructure.

The Script Security plugin is the first defense layer. It intercepts Groovy script execution in pipelines, shared libraries, and job configurations, running untrusted code in a restricted sandbox that blocks dangerous operations like file system access, network calls, and reflection. When a script needs an operation outside the sandbox, an administrator must explicitly approve it in the Script Approval page. Without Script Security, any user who can create or modify a pipeline can execute arbitrary Groovy code on the Jenkins controller JVM, which typically has access to all credentials, all job configurations, and the underlying server's file system.

Role-based access control in Jenkins is configured through plugins like Matrix Authorization Strategy or Role-Based Strategy. These allow fine-grained permissions: one team can create and run pipelines in their folder without seeing other teams' jobs, security administrators can manage credentials without running builds, and read-only users can view build results without modifying anything. Folder-level permissions are critical — the payments team's folder should restrict pipeline creation, credential binding, and agent assignment to that team only. The Overall/Administer permission should be limited to a small group of platform engineers.

Credentials management uses the Jenkins Credentials plugin, which stores secrets encrypted with a master key derived from the Jenkins controller's identity. Credentials can be scoped globally, to a folder, or to a specific domain. Folder-scoped credentials ensure the payments team cannot access the checkout team's API keys even if both share the same Jenkins controller. The credentials binding step injects secrets as environment variables or files during pipeline execution and automatically masks them in build logs. However, masking is pattern-based — if a script echoes the credential in base64-encoded or URL-encoded form, it may bypass masking.

The non-obvious gotcha is that shared libraries run with elevated trust by default. A globally configured shared library is not subject to Script Security sandbox restrictions, meaning any code in the library's vars/ or src/ directories executes with full access to the Jenkins controller. If a developer can push to the shared library repository without code review, they can bypass all Script Security controls. Architects must protect shared library repositories with branch protection, mandatory code review, and signed commits. Agent isolation is equally critical — builds running on the Jenkins controller itself have direct access to the controller's file system, credentials store, and JVM. All builds should run on remote agents (Kubernetes Pods, SSH agents, or cloud instances) with the controller locked down to zero executors.