Admission and drift behavior
Current source contains several complementary controls. They do not make cluster administrators powerless, and their availability depends on the installed bundle and deployment settings.
Control layers
| Layer | Current behavior |
|---|---|
| Identity-focused admission webhook | Validates mutation identity for managed Deployments and the Manager-supported Nexo custom-resource set |
| Operator reconciliation | Converges generated Deployments, Services, ConfigMaps, and referenced Secrets toward supported desired state |
| Manager drift detector | Periodically compares managed Proxy Deployment state and can revert detected drift |
| Kyverno policies | Validate image and pod-spec controls; enforcement remains gated until signed-digest and audit prerequisites are met |
| Ownership and status | Owner references, labels, annotations, hashes, generations, conditions, and graph revision provide traceability |
Admission scope
The current ValidatingWebhookConfiguration covers managed Deployment update/delete
operations and Nexo custom-resource create/update/delete operations known to Manager.
It is scoped by dedicated namespaces labeled nexo.io/managed=true, not by a Deployment
objectSelector. Do not place unrelated workloads in a managed Proxy namespace.
Manager, Operator, and system:masters have explicit bypasses so reconciliation and
emergency administration do not deadlock. Therefore the legacy statement “only the
Operator ServiceAccount can make changes” is inaccurate.
The current chart defaults admission to failurePolicy: Fail after Manager high
availability is configured. Bootstrap may temporarily use Ignore until the webhook
service and TLS are healthy. A fail-open setting is a security reduction, not a normal
steady state.
Drift detection
The Manager chart currently configures:
tamperProtection:
enabled: true
failurePolicy: Fail
driftCheckInterval: "30s"
autoRevert: true
These are chart defaults, not an immutable service commitment. The drift detector compares managed Deployment state, reports differences, and can reapply desired state. Operator reconciliation independently handles custom-resource ownership and generated resources.
Do not rely on the retired fixed list of “always reverted” fields. Pod-spec content hardening is split between reconciliation and Kyverno policy, while scale and metadata behavior depends on the owning resource and deployment settings.
What direct changes should operators expect?
| Action | Expected current treatment |
|---|---|
| Mutate a managed Deployment in a managed namespace | Subject to admission identity checks and later reconciliation/drift correction |
| Delete a managed Deployment | Subject to admission and ownership reconciliation |
| Mutate a Nexo custom resource | Subject to admission and Operator validation for the registered kind |
| Add an unrelated workload to a managed namespace | Unsupported namespace use; may be affected by namespace-scoped controls |
| Change replicas through the approved Nexo configuration | Supported when represented in desired state |
| Emergency administrator action | Possible through the documented privileged bypass; must be audited and reconciled afterward |
Manager interruption
Proxy traffic and the management path are separate. Existing Proxy pods can continue with the active configuration while Manager or Control Plane connectivity is unavailable, subject to the health of Proxy, Operator, Kubernetes, and MongoDB. New commands, Manager drift checks, and acknowledgements may be unavailable.
The webhook's availability is a separate concern: a fail-closed webhook requires its service to remain available. Current chart defaults use two Manager replicas, a zero-unavailable rolling update, a PodDisruptionBudget, and topology spread to reduce that risk.
TLS
The chart uses a TLS Secret for the webhook and can render a certificate-generation job when a CA bundle is not supplied. The legacy cert-manager and manual OpenSSL snippets are not the authoritative installation procedure. Use the release-specific chart workflow and verify the resulting CA bundle, Secret, Service, and webhook readiness.
0.2.0 and release boundaries
The admission-hardening and integrity work described here was added after the immutable 0.2.0 Private Preview baseline. Do not attribute current fail-closed admission, Manager HA defaults, Kyverno policy set, or periodic integrity monitor to 0.2.0 unless a release-specific manifest explicitly includes them.
See Configuration trust and drift protection and Operator configuration validation.