Field Notes · Security Architecture August 21, 2026 · 7 min read

Cloud security architecture is an identity problem before it is a network problem.

Teams arrive in cloud with network instincts: segment it, restrict the ingress, put the sensitive things somewhere private. Those controls still matter, and they govern the data plane. The control plane is a different system. It is an authenticated API, reachable from anywhere, that decides what exists and what the network rules are. An identity with sufficient policy acts on that API regardless of network position, which is why identity has to be reviewed first.

Two planes, two different governing mechanisms

The distinction is worth stating precisely because most confusion follows from collapsing it. The data plane is traffic to and between workloads: requests hitting an application, a service reaching a database, egress to the internet. It is governed by network constructs such as security groups, network ACLs, private endpoints, and firewall policy, and network thinking transfers to it reasonably well.

The control plane is the provider's management API: the interface that creates and destroys resources, attaches storage, reads secrets, changes policy, and rewrites the network rules themselves. It authenticates a principal and authorizes the requested action against policy. Network location is not part of that decision unless someone has deliberately made it one through conditional access or policy conditions, and in most environments nobody has.

The consequence is direct. Control-plane authority is a superset of data-plane controls, because it includes the ability to modify them. An environment can hold an immaculate network design and a role that can rewrite it, and the network design is then a statement of current configuration rather than a constraint. This is the sense in which identity is the real control plane, and it is why architecture review that begins with a network diagram begins in the wrong place.

Where cloud identity actually gets difficult

Saying identity matters is easy. The specific mechanisms that make it hard to reason about are more useful:

• Transitive trust through role assumption. Cloud identity systems allow one principal to assume another role, and chains form. The effective authority of a principal is the transitive closure of what it can reach through assumption, not what is written in the policy attached to it. Reviews that read individual policies systematically understate reach, because the interesting permission is usually two hops away.
• Workload identity. Compute resources carry identities of their own: instance profiles and roles in AWS, managed identities in Azure. A workload that is compromised does not need stolen user credentials, because it already holds cloud permissions and can request tokens for them. This makes application-level compromise a cloud-permission question, and it means the answer to "what could this container reach" is a policy question rather than a network question.
• Human access paths that bypass the reviewed ones. Break-glass accounts, provider support access, federated roles from an identity provider whose own security posture is a separate system, and long-lived access keys that predate the current standard. The reviewed path is rarely the only path.
• Policy that is permissive in ways nobody reads. Wildcards in actions or resources, permissions that allow modifying policy itself, and trust policies that accept a broader set of principals than intended. These are legible individually and difficult to reason about in aggregate, which is why the transitive question has to be asked directly rather than inferred.

The pipeline is inside the production boundary

A related boundary is drawn wrong more often than it is drawn at all. If a CI/CD pipeline can deploy to production, then the pipeline holds production authority, and everything that can influence the pipeline is inside the production trust boundary. That includes the repository, anyone who can approve or merge a change, the runner and its host, the third-party actions or plugins the workflow pulls in, and any credential the workflow can read.

Organizations routinely apply strict change control to production systems and comparatively relaxed control to the system that changes production. The reasoning is understandable, since the pipeline feels like developer tooling. It is more accurate to treat deployment authority as the sensitive asset it is, and to ask who can cause a deployment, what approves it, and what evidence exists afterward about what was deployed and by whom.

Declared state and deployed state are different objects

Infrastructure as code improves control genuinely: it makes configuration reviewable, versioned, and repeatable. It improves control over the deployed environment only to the extent that the deployed state is verified against the declared state.

Drift arrives through ordinary operations. An incident is resolved by a console change nobody codifies. An automation outside the pipeline adjusts a rule. A resource is created directly because the pipeline was slow that day. After a few quarters the repository describes intent accurately and the environment accurately describes itself, and the two have diverged in ways that only a comparison would reveal. A review that reads the Terraform and stops has examined a document, not a system. This is the same distinction that governs evidence generally: what a system demonstrates and what a record asserts are two different claims, and only one of them survives contact with an incident.

Kubernetes concentrates the same questions

Container platforms compress all of the above into one system, and the useful review questions are correspondingly specific. Start with which control plane you actually operate: a managed service moves responsibility for the API server and etcd to the provider and leaves you the authorization model, the workloads, and the node configuration, while a self-managed cluster leaves all of it with you. The security conversation differs substantially between the two, and teams frequently discuss the wrong one.

Within the cluster, authorization runs through RBAC bindings attached to users and service accounts. Two properties matter for review. Namespaces scope names and RBAC rules, and they are not by themselves a hard isolation boundary; treating them as multi-tenant separation without network policy, admission control, and workload-level controls assumes a property that has not been configured. And cluster-wide bindings, particularly anything approaching cluster-admin, tend to accumulate for operational reasons and are rarely revisited.

The bridge back to cloud identity is the part most often missed. A pod's access to the provider's control plane is determined by how workload identity is wired: through mechanisms that bind a Kubernetes service account to a cloud role, or, in less careful configurations, by inheriting the permissions attached to the node itself. In the second case every workload on the node shares the node's cloud authority, and a container boundary is doing work it was not designed to do.

Questions before approving a cloud architecture

1. Which identities can modify the environment, including modifying the network controls and the policies themselves, and what is their transitive reach through role assumption?
2. What identity does each workload carry, and what does that identity reach if the workload is compromised?
3. Who or what can cause a production deployment, and what governs that path?
4. How do we know the deployed state matches the declared state, and when was that last verified rather than assumed?
5. Are control-plane audit logs enabled, centralized, and retained long enough to reconstruct a compromise discovered months later? This is a retention decision made now that bounds a future investigation, which is the argument in Evidence Gaps Are Findings.
6. Which of our controls would still function if a single privileged identity were misused, and which would simply be reconfigured?

The strongest objection

A capable platform engineer will object that network controls remain essential in cloud: they limit blast radius, constrain egress, keep data stores off public networks, and provide defense in depth when identity controls fail. That is correct, and the thesis is about ordering rather than exclusivity. Network design does real work, and an environment with strong identity governance and a flat, openly reachable data plane is not well architected.

The claim is narrower: because control-plane authority can rewrite network controls, identity is the higher-order question, and a review that spends its effort on segmentation while leaving role chains unexamined has optimized the layer that the other layer governs. Zero-trust guidance formalizes the same ordering by treating each request as something to be authenticated and authorized on its own terms rather than trusted because of where it came from.

One boundary condition worth naming: in lift-and-shift estates where workloads run largely as they did in the data center and cloud-native services are thin, network controls carry proportionally more of the outcome and this argument applies with less force. The more an environment uses managed services, the more the control plane is the environment.

What good looks like

Observable characteristics in an environment reasoning this way: someone can produce, on request, the list of identities that can modify policy, and it is short. Workload identities are scoped per workload rather than inherited from nodes or shared across an account. Deployment authority is treated as production access and governed accordingly. Drift is detected by a job rather than by an incident. Control-plane logs are centralized with retention chosen deliberately against plausible dwell time. And the architecture diagram people actually review has identities and trust relationships on it, not only subnets.

Conclusion

In cloud environments the management API is the system that decides what the network is, so the question of who can call it precedes the question of what the topology looks like. The difficult parts are specific and reviewable: transitive reach through role assumption, the permissions carried by workloads, the deployment path that holds production authority, the gap between declared and deployed state, and the cluster authorization model where containers are involved. An architecture review that answers those before it reaches the network diagram is examining the layer that governs the others.

Related: A Control Is Worth What It Changes About the Outcome, on evaluating whether any of these controls change what is actually reachable.

← All Field Notes