CloudBees
The Role Based Access Control plugin introduces a number of new concepts to Jenkins when enabled. As these concepts and terms are used in a lot of different systems other than Jenkins, this section defines their meaning within the Role Based Access Control plugin.
- Permission
- A Permission is a basic capability, such as starting a job or configuring a build slave. There is a core set of permissions defined by Jenkins, but some plugins define further permissions. If an action within Jenkins requires a specific permission, then the user wishing to perform that action must have the required permission.
- Role
- A Role is just a set of permissions grouped into some meaningful category. For example, a “developer” role might include viewing jobs, browsing workspaces, starting (or canceling) builds, and creating version control tags; but not configuring (or deleting) those jobs, managing the build slaves they run on, or other permissions. The Role Based Access Control plugin allows the Jenkins administrator to define as many roles as are needed; these definitions will then be available throughout the system.
- Security Realm
- The Security Realm is responsible for establishing the identity of users after login. Jenkins ships with a number of security realm implementations and plugins can define additional ones, typically connecting to external services such as LDAP. Only one security realm can be active at a time.
- External Group
- An External Group is a group of users which is defined outside of the control of Jenkins and reported by the security realm. For example when the LDAP security realm is active, the LDAP groups that a user is a member of are considered external groups by Jenkins. The same is true of the Active Directory security realm. (Some security realms, such as the built-in “Jenkins’s own user database”, do not support external groups.)
- Authorization Strategy
- The Authorization Strategy picks up user definitions from the security realm and is responsible for determining what permissions users have on various objects within Jenkins. Jenkins ships with a number of authorization strategy implementations and plugins can define additional ones—including Role Based Access Control. Only one authorization strategy can be active at a time; since Role Based Access Control subsumes the functionality of most others this is unlikely to be a limitation.
- Group
- A Group (termed a Local Group when there is a chance of ambiguity) is a set of external groups, individual users, and even other local groups, which has been defined within Jenkins by the Role Based Access Control plugin. Besides membership, a group may be granted some of the roles defined separately in Jenkins. Groups can be defined either at the root of Jenkins, or within specific objects such as folders or even single jobs. When a group is defined within a specific object, that group is local to the object and any children (such as nested jobs and subfolders). A user’s effective permissions are the aggregate of all the roles assigned to the groups they are members of which are within the scope of the object they wish to perform an action on.
- Role Filter
- A Role Filter may be defined on an object within Jenkins, and allows roles to be restricted from propagating through from the parents of the object. For example, if a specific job is to be hidden from all but a small team of users, a group would be created in that job with the required roles assigned to that group. A role filter would then be applied to the job to suppress other roles from propagating through from the parent. Administrators can however specify that certain roles, such as Jenkins system administrator, must never be filtered out.