A mirror control plane keeps the authoritative configuration in Konnect while Kubernetes reflects it in a read-only form. Direct management in Kubernetes makes the cluster the active place where configuration is authored and changed. The distinction matters because mirror mode supports separation of duties, while direct management concentrates operational control inside the cluster.
Why This Matters for Security Teams
The choice between a mirror control plane and direct gateway management changes where trust, approval, and rollback authority live. In mirror mode, the cluster becomes a reflection layer, which helps reduce accidental drift and supports stronger separation of duties. Direct management in Kubernetes can be faster for operators, but it also increases the chance that cluster access becomes the de facto control point for production policy. That difference affects auditability, incident response, and who can safely approve changes.
Security teams often underestimate the operational risk of treating “where the config lives” as a minor implementation detail. A control plane strategy determines whether policy changes are governed centrally or edited inside the deployment environment, which directly affects privilege boundaries and change evidence. For a broader resilience lens, the NIST Cybersecurity Framework 2.0 is useful because it emphasizes governance, protection, detection, and recovery as connected outcomes rather than isolated tasks.
In practice, many security teams discover the governance gap only after a rushed emergency change has already bypassed the intended approval path.
How It Works in Practice
In mirror mode, the authoritative source of truth stays outside the cluster, and Kubernetes receives a read-only projection of the gateway state. That means the cluster can observe and apply the desired configuration, but it should not become the place where operators create or edit policy. This pattern is useful when platform teams want a central review workflow, consistent promotion between environments, and clearer evidence of what changed, when, and by whom.
Direct management works differently. The cluster is not just a runtime target; it becomes the authoring surface for route definitions, plugins, policies, or other gateway settings. That can simplify local operations, especially in smaller environments or when the people running the cluster also own the gateway behaviour. The tradeoff is that cluster privileges now carry configuration authority, so Kubernetes RBAC, admission controls, and secret handling become part of the gateway governance model.
- Mirror mode suits organisations that need a strong separation between policy owners and cluster operators.
- Direct management suits teams that prioritise speed and have mature cluster governance already in place.
- Both models still require version control, review, and rollback discipline.
- Neither model removes the need to monitor for drift, unauthorized change, or stale desired state.
Teams should also treat change propagation as an operational control, not just a sync mechanism. If the upstream control plane is authoritative, then downstream reconciliation should be observable and tamper-resistant. If Kubernetes is authoritative, then the cluster becomes a higher-value administrative target and should be protected accordingly. These controls tend to break down in multi-tenant clusters with broad admin access because authority, observability, and change approval are too easy to collapse into the same credentials.
Common Variations and Edge Cases
Tighter central control often increases workflow overhead, requiring organisations to balance faster local changes against stronger review and traceability. That tradeoff becomes sharper when multiple teams share the same gateway estate or when regulated workloads need hard evidence of approval paths. Best practice is evolving here, and there is no universal standard for every operating model.
Some environments use a hybrid approach, with central policy definitions mirrored into clusters while a limited set of environment-specific overrides remains local. That can work, but only if the boundary is explicit and the override scope is tightly constrained. Other environments prefer direct Kubernetes management for lower latency or simpler GitOps alignment, but that should be paired with strong RBAC, admission policy, and immutable audit logging. Where identity intersects with this question, the key issue is whether human and non-human operators have clearly separated privileges for authoring, approving, and deploying gateway changes.
Edge cases arise when the cluster is temporarily disconnected from the authoritative control plane, when emergency changes are needed during an incident, or when teams assume reconciliation will “eventually fix” unsafe edits. In those cases, the governance model matters more than the tool choice itself. If operational ownership is unclear, mirror mode can create stale expectations, while direct mode can turn one compromised admin path into immediate production impact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-1 | This question is about governance and where configuration authority resides. |
| NIST Zero Trust (SP 800-207) | SC-3 | Mirror mode aligns with separating control authority from the runtime environment. |
| NIS2 | Centralized change control supports accountability and operational resilience expectations. | |
| OWASP Non-Human Identity Top 10 | Gateway automation often relies on non-human identities that can alter configuration. |
Scope service credentials narrowly so automation can reconcile config without gaining broad admin power.
Related resources from NHI Mgmt Group
- What is the difference between an API gateway and a unified control plane?
- What is the difference between a self-hosted AI gateway and a broader enterprise AI control plane?
- What is the difference between a narrow MCP gateway and a broader AI control plane?
- What is the difference between direct agent-tool connections and using an MCP gateway as the control plane?
