DraftValidator cannot see ClusterNode.DriverConfigOverridesJson — the third driver-config persistence surface #499

New Issue

2026-07-25T16:08:59-04:00

dohertj2 commented

2026-07-25 16:08:59 -04:00

Split out of #498.

That issue is fixed for the two config surfaces DraftSnapshot exposes: DriverInstance.DriverConfig and Device.DeviceConfig. There is a third place a driver config blob is persisted — ClusterNode.DriverConfigOverridesJson, the per-node override JSON keyed by DriverInstanceId that is merged onto the cluster-level DriverConfig.

DraftSnapshot carries no ClusterNode collection, so DraftValidator cannot see it. A connectionString pasted into a node override would therefore be persisted into the ConfigDb and replicated, exactly the leak #498 closes elsewhere — just via a surface the validator is structurally blind to.

Two ways to close it, both needing a decision:

Add ClusterNode rows to DraftSnapshot and extend the existing rule. Widens the snapshot (and everything that builds one) for a single rule.
Validate the override JSON where it is authored/saved instead, next to whatever writes DriverConfigOverridesJson.

Also worth deciding while here: whether the rule should generalise beyond Sql + connectionString to a credential-shaped key check across every driver type (password, secret, …). #498 was deliberately kept to the Sql driver as reported, since silently failing an unrelated driver’s deploy would be a regression rather than defence in depth.

Not urgent: node overrides are an uncommon authoring path and the runtime still ignores the key. This is about refusing to store the secret.

Split out of #498. That issue is fixed for the two config surfaces `DraftSnapshot` exposes: `DriverInstance.DriverConfig` and `Device.DeviceConfig`. There is a **third** place a driver config blob is persisted — `ClusterNode.DriverConfigOverridesJson`, the per-node override JSON keyed by `DriverInstanceId` that is merged onto the cluster-level `DriverConfig`. `DraftSnapshot` carries no `ClusterNode` collection, so `DraftValidator` cannot see it. A `connectionString` pasted into a node override would therefore be persisted into the ConfigDb and replicated, exactly the leak #498 closes elsewhere — just via a surface the validator is structurally blind to. Two ways to close it, both needing a decision: 1. Add `ClusterNode` rows to `DraftSnapshot` and extend the existing rule. Widens the snapshot (and everything that builds one) for a single rule. 2. Validate the override JSON where it is authored/saved instead, next to whatever writes `DriverConfigOverridesJson`. Also worth deciding while here: whether the rule should generalise beyond `Sql` + `connectionString` to a credential-shaped key check across every driver type (`password`, `secret`, …). #498 was deliberately kept to the Sql driver as reported, since silently failing an unrelated driver’s deploy would be a regression rather than defence in depth. Not urgent: node overrides are an uncommon authoring path and the runtime still ignores the key. This is about refusing to *store* the secret.

dohertj2 referenced this issue

2026-07-25 16:09:10 -04:00

Deploy-time guard: reject a Sql DriverConfig blob carrying a connectionString key (FF-3) #498

dohertj2 referenced this issue from a commit

2026-07-25 22:44:40 -04:00

merge: Sql driver follow-ups #496/#497/#498 + the Runtime.Tests flake #500 (fix/sql-driver-followups)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#499