- Smarty 100%
This repository has been identified as part HCP's compliance boundary (either directly or transitively as a dependency of another repository) and requires updates to its associated PR template. This PR adds the suggested template changes, but you may reformat them in a way that makes sense for your repository and workflow. What you need to do: - Review the PR template changes proposed in this PR - (Optional) Make any edits as necessary, ensuring that the comment including `heimdall_github_prtemplate` is preserved - Approve and merge the PR Co-authored-by: compliance-pr-automation[bot] <1425255+compliance-pr-automation-bot[bot]@users.noreply.github.com> |
||
|---|---|---|
| .github | ||
| templates | ||
| .gitignore | ||
| .helmignore | ||
| Chart.yaml | ||
| README.md | ||
| values.yaml | ||
Deploy Vault Radar Agent to Kubernetes
This guide walks through a deployment of Vault Radar Agent to a Kubernetes cluster using Helm. This is simply a bootstrap example and should be modified with best practices and thoroughly tested before any type of production deployment.
Prerequisites
- Kubernetes cluster
- HCP Vault Radar access
- HCP service principal and key
Create an Agent in the HCP Vault Radar Portal
- Create a service principal and key
- Create a service principal and service principal key
- Copy and save the "Client ID" and "Client Key" to use later
- Create an agent
- Log in to the HCP portal
- Select "Vault Radar" from the navigation menu
- In Vault Radar navigate to "Settings" then select "Agent" from the navigation menu
- Select the "+ Add an Agent" button
- Give it a name
- Copy and save
HCP_PROJECT_IDandHCP_RADAR_AGENT_POOL_IDto use later - Select the "Install Agent" button
Set Environment Variables
Collect the following values before running any Helm commands:
HCP_CLIENT_ID— Client ID from the HCP service principalHCP_CLIENT_SECRET— Client key from the HCP service principalHCP_PROJECT_ID— Project ID retrieved when creating the agentHCP_RADAR_AGENT_POOL_ID— Agent pool ID retrieved when creating the agentVAULT_RADAR_GIT_TOKEN— A Git token with read access to the target repositories- For GitHub or GitLab: use a personal access token (PAT)
- For BitBucket and Azure DevOps: use the format
<username>:<PAT>
Export these as environment variables in your shell:
export NAMESPACE=vault-radar
export HCP_PROJECT_ID=
export HCP_RADAR_AGENT_POOL_ID=
export HCP_CLIENT_ID=
export HCP_CLIENT_SECRET=
export VAULT_RADAR_GIT_TOKEN=
Note: The image tag defaults to the
appVersiondeclared in Chart.yaml. To deploy a different version, add--set image.tag=<version>to any Helm command below.
Deploy
Dry Run
Validate the rendered manifests before installing:
helm upgrade --install --dry-run \
--create-namespace \
--namespace $NAMESPACE \
--set env.normal.HCP_PROJECT_ID=$HCP_PROJECT_ID \
--set env.normal.HCP_RADAR_AGENT_POOL_ID=$HCP_RADAR_AGENT_POOL_ID \
--set env.normal.HCP_CLIENT_ID=$HCP_CLIENT_ID \
--set env.secrets.HCP_CLIENT_SECRET=$HCP_CLIENT_SECRET \
--set env.secrets.VAULT_RADAR_GIT_TOKEN=$VAULT_RADAR_GIT_TOKEN \
vault-radar-agent . --debug
Install
helm upgrade --install \
--create-namespace \
--namespace $NAMESPACE \
--set env.normal.HCP_PROJECT_ID=$HCP_PROJECT_ID \
--set env.normal.HCP_RADAR_AGENT_POOL_ID=$HCP_RADAR_AGENT_POOL_ID \
--set env.normal.HCP_CLIENT_ID=$HCP_CLIENT_ID \
--set env.secrets.HCP_CLIENT_SECRET=$HCP_CLIENT_SECRET \
--set env.secrets.VAULT_RADAR_GIT_TOKEN=$VAULT_RADAR_GIT_TOKEN \
vault-radar-agent .
To enable Vault Kubernetes auth, add the following flag to either command above:
--set rbac.enabled="true" \
Uninstall
helm uninstall vault-radar-agent -n $NAMESPACE
Advanced Configuration
Setting Log Level
To deploy the agent with a specific log level, add the following flag to the install command:
--set env.optional.VAULT_RADAR_LOG_LEVEL="<log-level>" \
where <log-level> is your desired log level (e.g. debug, info, warn, error).
Deploying with Multiple Workers
The chart supports multiple workers (Deployments) within a single Helm release. Each worker can be configured to handle specific job types using AGENT_SERVICE_ENABLE_LIST or AGENT_SERVICE_DISABLE_LIST.
Note: You can only provide either
AGENT_SERVICE_ENABLE_LISTorAGENT_SERVICE_DISABLE_LISTper worker, not both.
Single worker (default)
By default, the chart deploys a single worker that handles all job types. Use the Install command above.
Multiple workers (separating job types)
To deploy separate workers for different job types (e.g., isolate PR scanning from other scans), add the following flags to the Install command:
--set workers.items.default.env.AGENT_SERVICE_DISABLE_LIST="pull_request_scan" \
--set workers.items.prScan.enabled="true" \
--set workers.items.prScan.name="pr-scan" \
--set workers.items.prScan.replicaCount="2" \
--set workers.items.prScan.env.AGENT_SERVICE_ENABLE_LIST="pull_request_scan" \
This creates:
- default worker: handles all job types except PR scanning (1 replica)
- pr-scan worker: dedicated to PR scanning only (2 replicas)
Both workers share the same ServiceAccount and Secret, but can be scaled and configured independently.
Worker configuration options
Each worker in workers.items supports:
| Option | Description | Default |
|---|---|---|
enabled |
Enable/disable the worker | true |
name |
Name suffix for the Deployment (required) | — |
replicaCount |
Number of replicas | 1 |
resources |
CPU/memory limits and requests as key-value pairs | limits: 1000m/3072Mi, requests: 100m/1024Mi |
nodeSelector |
Schedule pods on nodes with specific labels as key-value pairs (e.g., disktype: ssd) |
{} |
tolerations |
Allow pods to be scheduled on nodes with matching taints as a list of toleration objects | [] |
affinity |
Advanced scheduling rules for pod placement as key-value pairs (node affinity, pod affinity/anti-affinity) | {} |
env |
Worker-specific environment variables as key-value pairs | {} |
Enabling or disabling job types for a worker
Use the env option to control which job types a worker handles:
AGENT_SERVICE_ENABLE_LIST: comma-separated list of job types to enable (worker handles only these)AGENT_SERVICE_DISABLE_LIST: comma-separated list of job types to disable (worker handles all except these)
Note: You can only use one of these per worker, not both. When using
--set, escape commas with\,.
Available job types
| Job Type | Description |
|---|---|
http |
Handles HTTP webhook requests for on-demand scanning |
resource_scan |
Scans configured data sources (repos, buckets, etc.) |
content_scan |
Scans content/files for secrets |
pull_request_scan |
Scans pull requests and merge requests for secrets |
secrets_copy |
Copies discovered secrets to HashiCorp Vault for remediation |
Example — disable PR scanning and content scanning on the default worker:
--set workers.items.default.env.AGENT_SERVICE_DISABLE_LIST="pull_request_scan\,content_scan" \