Each category controls different aspects of Jenkins, such as global system access, job-level permissions, and agent (node) management.
Let's explore each type of role in detail.
Best Practices for Role Management in Jenkins
1. Global Roles
Global roles apply to the entire Jenkins instance, affecting the overall access users or groups have across the system. These roles are not tied to specific jobs or projects but rather to Jenkins-wide functionality such as job creation, system configuration, and user management.

Key Permissions for Global Roles
- Overall Permissions:
- Administer: Full control over Jenkins. Users with this permission can access all aspects of Jenkins, including configuration, plugin installation, security settings, etc.
- Read: Allows users to view the Jenkins dashboard and all jobs, but without making any changes.
- Credentials Permissions:
- Create: Users can create new credentials.
- Delete: Users can delete existing credentials.
- Manage Domains: Users can manage credential domains (grouping credentials for different scopes).
- Job Permissions:
- Create: Allows users to create new Jenkins jobs.
- Delete: Permits deletion of existing jobs.
- Configure: Enables users to modify job configurations.
- Read: View job configurations and logs without modifying anything.
- Build: Allows users to start builds for jobs.
- Run Permissions:
- Delete: Users can delete specific build runs (e.g., removing a build history).
- Update: Users can update build descriptions, labels, etc.
- Replay: Users can replay builds in pipelines.
- SCM Permissions:
- Tag: Users can create SCM (Source Control Management) tags.
Example Global Roles

- Admin Role: admin
- Full permissions across the Jenkins system.
- Permissions include Administer, Create, Configure, Build, Read, Delete for overall and job permissions.
- Use Cases for Admin Role: System Administrators and DevOps Engineers.
- Developer Role: developer
- is tailored for users involved in job creation, modification, and execution, without granting full administrative control over the Jenkins system.
- Permissions include Read, Build, Configure, but not system-wide admin functions.
- Use Cases for Developer Role: Software developers who need access to their jobs for managing builds and DevOps engineer working on specific Jenkins pipelines may need the ability to modify their own jobs, but they do not require full system admin rights.
- Viewer Role: viewer
- Restricted to read-only access across Jenkins.
- Permissions include Read for jobs and overall Jenkins.
- Use Cases for Viewer Role: Managers, Stakeholders, QA and Auditors
2. Item Roles (Project Roles)
Item roles (also called Project roles) are specific to jobs (or folders containing jobs). These roles determine what actions users can take on a particular set of jobs or folders.
Key Permissions for Item Roles
- Job Permissions:
- Read: View the job and its build history/logs.
- Build: Start a build for the job.
- Configure: Change job configurations such as source code repository, build steps, etc.
- Delete: Delete the job.
- Workspace: Access the workspace of the job (the directory on disk where the job executes).
- Run Permissions:
- Replay: Replay a pipeline or build.
- Update: Modify build details, descriptions, etc.
- Delete: Delete specific build runs.
Defining Item Roles
- Scope: Item roles can be defined with a scope, such as specific jobs or folders. For example, you can define an item role to apply only to jobs that match a particular pattern (
dev-*
orproject-A/*
). - Pattern Matching: You can use wildcards to match multiple jobs with similar names. For example,
project-*
will apply the role to all jobs starting withproject-
.
Example Item Roles

- Project Admin:
- Full control over specific projects.
- Permissions include Read, Build, Configure, Delete, and Workspace for the project scope.
- Build Operator:
- Can view and run builds but not configure jobs.
- Permissions include Read and Build for selected jobs.
- Project Viewer:
- View-only access to specific jobs.
- Permissions include Read for those jobs.
3. Agent Roles (Node Roles)
Agent roles control permissions related to Jenkins agents (also known as nodes or slaves). These roles determine who can configure, connect, disconnect, and manage the nodes used to run Jenkins jobs.
Key Permissions for Agent Roles
Agent Permissions:
- Configure: Allows users to configure the agent settings such as labels, remote directory, and usage.
- Connect: Allows users to manually connect the agent to Jenkins (useful when nodes disconnect due to network issues or restarts).
- Create: Enables users to create new agents.
- Delete: Users can delete agents.
- Disconnect: Users can disconnect an agent from Jenkins (useful for maintenance).
Pattern Usage in Agent Roles:
When defining Agent Roles, you can use patterns to control access to a specific set of agents (build executors/nodes) based on their naming conventions.
For example, if your Jenkins agents are named according to a particular project, team, or environment, you can use patterns to restrict access accordingly.
Example:client1-agent-*
This pattern is similar to the one used in Item Roles but is applied to agents (nodes). It means that the role will have permissions over any agent whose name starts with client1-agent-
like:client1-agent-node1
and client1t-agent-node2
Any role defined using the client1t-agent-*
pattern will apply to all these agents.
Use Cases for Agent Roles

- Node Maintainer:
- This role might be responsible for managing the health and connectivity of the agents without the ability to create or delete jobs.

Best Practices for Role Management in Jenkins
- Limit Admin Access: Only grant the Administer permission to trusted users who need full control over Jenkins.
- Granular Permissions: Use item roles to limit job-specific access. Avoid giving global permissions to users who only need to manage a subset of jobs.
- Use Groups: Instead of assigning roles to individual users, consider assigning them to groups, which simplifies management.
- Regular Audits: Periodically review roles and permissions to ensure they align with your security policies.
By carefully managing Global, Item, and Agent roles, you can establish a fine-grained access control mechanism that enhances security and operational efficiency in Jenkins.