Skip to content

Conversation

@Josh5
Copy link

@Josh5 Josh5 commented Aug 17, 2025

Fixes #

Changes proposed in this pull request:

Adds support for CLOUD_PROVIDER and CLOUD_REGION env vars.
When set, these values take precedence over automatically detected metadata that we set the values to be that of the "default cloud" (which seem wrong for some conditions).
If unset, existing detection logic remains unchanged.

Motivation

Currently, when the agent cannot detect a recognised cloud provider, it defaults to classifying the node under "serverless". This results in all such hosts being grouped under a single "Serverless" cloud provider in the UI even for on-prem or private cloud deployments.

While “serverless” makes sense for Lambda/Fargate environments, it is misleading as the default fallback. For people running ThreatMapper across mixed environments (e.g. private datacenters, non-cloud VMs, custom providers), the grouping is inaccurate and confusing.

This change allows users to explicitly configure provider/region when auto-detection is insufficient.

Example

docker run -dit \
    --cpus=".2" \
    --name=deepfence-agent \
    --restart on-failure \
    --pid=host \
    --net=host \
    --log-driver json-file \
    --log-opt max-size=50m \
    --privileged=true \
    -v /sys/kernel/debug:/sys/kernel/debug:rw \
    -v /var/log/fenced \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /:/fenced/mnt/host/:ro \
    -e DF_LOG_LEVEL="info" \
    -e CUSTOM_TAGS="" \
    -e MGMT_CONSOLE_URL="---CONSOLE-IP---" \
    -e MGMT_CONSOLE_PORT="443" \
    -e DEEPFENCE_KEY="---DEEPFENCE-API-KEY---" \
    -e http_proxy="" \
    -e https_proxy="" \
    -e no_proxy="" \
    -e CLOUD_PROVIDER=private_cloud \
    -e CLOUD_REGION=onprem-zone1 \
    quay.io/deepfenceio/deepfence_agent_ce:2.5.7

The node will now appear under Private Cloud → onprem-zone1 in the topology view.

Notes

  • No existing behaviour is broken: if the variables are not set, the previous detection logic and defaults are used.
  • Logging was added to make it clear when overrides are in effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants