Configuration trust and drift protection

Nexo configuration crosses several trust boundaries before it becomes active database policy. Each boundary must reject invalid or untrusted state rather than silently activating a partial graph.

Desired-state chain

1. An authorized user creates or changes a versioned configuration.
2. The Control Plane validates the requested product and entitlement state.
3. Manager receives approved desired state for its environment.
4. Operator resolves references and validates the supported graph.
5. Operator renders namespaced Kubernetes resources.
6. The Proxy activates the validated runtime graph and reports the active revision.

Record both the desired revision and the active revision. A successful browser action is not sufficient evidence that the data plane changed.

Pre-deployment schema validation

Where a runtime schema is registered, Operator validates the rendered component configuration before writing the related ConfigMap or Deployment.

Result	Behavior
Valid	Reconciliation can continue.
Invalid	Reconciliation fails closed and the previous valid runtime remains the recovery point.
No registered schema	Operator cannot provide the same field-level pre-deployment guarantee.

In the current implementation, enforced schema validation is narrower than the complete component catalog. Do not infer validation coverage from CRD installation alone.

Step provenance

The signed provenance enforcement described in this section was added after the 0.2.0 Private Preview and applies only to releases that explicitly publish it.

Release bundles can carry signed step provenance and expected digests. The Control Plane and Operator compare available claims with the approved step catalog and treat missing or mismatched required trust evidence as untrusted.

Provenance establishes artifact identity and release lineage. It does not prove that a pipeline configuration is safe for a particular workload.

Kubernetes ownership and drift

Generated Deployments, Services, ConfigMaps, and Secret copies are owned by the appropriate Nexo custom resource. Operator reconciliation is responsible for converging managed resources toward approved desired state and reporting conditions when it cannot.

Do not manually patch generated workloads as a normal deployment mechanism. A later reconciliation may replace the patch, and the active configuration would no longer be traceable to an approved revision.

Management interruption

The management path and database traffic path are separate. Loss of Control Plane or Manager connectivity must not be treated as permission to bypass policy or hand-edit managed workloads.

• Monitor the age of the last successful acknowledgement.
• Confirm which graph revision remains active.
• Avoid publishing new changes until management connectivity and trust checks recover.
• Test the expected behavior for management outage in each environment.

0.2.0 boundaries

The 0.2.0 chart installs more CRD schemas than its pinned Operator registers. Some resources can exist without affecting the data path, and selected resources require reconciliation of the owning NexoProxy after edits. Consult the CRD catalog and verify the active graph revision.

Admission and drift details

See Admission and drift behavior for current webhook scope, Manager drift detection, Kyverno boundaries, management interruption, and the controls that must not be attributed to 0.2.0.