To mitigate vulnerabilities, CloudBees recommends the following essential measures and recommendations for agent configuration in a non-clustered mode.
Limit agent privileges
Managing your CloudBees CD/RO agents privileges is critical to the overall security of your environment. CloudBees CD/RO agents can perform nearly any operation within your environment, and if given excessive privileges, security risks become inherent.
Do not run the agent service as a ROOT user
An essential distinction for CloudBees CD/RO agents is the difference between installing an agent using a sudo or ROOT installation and running the agent service using a sudo or ROOT user. The agent user and group are configured during installation, and are not assigned based on the user running the installer.
There is very little inherent risk involved in performing a ROOT agent installation, and it is often required. However, there are critical security risks if the agent service runs through a sudo or ROOT user account, as this grants agents almost unlimited ability to add, use, modify, and delete agent host files and configurations. Additionally, granting the agent service sudo or ROOT privileges also may allow the agent unlimited external communication permissions.
|
In production environments, or in long-running development or testing environments, you should not install an agent on the server host or give access to the server file system. If you do, then never allow agent services to run through a This greatly increases critical security risks, since it allows your agent to read the server passkey, change database configurations, and access and modify system resources. |
If you are currently running agents through a user with sudo or ROOT privileges, CloudBees strongly recommends:
-
If your server and agents are on different machines:
-
Uninstall your agent. For more information, refer to Uninstall CloudBees CD/RO on Linux, Unix, or macOS.
-
Reinstall a new agent using a different with an agent user that does not have
sudoorROOTprivileges. For more information, refer to either:In production environments, CloudBees strongly suggests you install the CloudBees CD/RO server and agent on different machines. For more information, refer to Install servers and agents on different machines. -
Restore your backup in the new CloudBees CD/RO instance. For more information, refer to Restore a CloudBees CD/RO server.
-
-
If your server and agents are on the same machine:
-
Perform a backup of your current CloudBees CD/RO server. For more information, refer to Back up a CloudBees CD/RO server.
-
Uninstall CloudBees CD/RO. For more information, refer to Uninstall CloudBees CD/RO on Linux, Unix, or macOS.
If you are using CloudBees Analytics, it will not be uninstalled as part of this process. -
Reinstall CloudBees CD/RO using a separate non-
sudoor non-ROOTuser account for the agent. For more information, refer to either:In production environments, CloudBees strongly suggests you install the CloudBees CD/RO server and agent on different machines. For more information, refer to Install servers and agents on different machines. -
Restore your backup in the new CloudBees CD/RO instance. For more information, refer to Restore a CloudBees CD/RO server.
-
Restrict agent user access
As previously described, you should never allow your agent services to run using a user account with sudo or ROOT privileges in production environments. As a further mitigating step, you should also restrict agent user account access to only the required system directories, and adhere to the "Principle of least privilege" (PoLP). This step is vital in preventing unauthorized file system access and data exposure should an agent become compromised.
The key point in this mitigation step is to limit the overall scope of access a compromised agent would have to your environment. CloudBees always recommends that you follow PoLP, where the agent user account is only allowed the minimal privileges required to perform its core functions.
If you are currently using an agent user with excessive system access, CloudBees strongly advises you minimize the permissions to only those needed to perform the functions required of the agent.
|
If making changes to permissions of the agent user, at a minimum, the agent user must have |
Run servers and agents as separate users on same machine
If you are running the CloudBees CD/RO server and agents of the same machine, it is critical to use separate users for these services. Using the same user account for both services is the same as running the agent service as a sudo or ROOT within the CloudBees CD/RO environment.
During installation, you must assign a user account for the CloudBees CD/RO servers:
Specify the user the server, web, and/or repository will run as. [<currentUser>]
This server user account owns all resources within the installation directory, and has access to the passkey, database configuration, and permissions to use and modify system resources used by CloudBees CD/RO.
This user is not required to be a sudo or ROOT user. Additionally, this operating system user is not the same as a CloudBees CD/RO admin user.
|
You must also assign a user account for agents:
Use the same service account for the agent (not recommended for production systems)? [y/N]
|
You should never use the same user account for server and agent services in production environments, or in long-running development or testing environments. Using the same user account for both services is the same as running the agent service as a By default, the agent user account has access to the required resources for it to run. However, using the same account for both services greatly increases the agent user privileges and introduces multiple critical security risks. These include allowing your agent user to read the server passkey, change database configurations, and access and modify system resources allotted to CloudBees CD/RO. |
Here, you should always select N in production environments, which results in the following prompts:
Use the same service account for the agent (not recommended for production systems)? [y/N] N
Specify the user the agent will run as. []
Specify the group the agent will run as. []
Assigning agent user privileges separate from the server user is crucial for minimizing the impact of security breaches. Ensure the agent runs under a dedicated user account, different from the server user account.
If you are currently using the same service account for the server and agent on the server host, CloudBees strongly recommends you:
-
Perform a backup of your current CloudBees CD/RO server. For more information, refer to Back up a CloudBees CD/RO server.
-
Uninstall CloudBees CD/RO. For more information, refer to Uninstall CloudBees CD/RO on Linux, Unix, or macOS.
If you are using CloudBees Analytics, it will not be uninstalled as part of this process. -
Reinstall CloudBees CD/RO using a separate non-
sudoor non-ROOTuser account for the agent. For more information, refer to either:In production environments, CloudBees strongly suggest you install the CloudBees CD/RO server and agent on different machines. For more information, refer to Install servers and agents on different machines. -
Restore your backup in the new CloudBees CD/RO instance. For more information, refer to Restore a CloudBees CD/RO server.
Implement isolation strategies
To enhance security through isolation, consider implementing one of the following strategies. Implementing these measures can significantly improve your system’s security posture and effectively mitigate potential vulnerabilities.
Install servers and agents on different machines
The CloudBees CD/RO server manages automation, deployment pipelines, and external communication and API calls with various third-party tools and systems. It controls the core logic, configuration, and sensitive data for your environment. Additionally, it handles access control and writes to your database. This makes maintaining the CloudBees CD/RO server in a secure environment critical to whatever operations your organization are trying to accomplish.
Agents are only the server execution nodes that perform tasks when directed by the server, such as running build processes, deploying applications, and other automated jobs. By their nature, agents are meant to be somewhat ephemeral, and have virtually no access to any underlying system resources.
For production environments, or long-running development and testing ones, CloudBees always suggests you install the CloudBees CD/RO server and agents on separate machines. These components perform completely separate functions, and should be isolated from each other to avoid critical security risks.
When servers and agents are installed and run on the same machine, there is always some inherent risk of privilege escalation and data exposure. Additionally, when both are installed on the same machine, you greatly increase the vulnerable points bad actors can use to infiltrate your environment.
To install the CloudBees CD/RO server and agent on different machines, you must use either:
|
When running either of these installation methods for production environments, CloudBees strongly suggests you use a separate machine for each component:
If you select to install either the web or the repository servers on the same machines as the CloudBees CD/RO sever, an agent is also automatically installed on the machine. To only install the server, the CLI install will be:
To install only the server using the UI option, the UI install will be: 
Figure 1. UI advanced installation of only CloudBees CD/RO server
|
Docker container
Run the agent inside the controlled environment of a Docker container. A Docker container limits the agent’s access to the host system and reduces the risk of unauthorized access to critical parts of the file system.
You can find the Docker containers for CloudBees CD/RO components with the following links:
Use chroot
The chroot command can also be used achieve a secure and isolated environment for the agent. This approach changes the apparent root directory for the current running process and its children, creating an isolated environment.
For more information, refer to the Ubuntu BasicChroot documentation.
Perform regular audits of agent privileges
Regularly auditing agent privileges is crucial for maintaining a secure and efficient environment. Over time, agents may accumulate excessive permissions that exceed their original scope, which can lead to security vulnerabilities.
By performing regular audits, you can help ensure agents only have the necessary privileges to perform their tasks. This minimizes the risk of unauthorized access to sensitive data and critical systems.
Additionally, regular audits help identify and mitigate potential risks associated with privilege escalation and insider threats. As agents' roles and responsibilities evolve, their access requirements may change. Regular auditing allows you to detect and correct issues before privilege misuse or accidental data exposure occur.