Jenkins Security Concepts: Difference between revisions
| Line 28: | Line 28: | ||
Each [[Jenkins_Concepts#Agent|build agent]] has its own context. | Each [[Jenkins_Concepts#Agent|build agent]] has its own context. | ||
==View Context== | |||
Each [[Jenkins_Concepts#View|view]] has its own context. | |||
=Credentials Management= | =Credentials Management= | ||
Revision as of 21:17, 24 April 2018
Internal
Jenkins Security Model
Authentication
User
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 Context
The root context is Jenkins itself.
Job Context
Each job has its own context.
User Context
Each user has its own context.
Build Agent Context
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 ID and name.
Credentials Plugin
Credential
Credential ID
Credential Name
Credential Scope
Credential Type
Username with Password
Docker Certificates Directory
Docker Host Certificate Authentication
SSH Username with Private Key
Secret File
Secret Text
Certificate
Credential Provider
A credential provider connects Jenkins to an external credential vault.
Jenkins Credentials Provider
Managed by the Credentials Plugin. Provides credentials from the root of Jenkins. 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
Managed by the Credentials Plugin. Provides each user with a personal credential store. 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.