Shared Configuration Options

This page documents the configuration fields that appear across multiple Coordimap data sources.

What Is scope_id?

scope_id is the stable identity of the upstream system boundary that Coordimap is crawling.

Think about it this way:

• data_source_id identifies the connector configuration you created in Coordimap.
• scope_id identifies the real system that owns the assets.

That distinction matters because Coordimap builds internal asset IDs from the upstream identity, not from the connector record. If you delete and recreate a data source, keeping the same scope_id allows Coordimap to keep those asset identities stable.

data_source_id

data_source_id is created by Coordimap when you add a data source in the UI. Use it to tell the agent which connector configuration it should send data for.

Do not use data_source_id as a replacement for scope_id. They serve different purposes.

scope_id

Every data source should provide a scope_id that comes from the platform being crawled.

Use the most stable upstream identity available:

• Kubernetes: cluster UID
• GCP: project number
• AWS: account ID
• PostgreSQL: system identifier
• MySQL or MariaDB: server UUID
• MongoDB: replica set or cluster identity

What Is external_mappings?

external_mappings is used when one integration needs help relating observed identities back to another scoped system.

In plain terms, it is a manual hint that tells Coordimap, "when you see this value from one integration, treat it as belonging to that other identity boundary."

The format is:

<mapping-key>@<mapping-value>

Examples:

europe-west1-my-gke-cluster@6f5f56e3-0123-4567-89ab-6c8f1e2a0cde
*@6f5f56e3-0123-4567-89ab-6c8f1e2a0cde
gke-node-pool-a@gcp-production

Interpretation depends on the integration:

• In GCP flow mappings, the key may be a GKE-related identifier seen in flow metadata, while the value should be the Kubernetes cluster UID used as scope_id.
• In the eBPF flows datasource running in Kubernetes mode, the value should point to the Kubernetes cluster UID so runtime traffic attaches to the correct cluster assets.
• In Kubernetes-related cloud mappings, the value may point to another datasource or stable external identity used for correlation.

The safest rules are:

• keep the key exactly aligned with what the upstream system emits
• keep the value stable
• when mapping to Kubernetes scope, use the Kubernetes cluster UID

Recommended scope_id by Data Source

How To Find Your scope_id

Use these commands and conventions when you configure a new data source.

Kubernetes

Use the cluster UID:

kubectl get namespace kube-system -o jsonpath='{.metadata.uid}'

GCP

Use the project number:

gcloud projects describe PROJECT_ID --format='value(projectNumber)'

AWS

Use the AWS account ID:

aws sts get-caller-identity --query Account --output text

PostgreSQL

Use the PostgreSQL system identifier:

SELECT system_identifier FROM pg_control_system();

If pg_control_system() is not available in your environment, retrieve the value with PostgreSQL system tooling such as pg_controldata.

MySQL Or MariaDB

Use the server UUID:

SHOW VARIABLES LIKE 'server_uuid';

If server_uuid is not available, use an explicitly configured stable value.

MongoDB

Use a replica set or cluster identity when your deployment exposes one:

rs.conf()
rs.status()

If no immutable ID is available, the replica set name is an acceptable fallback. For standalone MongoDB deployments, use an explicitly configured stable scope_id.

crawl_interval

crawl_interval controls how often the agent crawls a data source for changes.

Examples:

• 45s for 45 seconds
• 3m for 3 minutes