Access control examples for increased security

10 minute readAutomation

Initially, the Everyone group has Read and Execute permissions on all CloudBees CD/RO objects by default. The following examples illustrate how you might customize CloudBees CD/RO default access control settings for your organization.

Ensure you are familiar with the access control system before making changes. Incorrectly configuring access control lists (ACLs) can severely impact CloudBees CD/RO behavior.

Abbreviations used in the examples

  • A = Allow

  • I = Inherit (referred to as "Don’t Care" in some instances)

  • D = Deny

  • Change Permission = Change

Example 1: Basic ACL setup

This example illustrates how you might change access control defaults to set up a basic level of security. The easiest way to manage ACLs is by using different CloudBees CD/RO groups that allow users to perform specific roles.

In the following example, the Administrator and Designer groups are created and used, and the default Everyone group is modified.

When setting up your groups, choose any group names that suit your organization.

This is how the groups are defined:

  • Administrator group: This group has most of the power and abilities of the admin user login, but allows for more flexibility.

  • Designer group: This group can create and modify most CloudBees CD/RO objects.

  • Everyone group: This predefined group is used for people who only need to run CloudBees CD/RO procedures, and have no need to create or modify them.

As you begin to modify the access control system, note that the system has some project principal access control entries that should remain in place for correct system operation.

Server ACLs

The server object is the foundation for almost all ACL checks. Generally, every other object in the system inherits these privileges. For this basic ACL configuration, configure the server ACLs this way:

TypeNameReadModifyExecuteChange

group

Administrator

A

A

A

A

group

Everyone

I

I

I

I

Custom server properties ACLs

An often overlooked ACL setting is the Server Property Sheet. Allow the Everyone group Read permission on this object.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

System object ACLs

There are 25 categories of system objects with ACLs.

  1. Administration: No changes needed for this category.

  2. Archive connectors: No changes needed for this category.

  3. Artifacts: Allow the Designer group Read and Modify privileges. Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

    group

    Designer

    A

    A

    I

    I

  4. CI Configurations: No changes needed for this category.

  5. Data Retention Policies: No changes needed for this category.

  6. DevOps Insight Server Configuration: No changes needed for this category.

  7. Directory: Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  8. DSL Client Files: Allow the Everyone group Read and Modify privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  9. Email Configurations: Allow the Everyone group Read and Execute privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    A

    I

  10. Force Abort: Allow the Everyone group Execute privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    I

    I

    A

    I

  11. Licensing: No changes needed for this category.

  12. Logging: No changes needed for this category.

  13. Personas: Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  14. Plugins: Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  15. Priority: No changes needed for this category.

  16. Projects: Allow the Everyone group Read and Execute privileges, and allow the Designer group everything except Change privileges.

    TypeNameReadModifyExecuteChange

    group

    Designer

    A

    A

    A

    I

    group

    Everyone

    A

    I

    A

    I

  17. Report Object Types: No changes needed for this category.

  18. Repositories: Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  19. Resources: Allow the Everyone group Read and Execute privileges, and allow the Designer group everything except Change privileges.

    TypeNameReadModifyExecuteChange

    group

    Designer

    A

    A

    A

    I

    group

    Everyone

    A

    I

    A

    I

  20. Search Filters: Allow the Everyone group Read and Modify privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    A

    I

    I

  21. Session: Allow the Everyone group Execute privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    I

    I

    A

    I

  22. SSO Configuration: Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  23. Tags: Allow the Everyone group Read and Modify privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    A

    I

    I

  24. Workspaces: Allow the Everyone group to have Read and Execute privileges, and allow the Designer group everything except Change privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    A

    I

    group

    Designer

    A

    A

    A

    I

  25. Zones and gateways: No changes needed for this category.

Sites that want a slightly more open system might consider granting the Designer group Modify access to Resources and Workspaces.

Plugin project ACLs

Generally, you want to allow the Everyone group Read privileges on every plugin you expect to use. Each plugin has its own name, which is also the project name.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

Project ACLs

Project ACLs are special CloudBees projects: Default, EC-Utilities and EC-Examples.

Use caution when setting privileges on the EC-Utilities project. These are powerful procedures and some have their own ACL settings. Remember that the admin user is always able to use these utilities. Allowing the Administrator group full privileges accomplishes the same goal for users in that group. The Everyone group is allowed Read privileges. This is a unique project because it does not inherit ACLs from anywhere else (for example, Server or Projects).
TypeNameReadModifyExecuteChange

group

Administrator

A

A

A

A

group

Everyone

A

I

I

I

Example 2: Team ACL setup

Some organizations may want to have two or more different and separate teams use CloudBees CD/RO at the same time. In this example, people on one team have little knowledge about the other team who uses CloudBees CD/RO and no direct access to any objects used by the other team. This example describes how to modify default CloudBees CD/RO access control settings to create a multi-team security configuration using ACLs.

To divide your CloudBees CD/RO system for use by separate teams, you can create one or more separate projects for each team. You may decide to share some projects across teams.

  1. Create your teams (groups).

    For this example, begin with two teams: T1 and T2. Each team has a designer group and a user group. Using groups allows the flexibility to have a designer from one group work as a user in another group.

  2. Create the Administrator group. This group has most of the power and abilities of the admin user, but allows for more flexibility. Assigning users to the Administrator group allows better tracking of CloudBees CD/RO administrative activity.

  3. Create two designer groups: T1-designer and T2-designer. Members of the designer groups have the ability to create and modify procedures and other CloudBees CD/RO objects for their team. A member of the designer group from one team is not able to view or use the objects of the other team.

  4. Create two user groups: T1-user and T2-user. Members of the user groups have the ability to run procedures that belong to their team. A member of the user group from one team is not able to view or use objects that belong to the other team, who are not in any other group. This setup allows other users to access CloudBees CD/RO without exposing the work of the teams. A person that is not in a group for either team is not able to view objects for either of the teams.

As you begin to modify the access control system, note that the system has some project principal access control entries that should remain in place for correct system operation.

Server ACLs

The Server is the foundation for almost all ACL checks. Almost all objects in the system inherit these privileges. For this basic team configuration, we will set the Server ACLs this way:

TypeNameReadModifyExecuteChange

group

Administrator

A

A

A

A

group

Everyone

I

I

I

I

Custom Server Properties ACLs

An often overlooked ACL setting is the Server Property Sheet. Allow the Everyone group Read permission on this object.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

System object ACLs

There are 25 categories of system objects with ACLs.

  1. Administration: Allow the T1-designer and T2-designer groups Read privileges.

    TypeNameReadModifyExecuteChange

    group

    T1-designer

    A

    I

    I

    I

    group

    T2-designer

    A

    I

    I

    I

  2. Archive connectors: No changes needed for this category.

  3. Artifacts: Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  4. CI Configurations: Allow the T1-designer and T2-designer groups Read privileges.

    TypeNameReadModifyExecuteChange

    group

    T1-designer

    A

    A

    I

    I

    group

    T2-designer

    A

    A

    I

    I

  5. Data Retention Policies: No changes needed for this category.

  6. DevOps Insight Server Configuration: No changes needed for this category.

  7. Directory: Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  8. DSL Client Files: Allow the T1-designer and T2-designer groups Read and Modify privileges.

    TypeNameReadModifyExecuteChange

    group

    T1-designer

    A

    A

    I

    I

    group

    T2-designer

    A

    A

    I

    I

  9. Email Configurations: Allow the Everyone group Read and Execute privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    A

    I

  10. Force Abort: No changes needed for this category.

  11. Licensing: No changes needed for this category.

  12. Logging: No changes needed for this category.

  13. Personas: Allow the T1-designer and T2-designer groups Read privileges.

    TypeNameReadModifyExecuteChange

    group

    T1-designer

    A

    I

    I

    I

    group

    T2-designer

    A

    I

    I

    I

  14. Plugins: Allow the Everyone group Read privileges. Generally, privileges set here are inherited by all plugins.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  15. Priority: No changes needed for this category.

  16. Projects: No changes needed for this category. Privileges for projects are now handled on a case-by-case basis.

  17. Report Object Types: Allow the T1-designer and T2-designer groups Read privileges.

    TypeNameReadModifyExecuteChange

    group

    T1-designer

    I

    A

    I

    I

    group

    T2-designer

    I

    A

    I

    I

  18. Repositories: Allow the Everyone group Read privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    I

    I

  19. Resources: Allow the Everyone group Read and Execute privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    A

    I

  20. Search Filters: Allow the T1-designer and T2-designer groups Read and Modify privileges.

    TypeNameReadModifyExecuteChange

    group

    T1-designer

    A

    A

    I

    I

    group

    T2-designer

    A

    A

    I

    I

  21. Session: Allow the Everyone group Execute privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    I

    I

    A

    I

  22. SSO Configuration: Allow the T1-designer and T2-designer groups Read privileges.

    TypeNameReadModifyExecuteChange

    group

    T1-designer

    A

    I

    I

    I

    group

    T2-designer

    A

    I

    I

    I

  23. Tags: Allow the T1-designer and T2-designer groups Read and Modify privileges.

    TypeNameReadModifyExecuteChange

    group

    T1-designer

    A

    A

    I

    I

    group

    T2-designer

    A

    A

    I

    I

  24. Workspaces: Allow the Everyone group Read and Execute privileges.

    TypeNameReadModifyExecuteChange

    group

    Everyone

    A

    I

    A

    I

  25. Zones and gateways: No changes needed for this category.

Plugin project ACLs

Generally, you want to allow the Everyone group Read privileges on every plugin you expect to use. Each plugin has its own name, which is also the project name. Because you may want to use many plugins, you might want to use a script.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

Existing project ACLs

Next are a few CloudBees projects, and two sample projects that can be viewed and used by their respective team members only.

Project: EC-Examples

These are good examples, and you want to grant Everyone the ability to view and run them.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

Project: Default

Inherited settings allow the Administrator group full privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

Project: EC-Utilities

Use caution when setting privileges on the EC-Utilities project. These are powerful procedures and some have their own ACL settings.

Remember that the admin user is always able to use these utilities. Allowing the Administrator group full privileges accomplishes the same goal for users in that group. We allow the Everyone group Read privileges. This is a unique project because it does not inherit ACLs from anywhere else (for example, Server or Projects).

TypeNameReadModifyExecuteChange

group

Administrator

A

A

A

A

group

Everyone

A

I

I

I

Project: CloudBees

This project has one procedure, and you can grant everyone the ability to view it.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

ACLs for new projects

Now we introduce the concept of ACL settings as they would be in a multiple team environment. For this example, we assume you have five projects being used by two teams in the following way:

  • Project-A and Project-B are used by Team1

  • Project-C and Project-D are used by Team2

  • Project-E is used by Team1 and Team2

Project-A

This project is visible and usable only by CloudBees CD/RO users who are members of either the T1-user group or the T1-designer group. Notice that the designer group receives full permissions.

TypeNameReadModifyExecuteChange

group

T1-designer

A

A

A

A

group

T1-user

A

I

A

I

Project-B

This project is the same as Project-A.

TypeNameReadModifyExecuteChange

group

T1-designer

A

A

A

A

group

T1-user

A

I

A

I

Project-C

This project is visible and usable only by CloudBees CD/RO users who are members of either the T2-user group or the T2-designer group. Notice that the T2-designer group receives full permissions.

TypeNameReadModifyExecuteChange

group

T2-designer

A

A

A

A

group

T2-user

A

I

A

I

Project-D

This project is the same as Project-C.

TypeNameReadModifyExecuteChange

group

T2-designer

A

A

A

A

group

T2-user

A

I

A

I

Project-E

This project is a superset that includes both teams.

TypeNameReadModifyExecuteChange

group

T1-designer

A

A

A

A

group

T1-user

A

I

A

I

group

T2-designer

A

A

A

A

group

T2-user

A

I

A

I

Enabling Same Team Subprocedures

You can enable procedures in one project to use procedures in another project:

  1. Add the project principals for both T1 projects to the T1-user group. In this case, these are called: project: Project-A and project: Project-B.

  2. Add the project principals for both T2 projects to the T2-user group. In this case, these are called: project: Project-C and project: Project-D.

Optional: Restricting resources and workspaces by team

Resource ACLs

Resource: local

Since each team has dedicated resources, it is useful to keep one resource available for everyone to use.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

T1-resource

This resource is visible and usable only by CloudBees CD/RO users who are members of either the T1-user group or the T1-designer group. This resource also requires the Execute permission for the project itself, to allow it to run from a schedule.

TypeNameReadModifyExecuteChange

group

T1-designer

A

I

A

I

group

T1-user

A

I

A

I

T2-resource

This resource is visible and usable only by CloudBees CD/RO users who are members of either the T2-user group or the T2-designer group. This resource also requires the Execute permission for the project itself, to allow it to run from a schedule.

TypeNameReadModifyExecuteChange

group

Administrator

A

A

A

A

group

Everyone

I

I

I

I

Workspace ACLs

Workspace: default

Since there are dedicated workspaces for each team, it is useful to keep one workspace available for everyone to use.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

T1-workspace

This workspace is visible and usable only by CloudBees CD/RO users who are members of either the T1-user group or the T1-designer group.

TypeNameReadModifyExecuteChange

group

T1-designer

A

I

A

I

group

T1-user

A

I

A

I

T2-workspace

This workspace is visible and usable only by CloudBees CD/RO users who are members of either the T2-user group or the T2-designer group.

TypeNameReadModifyExecuteChange

group

T2-designer

A

I

A

I

group

T2-user

A

I

A

I