Artica Wiki

EdgeGuard — Configuration Drift

Whether an agent still runs the configuration it was given: what is watched, why secrets are fingerprinted, and how a baseline is established.

Whether an agent is still running the configuration it was given, or whether somebody has changed it on the machine.

Configuration that comes from the console is already accounted for: every change is in the Audit Log with a name and a time against it. What nothing else sees is a change made on the edge node itself — somebody editing config.json over SSH, a deployment script overwriting it, a restore from a backup taken before a decision was made.

That is drift, and this page is where it appears.

drift-01-list.png

Each row: when it was detected, which agent, which field, what it was, what it became, how serious it is, and who or what changed it.

Turning it on

Global Settings → Compliance → Configuration Drift Detection:

Switch What it does
Enabled compare the configuration against the baseline
Check Interval (sec) how often, for the periodic check
Alert on Drift raise an alert when a difference is found
Auto-Revert put the baseline back automatically
Require Approval hold the change as pending until somebody approves it

Needs engine 3.0.38. Before that, the detector was handed a map containing the time of the last reload and the path of the config file — the only field that could differ between two reloads was a timestamp. It reported that time had passed, and could never report that anything had changed. Every drift event on every installation before that version is about a clock.

What is watched

A chosen list, not the whole file — a detector that reports a changed log level every afternoon is one nobody reads:

Field Why it is on the list
central_url where this agent takes its orders from
central_tls_skip_verify whether it checks who is giving them
central_api_key compared as a fingerprint, never reported as a value
socket_path how nginx reaches the engine
storage_backend, database_path where runtime state and the config cache live
config_pull_enabled, config_pull_interval_seconds whether it still listens to the console, and how often
health_addr, metrics_addr what it exposes, and to where
log_level how much it records

Those are the fields somebody edits on a machine they have reached. The first two are the ones to read first: an agent pointed at a different central, or one that stopped verifying TLS, is a different problem from a changed socket path.

Secrets are compared as fingerprints. That the agent key changed is the finding; what it changed to does not belong in an event that travels to the console and into a compliance report. A fingerprint still detects a rotation — two different keys give two different fingerprints — without printing either.

Severity

Severity When
critical a field that decides behaviour or carries a credential changed — enabled, action, threshold, a key, a certificate
high a field was removed
medium more than five fields changed at once, or an ordinary edit
low everything else

The baseline

Taken at startup: the file as it is when the agent begins. Every later comparison is against that, so the first reload after a restart reports nothing rather than reporting every field as new.

Re-establishing the baseline deliberately — after a change you meant to make — is a restart of the agent. There is no "accept this drift" button yet, and this page says so rather than implying one.

Reading a drift event

Start with who. The changed_by column distinguishes startup, config_reload and a person. A reload with changes behind it means the file on that machine is not what it was.

Then what. One field changed is an edit. Eight fields changed at once is a file replaced — a deployment, a restore, or a different machine's configuration copied over.

Then when. Drift detected at three in the morning during a deployment window is one story. The same drift on a Sunday is another.

Verifying

1. Confirm the baseline exists. Restart the agent and watch its log for the drift detector starting. Nothing should be reported: a baseline compared against itself is not drift.

2. Make some, on purpose. On the agent, change something harmless in config.json — the log level — and reload the engine:

# On the agent host
sed -i 's/"level": "info"/"level": "debug"/' /etc/artica-edgeguard/config.json
systemctl reload artica-edgeguard-agent   # or however this host reloads it

Within a minute the event appears here, naming log_level, info → debug.

3. Check a secret is not printed. Change the agent key and confirm the event says the fingerprint changed, and shows neither the old key nor the new one.

Where drift detection is the wrong tool