A controller must defer to Konnect because cached Kubernetes reads can lag behind reality and create stale decisions during reconciliation. If the operator keeps enforcing an outdated local view, it can overwrite valid remote state or miss conflicts. Treating the platform of record as authoritative helps keep desired and observed state aligned and reduces accidental configuration corruption.
Why source-of-truth conflicts are a reconciliation problem, not just a sync problem
Declarative controllers are constantly comparing intent to observed state. When the controller’s local cache lags behind the platform of record, a conflict is not just a stale read, it is a decision-making error. The controller has to resolve state against the authoritative system, otherwise it can keep reconciling toward an outdated snapshot and undo valid changes.
That distinction matters because reconciliation loops are usually idempotent only when the input they trust is current. If the controller treats an eventual-consistent cache as authoritative, it may reapply an already-obsolete desired state, create oscillation between systems, or suppress a real drift condition that should have been handled explicitly.
The source of truth therefore defines which state wins when the controller sees disagreement. In practice, that means the controller must privilege the system that owns the current authoritative record, not whichever read arrived first.
What goes wrong when a controller trusts cached state over authoritative state
The failure mode is overwrite and concealment. A stale local view can make a legitimate remote update look like drift, so the controller “fixes” something that was already corrected elsewhere. In a busy system, that can erase valid configuration, roll back a recent operator action, or reintroduce settings that were intentionally changed for incident response or rollout control.
It also breaks conflict detection. If the controller keeps comparing against cached data, it may never see that another actor has already modified the resource, which means the conflict is not surfaced as a human decision point. Instead, the system silently chooses the wrong winner and continues as if nothing happened.
For declarative systems, that is the deeper risk: the controller becomes an amplifier of stale knowledge. The more automated the loop, the more damaging a wrong authority decision becomes, because the same mistaken assumption can be replayed across many reconcile cycles.
Why “platform of record” is the right authority boundary
The platform of record is the system that owns the latest valid state and can resolve who changed what, when, and under which rules. If Konnect is the place where the canonical configuration lives, then it must dominate conflicting downstream reads because it has the freshest and most complete view of the resource lifecycle.
That does not mean the controller ignores Kubernetes. It means Kubernetes is treated as a projection or execution environment, while Konnect remains the authoritative configuration plane. The controller can still use cluster state for execution feedback, but not as the final judge of desired configuration when the two disagree.
For control planes that span multiple systems, this hierarchy prevents split-brain behavior. The controller can reconcile toward one truth instead of trying to average two incompatible views.
How practitioners should think about conflict handling in this pattern
When a conflict occurs, the safe default is to pause on the stale side and re-read the authoritative side before taking corrective action. The controller should only write after it has revalidated the latest platform state and confirmed that the change still matches the intended configuration.
That makes conflict handling a correctness rule, not a retry rule. Retries alone do not help if the retry loop keeps replaying a wrong assumption about which system is authoritative.
It also means operators should design for observable conflict resolution, not hidden reconciliation. If the controller cannot explain why it chose one state over another, the system is too brittle for reliable declarative management.
Risk and Threat Considerations
Stale authority decisions can create configuration corruption, unintentional rollback, and hidden drift. In a declarative loop, those failures are especially dangerous because they can be repeated automatically until the wrong state becomes persistent.
Failure mechanism: A controller reads outdated cached data, treats it as current truth, and writes a reconcile action that overwrites newer remote state or suppresses a real conflict.
Impact: Operators can lose valid changes, misclassify the true configuration state, and propagate incorrect settings across the environment, increasing outage and recovery risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 — Oversight of Cybersecurity Risk | Authority conflicts create operational risk that needs governance oversight. |
| Recommendation — Define the authoritative state source and require conflict-override rules for reconciliation. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Conflicting writes can corrupt configuration unless changes are controlled and validated. |
| Recommendation — Require controlled, validated configuration updates before reconciliation writes. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | Canonical-state conflicts are a change-management issue because the wrong source can overwrite valid state. |
| Recommendation — Apply change-management checks that verify the authoritative source before applying updates. | ||
Practitioner Guidance
What to verify: Confirm that the controller’s conflict path rechecks the authoritative source before any write, and that cached reads are never treated as the final decision source when the two views disagree.
Decision rule: If the platform of record and the local cache conflict, defer the reconcile write, refresh the authoritative state, and only proceed when the controller can prove it is acting on the latest canonical version.
Practitioner takeaway: A declarative controller should optimise for correctness under stale reads, not for speed of self-healing, because the wrong “fix” is worse than a delayed but authoritative reconcile.
Related resources from NHI Mgmt Group
- When should organisations treat an NHI as a high-priority risk?
- What breaks when organisations treat a source of truth and a system of record as the same thing?
- What breaks when identity reviews do not have a single source of truth?
- Who should own the single source of truth for user and device lifecycle data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
