Vault Radar agent deployment (hybrid)

Prerequisites

Outbound connectivity to the HCP platform
An agent pool in the HCP Portal
An HCP project level service principal with the Vault Radar agent role assigned
Base 64 encoded data source credential (e.g. GitHub/GitLab personal access token (PAT), Bitbucket HTTP access token, etc.)

The agent supports scanning within a private network. It connects with HCP for licensing and uploading only metadata to provide centralized secret risk inventory. It does not send secret values or sensitive information to HCP.

For deploying the agent, follow the Deploy Vault Radar Agent documentation page. Kubernetes is currently our recommended platform for deploying the Agent. You are welcome to extrapolate the configuration for other platforms, but we cannot guarantee support for that platform at this time.

Minimum resource requests:

CPU: 100 or (0.1 GHz)
Memory: 1GB

Maximum resource requests:

CPU: 3000 or (3 GHz)
Memory: 4GB

These are general recommendations that have worked for a broad range of workloads. We recommend you start with these and adjust depending on your workloads and data type/structure.

Note that in our Kubernetes manifest sample, we have set up a secret and environment variable for connecting to our data sources, in this case a GitHub PAT. You can set up any supported code server token like the GitHub PAT example below, by creating a Kubernetes Secret resource, and injecting it as a Kubernetes deployment environment variable.

Note

You can use a different variable name. But you must be consistent with the name when configuring the data source below.

If you are using a Linux server, set an environment variable manually at the target machine:

export VAULT_RADAR_GIT_TOKEN=<YOUR_GITHUB_PAT>

After the agent connects and is running, add a data source for scanning. At the Vault Radar portal page, click on Settings > Data Sources > Add Data Source. Select Vault Radar Agent Scan:

Select Vault Radar Agent Scan option

Select your Code Server and fill the connection information. Enter the environment path for your code server access token in the last field:

Configure code server connection settings

Check that the URI entered is correct. It should be env://<YOUR_VARIABLE_NAME>. In the example this is: env://VAULT_RADAR_GIT_TOKEN

Click next and wait for the agent to validate the configuration. On the next page, select repositories to monitor to set up the data source. When ready you can select finish.

For additional information, please check the Deploy Vault Radar agent page.

Agent horizontal scaling

Scaling the agent is more complex due to its nature. It handles a variety of operations and is in theory, always running. The agent is horizontally scaled and there are some configuration options available to optimize the agent pool.

By default when the Agent starts, it runs and polls for all types of work. The works best when the aim is scanning happen in the background. When the operation is one with a user waiting for the results, it can result in users waiting for results behind other workloads.

One way to address this is to deploy more agents using the same Agent Pool ID to scale the agent. A better approach is to refine the agent deployment to only run a specific workload. This allows users to scale multiple agent deployments to handle background scanning and user facing workloads like PR Scanning.

Workload	Purpose	Interaction Type	Command (Default to `true`)
Full resource scanning	This is a full scan of a resource. This is typically something that happens as a background task, but users can request an ad-hoc full scan.	Typically background	`AGENT_POLL_RESOURCE_SCAN_JOB_ENABLED`
Webhook content scanning	This is a scan of some change to a resource (like a commit to a repository). This is generally a background operation.	Typically background	`AGENT_POLL_CONTENT_SCAN_JOB_ENABLED`
Data source onboarding	These workloads are requests made as part of onboarding a new data source. Often a user is expecting this to complete quickly.	Typically user facing	`AGENT_POLL_HTTP_JOB_ENABLED`
Pull request scanning	This workload is responsible for scanning a PR and annotating the contents. This is a user facing operation.	Typically user facing	`AGENT_POLL_PULL_REQUEST_SCAN_JOB_ENABLED`
Copy secrets	This workload is responsible for handling Copy Secrets. This is also typically a user facing operation.	Typically user facing	`AGENT_POLL_COPY_SECRETS_JOB_ENABLED`

An example of how to use this by creating two deployments is below. Both deployments share the same Agent Pool ID, Service Principals, and any Credentials. The first deployment is for background operations only. To do that disable the user facing operations flags by setting:

AGENT_POLL_COPY_SECRETS_JOB_ENABLED=false
AGENT_POLL_PULL_REQUEST_SCAN_JOB_ENABLED=false
AGENT_POLL_HTTP_JOB_ENABLED=false

And in the other deployment we can disable the background workload flags by setting:

AGENT_POLL_CONTENT_SCAN_JOB_ENABLED=false
AGENT_POLL_RESOURCE_SCAN_JOB_ENABLED=false

Scale these two deployments separately depending on the need for background or user facing scanning.

Set up Vault Radar

Use Vault Radar in pipelines