3 minute readAutomation

If an object’s access control list does not indicate what to do for the user who is trying to access it, CloudBees CD/RO first looks in the access control list 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 see 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 access control list 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 access control list in the inheritance chain and repeats the process.

  • A matching entry in a lower-level access control list takes priority over entries in higher-level access control lists. 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 just one place. When new objects are created, their access control lists 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 access control list 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 access control list.

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, however indirectly, the user is denied access. Even if a specific ACL entry granting read access by username exists, a less specific deny ACL entry overrides that specific rule. Therefore, avoid deny rules if at all possible, especially to groups, or you may experience some unexpected permissions issues.

You can, however, enforce an implicit deny 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 access control list, the object becomes completely inaccessible. You will not be 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 running job or workflow runs using the project as the identity, so 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 GUI or execute ectool commands from the command line or a script—​basically anywhere that a script or user needs to log in to CloudBees CD/RO. Having logged 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.

  • When it is practical, a job runs with multiple identities: the project, and the user that launched the job. You cannot, however rely on this behavior for security because jobs run from a schedule, and jobs started by a workflow do not have a user principal—just the project principals.

  • A job can have multiple project principals because it "accumulates" new project principals when it calls into another project’s subprocedure (and then releases the other project’s identity when the subprocedure returns). This makes it possible to create trusted libraries.