Introduction
Introduction
IntroductionInstall CloudBees CD/RO within KubernetesConfigure Helm chartsKubernetes platform-specific configurationsKubernetes configuration optionsConfigure IP protocols for Helm chart componentsConfigure GitOps with Helm chartsVerify Helm chartsCreate custom Docker imagesVerify Docker images
IntroductionInstallation user requirementsInstallation typesDefault installation directoriesVerify installation binariesAgent security recommendations
IntroductionInstall a default configurationInstall a custom configurationRun an express agent GUI installationRun an express GUI installation (agent-only installer)Run an advanced GUI installation (agent-only installer)Install CloudBees Analytics
IntroductionRun an express server command-line installationRun an advanced command-line installationRun an express agent command-line installationExpress agent command-line installation (agent-only installer)Advanced command-line installation (agent-only installer)Install the CloudBees Analytics server with the interactive command-line installer
IntroductionRun a silent installationSilent installation argumentsLinux silent installation examplesWindows silent installation examplesCloudBees Analytics server unattended installation
IntroductionUNIX agent interactive command-line installationSilent installation method for UNIX or macOS agents
IntroductionPrerequisitesPermissions to install or upgrade remote agentsInstall remote agents using the web interfaceInstall via the API
CloudBees Tools installation
Move the artifact repository in LinuxMove the artifact repository in Windows
Connect CloudBees CD/RO to a Microsoft SQL server
Install the MySQL JDBC connector
IntroductionUninstall CloudBees CD/RO on Linux, Unix, or macOSUninstall on WindowUninstall the CloudBees Analytics server on LinuxUninstall the CloudBees Analytics server on Windows
IntroductionZones and gatewaysConfigure custom CAs and CRLs in non-clustered environmentsConfigure custom CAs and CRLs in clustered environmentsConfigure agent environment variablesLicensesCreate and manage usersEdit user settingsCreate and manage groupsPersonasConfigure an external databaseConfigure CloudBees CD/RO to use an alternate databaseInstall services for non-root/non-sudo Linux installationsConfigure autostart for non-root/non-sudo Linux installationsConfigure universal access to the plugins directoryConfigure an environment proxy serverSystem health monitoringIncrease file descriptors on Linux and Linux Docker containersAdjust swappiness on LinuxSet variables on Windows agent machinesServer propertiesServer settingsSource code synchronization
IntroductionConfigure initial events for Workload InsightsConfigure OpenSearch Dashboards to work with CloudBees Analytics
IntroductionArchitecture of a CloudBees CD/RO clusterResource, agent, and procedure considerationsSoftware for clusteringDependencies for clusteringConfigure clusteringSeparate agents from CloudBees CD/RO serversPrepare your cluster resourcesInstall and configure a load balancerInstall ZooKeeperConfigure a multi-ZooKeeper clusterInstall CloudBees CD/RO softwareConfigure repository serversConfigure machines to operate in clustered modeRun a cluster in single-server modeAdd the configuration to ZooKeeperUpload configuration files to ZooKeeperGet cluster information from ZooKeeperAdd a node to an existing clusterConfigure web server propertiesConfigure repository server propertiesConfigure CloudBees CD/RO agentsConfigure the cluster workspaceConfigure CloudBees CD/RO repositoriesAdd trusted agents to clustersVerify CloudBees CD/RO servicesAccess CloudBees CD/RO with clusteringHealth check for the CloudBees CD/RO clusterAdditional ways to improve a clusterInstall the CloudBees Analytics server in cluster modeUse self-signed certificates in CloudBees CD/RO on KubernetesConfigure Disaster Recovery and recover from a disaster
Sign in to CloudBees CD/ROAccess the Home pageMy work dashboardGuided tutorialsLearn about the object modelSearch and filter
IntroductionIntrinsic properties listed by object typeReserved words in CloudBees CD/ROObject types in CloudBees CD/ROSpecial characters in CloudBees CD/RO object namesContext-relative shortcuts to property pathsProperty error codesConfigure properties or property sheetsProperty BrowserProperty reference use case
IntroductionResource poolsCreate or edit resource pools
IntroductionView workspacesCreate or edit workspacesWorkspace file
IntroductionCreate a projectSchedules
IntroductionPipeline stages and gatesPipeline access controlPipeline tasksUse the CloudBees CD/RO API to define tasksDefine manual tasksEntry and exit gatesPipeline conditionsPipeline start and end stages and stage skippingWait dependenciesNative CI integrationPipeline UIAuthor and run pipelinesDefine stage gate rulesPipeline objects and conditionsPipeline stage summaryCredentials in pipelinesRun pipelinesView pipeline runsExample: Create a manual task in a pipelineExample: Plugin pipeline tasksExample: Integrate test automation in release pipelinesExample: Leverage test data management and service virtualization in release pipelines
IntroductionRelease planning, scheduling, and trackingRelease and environment reservations calendarVisibility and status of release pipelinesRelease definitionDeploy with Argo RolloutsRelease dashboardPlanned versus actual view for pipeline statusPath to production viewRelease summaryRun and end releases
Introduction
IntroductionManage procedure runsProcedure run detailsUsing CloudBees CD/RO in your environmentJob step executionPostprocessors: Collecting data for reports
IntroductionWorkflow listsCreate or edit workflow definitionsWorkflow definition detailsRun workflowWorkflow detailsWorkflow LogTransition workflow
Introduction
IntroductionCreate and manage applicationsApplication process run detailsCreate application processesAdd process stepsProcess branchingConfigure plugin process stepsDefine manual stepsExample: Manual step with runtime parametersAttach credentials to processesFull-stack dependency viewApplication deployment optionsConfiguration drift
IntroductionMaster component examplesMaster components list
Introduction
IntroductionStage artifactsCapture snapshotsApplication rollbackManage dependencies
IntroductionCreate environmentsDefine environment tier mapsInventory trackingEnvironment inventoryGlobal environment inventoryEnvironment reservationsLock environmentsModel dynamic environmentsAutomated environment discoveryCreate a deployment task to trigger third-party toolsGenerate a deployment packageExample: Dynamic environment with Amazon and ChefExample: Deploy and troubleshoot applicationsExample: Deploy applications with provisioned cloud resourcesExample: Implement deployment strategies
IntroductionArtifactsArtifact versionsRepositories
Create object tagsCreate object schedules
IntroductionConfigure webhook triggersConfigure polling triggers
IntroductionConfigure email notificationsSelect and edit email messages for application or microservice processes
Introduction
IntroductionInstall CloudBees CD/RO pluginsCreate plugin configurationsManage pluginsCreate pluginsManage the plugin catalog

Access control examples for increased security

11 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

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:

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    I

    I

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

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    I

    I

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

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    A

    I

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

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    I

    I

  14. Plugins: Allow the Everyone group Read privileges.

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    group

    Designer

    A

    A

    A

    I

    group

    Everyone

    A

    I

    A

    I

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

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    A

    I

    I

  21. Session: Allow the Everyone group Execute privileges.

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    I

    I

    A

    I

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

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    I

    I

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

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    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.

Type Name Read Modify Execute Change Permissions

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).
Type Name Read Modify Execute Change Permissions

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:

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    I

    I

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

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    I

    I

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

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    group

    T1-designer

    I

    A

    I

    I

    group

    T2-designer

    I

    A

    I

    I

  18. Repositories: Allow the Everyone group Read privileges.

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    I

    I

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

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    A

    I

    A

    I

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

    Type Name Read Modify Execute Change Permissions

    group

    T1-designer

    A

    A

    I

    I

    group

    T2-designer

    A

    A

    I

    I

  21. Session: Allow the Everyone group Execute privileges.

    Type Name Read Modify Execute Change Permissions

    group

    Everyone

    I

    I

    A

    I

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

    Type Name Read Modify Execute Change Permissions

    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.

    Type Name Read Modify Execute Change Permissions

    group

    T1-designer

    A

    A

    I

    I

    group

    T2-designer

    A

    A

    I

    I

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

    Type Name Read Modify Execute Change Permissions

    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.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

group

Everyone

A

I

A

I

Project: Default

Inherited settings allow the Administrator group full privileges.

Type Name Read Modify Execute Change Permissions

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

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

group

T1-designer

A

A

A

A

group

T1-user

A

I

A

I

Project-B

This project is the same as Project-A.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

group

T2-designer

A

A

A

A

group

T2-user

A

I

A

I

Project-D

This project is the same as Project-C.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

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.

Type Name Read Modify Execute Change Permissions

group

T2-designer

A

I

A

I

group

T2-user

A

I

A

I
Access control scenarios for pipelines, releases, and procedures