SetDataplaneConfigOverride
POST/admin/v1/dataplanes/:id/config-overrides
Override one whitelisted field on one data plane.
Exactly one of value and key carries the override, and which one is
decided by the field path: providers.<provider>.endpoint takes value,
and providers.<provider>.key takes key. A field path outside the
whitelist is rejected with INVALID_ARGUMENT naming the two paths a
provider offers.
A repeat write replaces the value the field held. Every write lands in the audit log with the field path, the data plane and the actor, and the data plane it names regenerates its configuration, so it carries the override on its next pull.
A credential is stored write-only: it goes to the secret service and the override keeps a reference the data plane resolves, which resolves for that data plane alone.
A write needs the project labelled on the data plane, and answers
FAILED_PRECONDITION naming both when it is not: label the project onto the
data plane first. A project that does not exist answers NOT_FOUND. A write
to an external provider is refused for both fields, and a credential
override for a provider whose auth type is none is refused, because a
data plane never reads a credential for that provider. A data plane below
the version that renders per-project provider objects is refused for both
fields.
An override reaches the project's requests on every route family the
data plane serves it through: the shared catalog routes, the fallback
chains and the routes of the project's own keys. A request authenticated
with a key the caller brought themselves (BYOK) keeps dialling the bundle
endpoint with the caller's key. On a deployment that registers an
external autofallback-<provider> catalog entry, the primary leg routed
through that service is not covered.
Request
Responses
- 200
Success