If an object’s access control list (ACL) does not indicate what to do for a user who is trying to access it, CloudBees CD/RO first checks the ACL for the object containing the target object, then its parent, and so on; up to a top-level object covering the entire server. This mechanism is called inheritance.
For example, a nested property sheet on a procedure inherits access control information from its parent property sheet, the procedure, the project containing the procedure, and the server. When you view the object access control list, you also view inherited access control lists, so you can trace the object’s inheritance chain.
When CloudBees CD/RO performs an access check on an object, it begins with the ACL for that object.
-
If a Deny entry matches an entry in that list, access is denied.
-
If there is no Deny entry, but a matching Allow entry is found, access is allowed.
-
If there is no matching entry that specifies either Allow or Deny, CloudBees CD/RO moves to the next ACL in the inheritance chain and repeats the process.
-
A matching entry in a lower-level ACL takes priority over entries in higher-level ACLs. If no matching entry in any list is found, access is denied.
Inheritance allows you to control access to a collection of objects because you can make changes in one place. When new objects are created, their ACLs are empty, so all access control for the entire system is determined by the server-level list.
-
Typically, when a new project is created, you define an ACL for the project and allow everything in the project to inherit from the project.
-
If you do not define additional access control information in project components, all project access is determined by the project’s ACL.
In some situations, you may want tight control over object access, so changes in parent objects do not affect access to the object or its children. To achieve this, you can "break inheritance," which means a particular object does not inherit from its ancestors. The CloudBees CD/RO web interface allows you to break and restore inheritance for any object on which you can change permissions.
| If you break an object’s inheritance, it affects all children of that object. |
Additional information about deny
If a user matches a Deny rule, no matter how indirectly, the user is denied access. Even if a specific ACL entry granting Read access by the user name exists, a less specific Deny ACL entry can override that specific rule. Therefore, avoid Deny rules if at all possible, especially for groups, or you may experience some unexpected permissions issues.
However, you can enforce an implicit Deny rule by allowing an object to fall off the end of the inheritance chain. This practice allows denial behavior without the risks associated with an explicit ACL entry to deny access.
| If you break inheritance on an object with an empty ACL, the object becomes completely inaccessible. You are not able to restore inheritance because you no longer have the right to change permissions on that object. If this happens, you must contact your system administrator to restore inheritance. |
Consider CloudBees CD/RO principals (actors) from two perspectives:
-
A job or workflow runs using the project as the identity. Therefore, if a job requires special permissions, you must use the project as the principal in the ACL entry.
-
Users and groups come into play when users manipulate the UI or execute ectool commands from the command line or a script—basically anywhere that a script or user needs to sign in to CloudBees CD/RO. Having signed in, a group and ID exist, which can be used in ACL entries.
For example, consider a property that stores a build number. You can set an ACL that breaks inheritance (implicit deny), and then add an ACL entry granting permissions for the project to be able to increment the property value. This prevents users from manipulating the build number but permits a running job to increment the build number at will.
|