Examples for increased security

9 minute readAutomation

Initially, the Everyone group has Read and Execute permission 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.

Make sure you are familiar with the access control system before making changes. Incorrectly setting ACLs can severely impact CloudBees CD/RO behavior.

Abbreviations used in the examples

  • A = Allow

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

  • 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.

For our example, we will create and use the groups called EC-administrator and EC-designer, and we will modify the default Everyone group.

When setting up your groups, you would choose any group names that suit your organization, but note that the EC- prefix is reserved for CloudBees use only.

This is how we want to define our groups:

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

  • EC-designer group: This role is more significant. Users in 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 ACEs 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 we want to set Server ACLs this way:

TypeNameReadModifyExecuteChange

group

EC-administrator

A

A

A

A

group

Everyone

I

I

I

I

Custom server properties ACLs

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

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

System object ACLs

There are 14 categories of System objects with ACLs.

1—Administration: allow the EC-designer group Read privileges.

TypeNameReadModifyExecuteChange

group

EC-designers

A

I

I

I

2—Artifacts: allow the EC-designer group Read privileges.

TypeNameReadModifyExecuteChange

group

EC-designers

A

A

I

I

group

Everyone

A

I

I

I

3—Directory: allow the Everyone group Read privileges.

TypeNameReadModifyExecuteChange

group

EC-designers

A

I

I

I

4—Email Configurations: allow the Everyone group Read and Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

5—Force Abort: no changes needed for this category.

6—Logging: no changes needed for this category.

7—Licensing: no changes needed for this category.

8—Plugins: allow the Everyone group Read privilege.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

9—Priority: no changes needed for this category.

10—Projects: allow the Everyone group Read and Execute privileges, and the EC-designer group everything except Change privilege.

TypeNameReadModifyExecuteChange

group

EC-designers

A

A

A

I

group

Everyone

A

I

A

I

11—Repositories: allow the Everyone group Read and Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

12—Resources: allow the Everyone group Read and Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

13—Session: allow the Everyone group Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

I

I

A

I

14—Workspaces: allow the Everyone group to have Read and Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

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

Plugin project ACLs

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

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

Project ACLs

Next 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 the ‘admin’ user will always be able to use these utilities. Allowing the EC-administrator group full privileges accomplishes the same goal for users in that group. We allow the Everyone group Read only privileges. This is a unique project because it does not inherit ACLs from anywhere else (for example, Server or Projects).

TypeNameReadModifyExecuteChange

group

EC-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. Our "Team" 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 will want to create one or more separate Projects for each team. You may decide to share some projects across teams.

Create your teams (groups). For our example, we will 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.

  • Create the EC-administrator group This group has most of the power and abilities of the ‘admin’ user login, but allows for more flexibility. Assigning people to the EC-administrator group allows better tracking of CloudBees CD/RO administrative activity.

  • Create two designer groups:T1-designer and T2-designer Members of the designer groups will 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 will not be able to view or use the objects of the other team.

  • Create two user groups: T1-user and T2-user Members of the user groups will have the ability to run procedures that belong to their team. A member of the user group from one team will not be 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 any of the teams. A person not in a group for either team will not be able to see objects of either of the teams.

As you begin to modify the access control system, note that the system has some project principal ACEs 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

EC-administrator

A

A

A

A

group

Everyone

I

I

I

I

Custom Server Properties ACLs

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

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

System object ACLs

There are 14 categories of System objects with ACLs.

1—Administration: allow both designer groups Read privileges.

TypeNameReadModifyExecuteChange

group

T1-designer

A

I

I

I

group

T2-designer

A

I

I

I

2—Artifacts: allow the Everyone group Read privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

3—Directory: allow the Everyone group Read privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

4—Email Configurations: allow the Everyone group Read and Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

5—Force Abort: no changes needed for this category.

6—Logging: no changes needed for this category.

7—Licensing: no changes needed for this category.

8—Plugins: allow the Everyone group Read privilege. Generally, privileges set here will be inherited by all plugins.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

9—Priority: no changes needed for this category.

10—Projects: no changes needed for this category. Privileges for projects are now handled on a case by case basis.

11—Repositories: allow the Everyone group Read privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

I

I

12—Resources: allow the Everyone group Read and Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

13—Session: allow the Everyone group Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

I

I

A

I

14—Workspaces: allow the Everyone group Read and Execute privileges.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

Plugin project ACLs

Generally, you will 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 seen and used by their respective team members only.

Project: EC-Examples

These are nice examples and we want to grant Everyone the ability to see and run them.

TypeNameReadModifyExecuteChange

group

Everyone

A

I

A

I

Project: Default

Inherited settings will allow the EC-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 the admin user will always be able to use these utilities. Allowing the EC-administrator group full privileges accomplishes the same goal for users in that group. We allow the Everyone group Read only privileges. This is a unique project because it does not inherit ACLs from anywhere else (for example, Server or Projects).

TypeNameReadModifyExecuteChange

group

EC-administrator

A

A

A

A

group

Everyone

A

I

I

I

Project: CloudBees

This project has one procedure and we want to grant everyone the ability to see 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 used by Team1

  • Project-B used by Team1

  • Project-C used by Team2

  • Project-D used by Team2

  • Project-E 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 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

To enable procedures in one project to use procedures in another project, one more step is necessary.

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”.

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

Because each team will have 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 needs 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 needs Execute permission for the project itself to allow it to run from a schedule.

TypeNameReadModifyExecuteChange

group

EC-administrator

A

A

A

A

group

Everyone

I

I

I

I

Workspace ACLs

Workspace: default

Because there will be 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