Jenkins - Security

Jenkins - Security Configuration

Securing your Jenkins instance is crucial to protect your build processes, source code access, credentials, and deployment pipelines. By default, a fresh Jenkins install might allow anonymous access with full control, which is highly insecure.

Step 1: Enable Security

1. Navigate to Manage Jenkins → Security.

2. Check the box ‘Enable security’.

Once enabled, you must configure a Security Realm (Authentication) and an Authorization Strategy.

Step 2: Configure Security Realm (Authentication - Who are you?)

This determines how Jenkins verifies user identities.

• Jenkins’ own user database: (Default after enabling security) Jenkins maintains its own list of users and passwords. Suitable for small setups. Ensure ‘Allow users to sign up’ is unchecked for better control. You manage users via Manage Jenkins → Users.
• LDAP / Active Directory: Integrate with your organization’s existing directory service. Users log in with their standard corporate credentials. Requires the ‘LDAP Plugin’ or ‘Active Directory Plugin’. Configuration involves specifying server details, domain names, and user/group search bases.
• Unix user/group database: Uses the underlying OS’s user accounts (less common for web UI access).
• Delegate to servlet container: If Jenkins runs in Tomcat/Jetty, authentication can be handled by the container.
• OAuth / SAML: Integrate with external Identity Providers (IdPs) like GitHub, Google, Okta, Azure AD using relevant plugins (e.g., ‘GitHub Authentication’, ‘SAML’, ‘OpenID Connect Authentication’).

Choose the realm that best fits your environment. LDAP/AD or SSO (SAML/OAuth) are common in enterprise settings.

Step 3: Configure Authorization Strategy (Permissions - What can you do?)

This defines what actions authenticated users (or anonymous users, if allowed) can perform.

• Anyone can do anything: (Highly insecure - Avoid!) Grants full control to all users, including anonymous ones.
• Logged-in users can do anything: Grants full control to any authenticated user. Better, but still lacks granular control.
• Legacy mode: Approximates older Jenkins versions’ behavior (generally not recommended).
• Matrix-based security: Provides a grid to grant specific permissions (Read, Build, Configure, Administer, etc.) to individual users or groups globally.
• Project-based Matrix Authorization Strategy: Extends Matrix-based security, allowing you to define permissions per-project (job/folder) in addition to global permissions. Offers fine-grained control.
• Role-based Authorization Strategy: (Requires ‘Role-based Authorization Strategy’ plugin) Define roles (e.g., ‘developer’, ‘tester’, ‘admin’), assign permissions to roles, and then assign users/groups to roles. Often easier to manage permissions for many users/jobs than matrix strategies.

Recommendation: Start with ‘Logged-in users can do anything’ initially after enabling security to avoid locking yourself out. Then, immediately configure either ‘Matrix-based security’ (adding your admin user with full ‘Administer’ permissions first) or install and configure the ‘Role-based Strategy’ plugin for more robust control.

When using matrix or role-based strategies, always ensure you grant the ‘Overall/Administer’ permission to at least one administrative user or group.

Step 4: Manage Users (if using Jenkins DB)

If you chose ‘Jenkins’ own user database’ as the realm:

1. Navigate to Manage Jenkins → Users.
2. Click ‘Create User’.
3. Fill in the username, password, full name, and email.
4. Click ‘Create User’.
5. Repeat for all necessary users.
6. Return to ‘Configure Global Security’ to assign permissions to these users in the Authorization matrix/roles.

Other Security Considerations

• Agent Security: Secure the connection between the controller and agents. Use SSH agents where possible. For JNLP agents, enable ‘Agent → Controller Access Control’ to restrict what agents can do on the controller.
• CSRF Protection: Keep ‘Prevent Cross Site Request Forgery exploits’ enabled (default).
• Markup Formatter: Set to ‘Safe HTML’ or ‘Plain text’ to prevent potential XSS attacks via job descriptions or build output.
• Credentials Management: Use the Jenkins Credentials system (Manage Jenkins → Credentials) for all secrets (passwords, tokens, keys). Never hardcode secrets in job configurations or Jenkinsfiles.
• Regular Updates: Keep Jenkins core and plugins updated to receive security patches.

Click ‘Save’ after configuring security settings. You will likely be logged out and need to log back in with the credentials of a user who has appropriate permissions based on your new configuration.