ThreatMapper icon indicating copy to clipboard operation
ThreatMapper copied to clipboard

Add ability to read cloud region and cloud provider from env variables

Open Josh5 opened this issue 8 months ago • 0 comments

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.

Josh5 avatar Aug 17 '25 06:08 Josh5