Learn Jenkins - Jenkins Security, RBAC & Authentication

#Introduction

In episode 10 we discussed how to store build artifacts and manage workspaces across agents. But there is one question we have not answered: who should be allowed to enter your Jenkins and what may they do?

Jenkins is often left running with very permissive default settings, including anonymous read access. In that state, anyone who knows your Jenkins address — including strangers on the internet — can read the job list, open configurations, and even see workspace contents containing source code and secrets. Imagine an office with the door wide open and every document on the desk readable without permission; that is the picture of an unsecured controller.

In this episode we will close those gaps one by one: disable anonymous access, choose an authentication scheme, implement Role-Based Authorization Strategy (RBAC), and then secure Groovy script execution with Script Security and the Groovy Sandbox. This topic must be mastered before your Jenkins touches a production network.

#Main Discussion

#Authentication Is Different from Authorization

Before diving into the settings, remember two concepts that are often mixed up:

• Authentication answers the question "who are you?" — the process of verifying identity, for example through a user database or LDAP.
• Authorization answers the question "what are you allowed to do?" — the process of determining access rights once the identity is known.

#Level 1: Disable Anonymous Read Access

The most fundamental step lives in Manage Jenkins > Security. Check the Disable anonymous read access option so visitors without a login cannot see anything.

Next, set the authorization strategy. For a lab or experiments, choose Logged-in users can do anything — all authenticated users have full access. This is indeed safer than the default, but too broad for production; we will level up to RBAC in the next section.

#Level 2: Choose an Authentication Scheme

Jenkins provides several ways to verify user identity. The best choice depends on the scale of your organization:

All these schemes are chosen in Manage Jenkins > Security > Global Security under the Security Realm section. In episode 12 we will discuss one OAuth 2.0 derivative, OIDC, for passwordless cloud authentication.

#Level 3: RBAC with Role-Based Authorization Strategy

After authentication, implement the Role-Based Authorization Strategy via the Role-based Authorization Strategy plugin. This plugin separates access rights into three scopes:

• Global roles — rights at the controller level, e.g. Overall/Administer, Overall/Read, Overall/Configure.
• Item roles — rights per job or project, usually matched by name patterns such as my-app-*.
• Agent roles — rights to manage agent nodes.

How to activate: install the plugin, then in Manage Jenkins > Security > Global Security choose Role-Based Strategy as the authorization, and click Save. Next, the Manage and Assign Roles menu appears to define roles. An example of common role mapping in a development team:

With this pattern, a Tester can run builds and read their results but cannot change job configuration, while a Developer without Overall/Administer can still work on their project. Each user or group is then assigned to a specific role through the Assign Roles page.

#Level 4: Script Security & the Groovy Sandbox

Jenkins pipelines run in the Groovy Sandbox by default. The sandbox restricts code so it cannot call dangerous methods outside the allowed area. If a pipeline tries to call a disallowed method, execution stops and Jenkins asks an admin to approve that script. An example of code that triggers the approval process:

Pipeline that requires approval

stage('Cek Kapasitas Agent') {
    steps {
        script {
            def node = hudson.model.Hudson.instance.getNode('linux-runner')
            println "Total executors: " + node.getNumExecutors()
        }
    }
}

The call hudson.model.Hudson.instance is a static method considered sensitive, so the pipeline stops with an error and shows a message like:

Scripts not permitted to use: staticMethod hudson.model.Hudson getInstance
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException:
    Scripts not permitted to use: staticMethod hudson.model.Hudson getInstance

The admin then opens Manage Jenkins > In-process Script Approval and chooses Approve or Deny for the rejected method signature. After approval, subsequent pipelines can call that method without hindrance.

#CSRF Protection

Cross-Site Request Forgery (CSRF) forces a victim to send requests without realizing it. Since Jenkins 2.0, CSRF protection is active by default: every POST request must include a per-session crumb token. When interacting via the API, you must fetch a crumb first and then send it via the Jenkins-Crumb header:

curl -s -u admin:API_TOKEN \
  -c /tmp/crumb.jar \
  https://jenkins.example.com/crumbIssuer/api/json
 
curl -s -u admin:API_TOKEN \
  -b /tmp/crumb.jar \
  -H "Jenkins-Crumb: <hasil-crumb>" \
  -X POST \
  https://jenkins.example.com/job/my-app/build

#Conclusion

In episode 11 you have learned to secure the Jenkins controller from the inside out: disabling anonymous read access, choosing an authentication scheme suited to team size, implementing RBAC with the Role-Based Authorization Strategy to separate the Admin, Developer, and Tester roles, understanding how Script Security and the Groovy Sandbox work along with the script approval process, and recognizing CSRF protection, which is active by default.

Security does not stop at controller settings. One point that still often leaks is static cloud credentials — for example an AWS Access Key stored permanently in Jenkins Credentials.

In episode 12 we will discuss Passwordless Cloud Authentication Using OIDC — replacing static credentials with short-lived tokens so authentication to AWS, GCP, and Azure becomes more secure and password-free. See you there!