DraftValidator cannot see ClusterNode.DriverConfigOverridesJson — the third driver-config persistence surface #499
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Split out of #498.
That issue is fixed for the two config surfaces
DraftSnapshotexposes:DriverInstance.DriverConfigandDevice.DeviceConfig. There is a third place a driver config blob is persisted —ClusterNode.DriverConfigOverridesJson, the per-node override JSON keyed byDriverInstanceIdthat is merged onto the cluster-levelDriverConfig.DraftSnapshotcarries noClusterNodecollection, soDraftValidatorcannot see it. AconnectionStringpasted 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:
ClusterNoderows toDraftSnapshotand extend the existing rule. Widens the snapshot (and everything that builds one) for a single rule.DriverConfigOverridesJson.Also worth deciding while here: whether the rule should generalise beyond
Sql+connectionStringto 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.
Fixed on
fix/issues-503-501-493-499-488, commit2193d9f2, live-verified.Neither of the two options as stated — gated at the SAVE. Reasoning:
ClusterNodeintoDraftSnapshot) widens the snapshot and every builder of one for a single rule about a value that never enters the artifact.The check moved into a shared
SqlCredentialGuardso the two enforcement points cannot drift;DraftValidatornow calls it instead of its own private helper.On generalising to credential-shaped keys across all drivers: not doing it, for the reason #498 gave. A broader sweep would start refusing configs that are legitimate today for drivers which never made an indirect-credential guarantee — a regression, not defence in depth. Widen per driver as each gains its own contract.
The error names the offending instance(s) and never the value.
Live gate (docker-dev, real Sql driver
DRV-73f6a1061cfein MAIN):{"DRV-73f6a1061cfe":{"connectionString":"Server=sql,1433;…;Password=hunter2"}}into the node's override box → save refused, banner: "Driver config overrides carry a 'connectionString' for Sql driver instance(s) DRV-73f6a1061cfe… Remove the key." No credential text in the message.ClusterNode.DriverConfigOverridesJsonstillNULLin SQL.{"DRV-73f6a1061cfe":{"connectionStringRef":"Sql:Line3","commandTimeoutSeconds":45}}→ saved, verified in SQL. Rig restored afterwards.⚠️ The live gate found the editor page was completely dead, both defects pre-existing on master and unrelated to this change — fixed in
4cc0215b, see the note I am filing separately. Without them this guard was unreachable by any operator.14 new
SqlCredentialGuardTestscover both surfaces, case variants (System.Text.JsonbindsConnectionStringtoconnectionString, so a case variant is the same key, not a bypass), non-Sql ids being ignored, and every blank/malformed/non-object shape. Configuration.Tests 131/131.