Jenkins Security Concepts

Internal

• Jenkins Concepts

Jenkins Security Model

Jenkins uses a permission-based security model. Different operations have different permissions. Plugins can define their own permissions. To decide whether an operation can be performed, Jenkins asks the currently configured authorization strategy whether a specific authentication has the required permission in a specific context.

Authorization Strategy

The authorization strategy is an extension point and there are multiple plugins providing their own implementations. In most cases, these strategies are mostly hierarchical, so if an authentication has a permission in a parent context it will typically have the same permission in the children of that context.

Each authorization strategy is provided with the authentication that is requesting permission, permissions requested, and the context of the request. It returns a "yes/no" answer.

Authentication

Each execution thread has an associated authentication. There are three classes of authentications:

• ACL.SYSTEM (also known as SYSTEM) - the super-user authentication of the Jenkins master process itself. Any actions performed by Jenkins itself will start in a thread using this authentication. By default, and unless the "Authorize Project" plugin has been installed, jobs will be running as ACL.SYSTEM and will only be able to access global scope credentials.
• User authentication - assigned to any web/CLI request by a logged user.
• Jenkins.ANONYMOUS (known as ANONYMOUS) - assigned to any web/CLI request that has not been authenticated.

Permission

Hidden Permissions

Hidden permissions that interact with credentials scopes: "Credentials/UseOwn", "Credentials/UseItem".

Contexts

Jenkins implements a hierarchical context model. Every context has a chain of parent context leading ultimately to the root context. Plugins can define additions child contexts, but by default, Jenkins provides the child contexts described below.

Root

The root context is Jenkins itself.

Job

Each job has its own context.

User

Each user has its own context.

Build Agent

Each build agent has its own context.

View Context

Each view has its own context.

Credentials Management

A summary of credentials managed by a Jenkins instance is available from Jenkins -> Credentials. The view lists credential types, providers, stores, domains as well as details such as credential ID and credential name.

Credentials Plugin

Credentials Plugin

Credentials Binding Plugin

Credential

A credentials instance is a piece of security sensitive information, identified by an ID, such as a username/password pair or a username/private key pair. The sensitive information is persisted and protected in a store, and different Jenkins components that require access to it refer to it by its ID. Jenkins extract the sensitive information at runtime and provides it as needed. The default Jenkins configuration uses the Credentials Plugin Store. More details about how credentials are stored there can be found in Credentials Plugin Store Internal Implementation section. Once declared and persisted in the store, any credential can be referred from a job or any other component by ID - see "credentialsId" below:

<project>
  ...
  <scm class="hudson.plugins.git.GitSCM" plugin="git@3.8.0">

    ...
    <userRemoteConfigs>
      <hudson.plugins.git.UserRemoteConfig>
        <url>https://github.com/SomeOrganization/someproject</url>
        <credentialsId>github-service-account</credentialsId>
      </hudson.plugins.git.UserRemoteConfig>
    </userRemoteConfigs>
    ...
  </scm>
 
  ...

</project>

Credential ID

The unique ID of the credential entry.

Credential Scope

The scope defines how the credentials can be exposed:

System

This scope is only available in credential stores associated with the root context. System scope credentials are exposed to Jenkins system/background tasks. For example, a system-scoped credential can be used to connect a builder agent.

Global

This is the default scope. Global scope credentials are exposed to their associated context and all child contexts. For example, to make a credential generally available to jobs, use the Global scope.

User

This scope is the only scope available in the per-user credentials store. User scope credentials are only available to threads using that specific user's Authentication.

Credential Domain

Credential domains are intended to help select correct credentials for each services. A credential domain has a specification (example: only hostname myservice.example.com, only URLs with the https protocol, only port 8443).

Credential Type

Username with Password

To add a "Username with Password" credential. Go to Jenkins → Manage Jenkins → Manage Credentials → scroll to stores → Stores scoped to Jenkins → click on the store → click on the desired domain → left menu → Add Credentials → kind: "Username with password" → OK

The credential will show up at the bottom of the list with a randomly generated credential ID (e.g. 867941da-238c-4831-1764-7a4b32768355). Then click on the "Update" icon associated with the credential.

Update Username, change Password. The credential ID seems to be generated automatically and the UI does not allow changing it to something more user-friendly. Find out how.

For an example of how the username and password can be retrieved from a pipeline, see:

Jenkins Credentials Binding Plugin | usernamePassword Binding - Injecting Username and Password into a Build Step

Credential Provider

A credential provider connects Jenkins to an external credential vault. A credential provider is an extension point.

Jenkins (System) Credentials Provider

It exposes a credential store at the root context. It supports credential domains. It supports two scopes: system and global. The credentials store can be inspected from Jenkins › Credentials › System. Managed by the Credentials Plugin.

Credentials will be available to:

• Authentication: SYSTEM
• Users with permission: Job/Configure

Credentials will be available in:

• Global scoped credentials be available to all items within Jenkins.
• System scoped credentials restricted to system level operations such as connecting build agents.

User Credentials Provider

Provides each user with a personal credential store, where per-user credentials can be stored. The credentials store can be inspected from either Jenkins › username in the banner bar › Credentials › User or Jenkins › People › username › Credentials › User. It is managed by the Credentials Plugin. Credentials will be available to:

• Immediate operations performed by the user who defined the credentials.
• Jobs with credentials parameters when directly triggered by a user with the permission: Job/Build.
• Jobs running as the user and the user has the permission: Job/Build.

Credentials Store

Credentials providers expose credentials to Jenkins through the credentials store extension point. A credentials store is associated with a specific context within Jenkins. It either only supports the global domain, or has full support for custom domains. A credentials store will support a defined list of credentials scopes.

Internal credential stores will be responsible for storing actual credentials.

Jenkins Credentials Plugin Internal Store

Jenkins Credentials Plugin Internal Store