Add ability to read cloud region and cloud provider from env variables #2426
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #
Changes proposed in this pull request:
Adds support for
CLOUD_PROVIDERandCLOUD_REGIONenv 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
The node will now appear under Private Cloud → onprem-zone1 in the topology view.
Notes