Control Plane vs Data Plane: separating management from traffic to limit compromise

Most serious cloud and platform compromises come down to one question: did the attacker get hold of the plane that changes things, or only the plane that carries things? The control plane is where resources, policies, identities and routes are created and changed; the data plane is where the workload actually serves traffic, stores objects and answers queries. The two have different threat models, different credentials and different logs, and many programmes protect one well while leaving the other almost unwatched. This guide applies the split across cloud providers, Kubernetes, service meshes, SaaS, AI gateways and identity providers, then gives a design approach, metrics and a worked scenario. It is for cloud architects, platform engineers and detection teams. Platforms are listed alphabetically and the order is not a ranking.

Key takeaways

• The control plane changes the system; the data plane is the system doing its job. AWS describes control planes as the APIs that create, read, update, delete and list resources, and the data plane as what provides the primary function of the service.
• Control plane compromise is about blast radius. One administrative credential can create new identities, rewrite policy, disable logging or reach every data store through grants it gives itself.
• Data plane access often bypasses control plane guardrails. Microsoft states that a lock preventing a database being deleted does not prevent data being deleted through queries, and that management features might not apply to data plane operations.
• Default logging favours the control plane. Google Cloud Admin Activity logs are always written while Data Access logs are off by default except for BigQuery; AWS CloudTrail does not log data events by default.
• Separate the credentials, not just the networks. Different identities, roles and keys per plane, with key-based data access minimised, are what turn the architectural split into a security boundary.

The short answer

Treat the control plane as your crown jewels for integrity and the data plane as your crown jewels for confidentiality. The control plane needs the strongest authentication, the fewest standing grants, a narrow network path and tamper-resistant logs, because whoever holds it can rewrite every other control. The data plane needs strong per-workload identity, encryption, egress control and data access logging, because that is where records actually leave. Hardening console access while storage runs on long-lived keys is only half the job.

Side by side

Threat model per plane

Control plane

The attacker's goal on the control plane is leverage. With administrative rights they can grant themselves data access, create persistence through new users, roles or federated trusts (ATT&CK T1098 Account Manipulation), turn off or redirect logging, delete recovery points and change network rules. Entry is usually through valid cloud accounts (T1078.004 Cloud Accounts): a phished administrator, a leaked pipeline secret, or a role reached by chaining from a workload. Control plane traffic is low volume, so every call must be attributed to a named identity.

Control plane compromise also includes the planes that issue identity. The Microsoft Storm-0558 key breach is a control plane failure in identity terms: a stale signing key that should have been retired let the attacker mint tokens, so every data plane that trusted those tokens was open.

Data plane

The attacker's goal on the data plane is the data itself: Data from Cloud Storage (T1530), database dumps, model prompts and outputs, message queues. Entry is through credentials the data plane accepts directly (storage keys, database passwords, API keys, session tokens) or a compromised workload. The Snowflake breach shows the pattern: no platform flaw, just customer accounts accepting stolen passwords without MFA or network allow lists, so data walked out through the normal data plane interface.

Crossing between planes

The most damaging chains cross the boundary. A workload on the data plane reaches the instance metadata service (T1552.005 Cloud Instance Metadata API) and obtains a role with control plane permissions. A management interface exposed on the data plane network lets anyone reach the control plane. In the Tesla Kubernetes cryptojacking case an administration console without password protection gave attackers a foothold, and AWS credentials found in a pod then opened an S3 bucket.

Cloud providers: how the split is drawn

Two consequences follow from Microsoft's own description. First, data plane access can carry on when the control plane is unavailable, which is good for resilience and means control plane revocation is not always instant data plane revocation. Second, data plane operations may need other credentials, such as a database login or a VM session, that never pass through Resource Manager and so never meet its RBAC, policy or locks. Key Vault is a clear example: Microsoft separates the control plane for managing the vault from the data plane for keys, secrets and certificates, recommends Azure RBAC, and advises against legacy access policies, which do not support Privileged Identity Management. Under the access policy model a principal that can write the vault's policies can grant itself secret access, which is why moving to RBAC matters. See the Azure Key Vault Security Guide and the AWS CloudTrail Guide.

Kubernetes and service meshes

Kubernetes documents its control plane as kube-apiserver, etcd, kube-scheduler, kube-controller-manager and the optional cloud-controller-manager, with kubelet, kube-proxy and the container runtime running on every node. The API server is the single front door to the control plane (by default on TCP 6443), and etcd holds all cluster state, including Secrets unless encryption at rest is configured. The kubelet API on each node (TCP 10250) is a control path into the data plane and must require authentication and authorisation.

• Control plane threats: anonymous or overly broad API access, cluster-admin bound to service accounts, exposed dashboards, direct etcd access and Container Administration Command (T1609) through exec into pods. See the Kubernetes RBAC Guide.
• Data plane threats: compromised containers, pod-to-pod lateral movement without network policies, service account tokens mounted where they are not needed, and node credentials reaching the cloud metadata service.
• Managed clusters: on Amazon EKS the provider runs the API servers and etcd inside an EKS-managed VPC, and the customer chooses whether the API endpoint is public, private or both. Managed services move control plane operations to the provider, but RBAC bindings, endpoint exposure and audit log export remain customer settings.
• Service mesh: Istio describes its data plane as Envoy proxies deployed alongside workloads and its control plane as the component that configures them; istiod also acts as the certificate authority for mTLS. Whoever controls istiod can issue workload identities and rewrite routing, so it belongs in the control plane tier. See the Service Mesh Security Guide.

See the Kubernetes Security Guide for hardening. RBAC, admission control and API audit logging are control plane controls, while network policies, runtime detection and workload identity are data plane controls, and both sets need owners.

SaaS, data platforms and identity providers

SaaS products have the same split, even when the vendor does not name it. The admin console and admin APIs (tenant settings, SSO configuration, OAuth app approvals, API token issuance) form the control plane; user sessions, file access and API calls that read records form the data plane. Hybrid data platforms make the split physical. Databricks, for example, documents a control plane of backend services in the Databricks account and a classic compute plane that runs in the customer's AWS account, alongside a serverless compute plane that runs in the Databricks account. For hybrid deployments, ask which vendor identities can direct compute in your account and which credentials that compute uses to reach your storage.

Identity providers are the control plane for every other control plane. An IdP super administrator can change federation trust, MFA policy and app assignments for the whole estate. That is why recovery and emergency accounts deserve their own treatment: see the Protecting Cloud Control-Plane Recovery Accounts and Credentials guide and the Break-Glass Account Guide.

AI gateways and model platforms

AI services split cleanly. The control plane covers model deployments, content filter settings, quotas, routing rules, provider keys and logging configuration. The data plane is inference: prompts in, completions out, tool calls and retrieval. Microsoft's Azure OpenAI roles illustrate the separation: Cognitive Services OpenAI User can make inference calls with Microsoft Entra ID but cannot view keys, while Cognitive Services Contributor can view and regenerate keys but cannot make inference calls with Entra ID. Microsoft also warns that using API keys bypasses Azure RBAC.

An AI gateway adds its own pair of planes. Its admin API, virtual key issuance and upstream provider keys are a control plane that concentrates every team's model access; its proxy path is a data plane that sees every prompt. Separate gateway administration from inference traffic, keep upstream keys in a secrets manager, and decide prompt logging by data classification. See the AI Gateway and LLM Gateway Guide and Securing the AI gateway itself.

Credentials and logging per plane

The architectural split becomes a security boundary only when each plane has its own identities and its own evidence.

Ship control plane logs to a security-owned account that workload administrators cannot modify. See the Workload Identity Federation Guide for removing static keys from pipelines.

Decision criteria

• Where to spend first: if more than a handful of humans hold standing administrative roles, start with the control plane. If administrative access is already tight but workloads use long-lived keys, start with the data plane.
• Logging budget: keep control plane logs always on and retained longest. Enable data plane logs selectively by data classification: regulated and crown-jewel stores first, high-volume low-value paths sampled or summarised.
• Network separation: large organisations should reach management interfaces only from privileged access workstations or a management network; small organisations get most of the value from phishing-resistant MFA, conditional access and private API endpoints.
• Managed versus self-run: a managed control plane shifts patching and availability to the provider but leaves access configuration, endpoint exposure and log export with you.
• Keys versus identity on the data plane: prefer identity-based data access wherever the service supports it, because keys bypass role models and are hard to attribute. Keep keys only for clients that cannot use identity, and scope, rotate and monitor them.

Worked scenario: a retailer's AI order assistant

A retailer runs an order assistant on managed Kubernetes. It calls a hosted model through an internal AI gateway and reads order history from a cloud database. During design review the team maps each component to a plane.

1. Control plane inventory: cloud subscription Owner and Contributor assignments, the cluster API endpoint, the gateway admin API and the database server's management settings. Fourteen humans hold standing Owner; the cluster endpoint is public; the gateway admin API listens on the same ingress as inference.
2. Data plane inventory: the assistant pods, the gateway proxy, the model inference endpoint and the database listener. The pods read the database with a static password in a Kubernetes Secret and call the gateway with a shared key.
3. Changes: Owner reduced to two break-glass accounts plus just-in-time elevation; the cluster endpoint made private and reachable from privileged access workstations; the gateway admin API moved to a separate internal listener with its own identity provider group; pods given a workload identity with read-only access to the orders schema; the gateway issues a per-application virtual key; database key-based local authentication turned off.
4. Logging: control plane logs exported to a security-owned account; database data access logs enabled for the orders schema; gateway logs record request metadata and policy decisions but store prompt text only for flagged requests.
5. Test: a simulated pod compromise can read orders (expected) but cannot list cluster Secrets, reach the gateway admin API or obtain a management role from the metadata service.

Implementation path

1. Map: for each platform, list control plane interfaces, data plane endpoints, and every identity that can reach each. Mark identities that can reach both.
2. Log first: turn on and centralise control plane audit logs everywhere, then enable data plane logs for the most sensitive stores. Run detections in alert-only mode for two weeks to baseline.
3. Cut standing control plane access: move humans to just-in-time elevation, pipelines to federated workload identity, and remove static admin keys. Keep two tested break-glass accounts.
4. Narrow the path: make management endpoints private or restricted by source, and separate gateway, mesh and database admin listeners from serving traffic.
5. Move the data plane to identity: replace storage keys, database passwords and shared API keys with workload identities scoped to named resources; disable key authentication service by service after confirming no client still uses it.
6. Roll back safely: stage each change in a non-production environment, keep the previous key or role available but monitored for a defined window, and remove it only when logs show zero use.

Detection and measurement

• Control plane signals: new role assignments at subscription, project or organisation scope; new federated trusts or identity provider changes; logging, trail or diagnostic setting changes; cluster-admin bindings; gateway key creation.
• Data plane signals: unusual read volume from a single identity; data access from identities with no prior history; key-based access where identity is expected; workload calls to the metadata service followed by management API calls.
• Metric: number of humans with standing control plane administrative roles (target: break-glass only).
• Metric: percentage of sensitive data stores with data plane access logging enabled and centralised.
• Metric: percentage of data plane access using identity rather than keys, per service.
• Metric: number of workload identities holding any control plane permission (target: deployment pipelines only).
• Metric: management endpoints reachable from the internet (target: zero, or source-restricted with exceptions recorded).

Framework mapping

Common failure patterns

• Locks mistaken for data protection: resource locks and deletion policies protect the resource, not its contents. Data deleted or exfiltrated through the data plane is untouched by them.
• Data plane logging never enabled: investigators find management events but no record of which objects or rows were read, so breach scope cannot be bounded and notification decisions default to worst case.
• Keys that bypass the role model: storage keys, database passwords and AI service API keys remain enabled after identity-based access is introduced, so the cleanest RBAC design still has a side door.
• Management interfaces on the serving network: dashboards, kubelet APIs, gateway admin endpoints and mesh control planes reachable from workload networks, as in the Tesla case above.
• Identity plane treated as just another app: IdP administrators and signing keys governed less strictly than cloud Owners, even though they can mint access to every plane.

Practitioner checklist

• Inventory control plane interfaces and data plane endpoints for every cloud, cluster, SaaS tenant, gateway and IdP.
• Reduce standing control plane administrators to break-glass accounts plus just-in-time elevation.
• Make management endpoints private or source-restricted and separate admin listeners from serving traffic.
• Enable and centralise control plane audit logs in a security-owned account or tenant.
• Enable data plane access logs for regulated and crown-jewel stores.
• Replace data plane keys with workload identities and disable key authentication where the service allows.
• Remove control plane permissions from workload identities and block metadata service paths to management roles.
• Alert on logging changes, new high-scope role assignments and new federated trusts.
• Test plane separation by simulating a compromised workload and confirming it cannot reach the control plane.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• AWS: Control planes and data planes (AWS Fault Isolation Boundaries)
• Microsoft Learn: Azure control plane and data plane
• Google Cloud: Cloud Audit Logs overview
• AWS: Logging data events with CloudTrail
• Kubernetes: Kubernetes Components
• Istio: Architecture
• Microsoft Learn: Role-based access control for Azure OpenAI

Related NHI Mgmt Group resources: Network Device Management Plane Hardening Guide, NIST SP 800-207 Zero Trust Architecture Guide, Privileged Access Workstations Guide, Kubernetes Audit Log Detection Guide.