Most cloud security conversations start with tools.
Which scanner are you using?
Which CNAPP platform did you buy?
Which dashboard shows your risk score?
After working with multiple startups and engineering teams, I’ve learned that these questions are almost irrelevant. Organizations rarely fail at cloud security because they chose the wrong tool. They fail because they never designed a security model in the first place.
What usually exists is a collection of disconnected controls: some IAM rules here, a firewall policy there, a few pipeline checks, and a compliance spreadsheet maintained by someone who doesn’t even touch the platform. Everyone assumes security is “handled,” but no one can explain how all of it fits together.
Security, in cloud environments, is not a feature. It is a system.
That realization is what led me to define what I call the 6-Layer Cloud Security Model — a mental model for designing cloud security as an architecture, not as a checklist.
Traditional security models came from a world of physical infrastructure. You had networks, offices, users, and servers that barely changed. The perimeter was real, and once you crossed it, everything inside was implicitly trusted.
Cloud platforms break all of that.
Identities are temporary. Infrastructure is created and destroyed continuously. Networks are software constructs. Workloads move, scale, and disappear. Even administrators rarely touch servers directly anymore.
In this world, security cannot be something you “add later.” It has to be embedded into the platform itself, just like reliability and scalability.
A layered model forces you to think in terms of trust domains. Instead of asking “are we secure?”, you start asking much more precise questions: where does trust start, where does it end, and how is it enforced?
The first layer is identity, and it is the most critical one.
In modern cloud platforms, there is no meaningful boundary between internal and external systems. Everything is accessed through APIs, and every API call is authenticated using some form of identity.
If an attacker compromises identity, they don’t need to exploit software vulnerabilities. They simply become a legitimate actor inside your system.
This is why so many real-world breaches start with something embarrassingly simple: leaked credentials, over-permissioned service accounts, or long-lived access keys that no one remembers creating.
Identity is not just about users. It includes every workload, every pipeline, every automated process. The question is not “do we use IAM?”, but whether identity is treated as a first-class architectural component of the platform.
For a practical breakdown of how secrets are managed across GKE workloads, see 4 Ways to Inject GCP Secrets into GKE.
In cloud, networks are no longer cables and switches. They are code.
This means network security is not really about blocking traffic; it is about designing safe connectivity by default. The network defines which systems are allowed to see each other, which ones are isolated, and how failure propagates.
Poorly designed cloud networks tend to look flat. Everything can talk to everything else, often because “it was easier” or because no one wanted to debug connectivity issues.
Well-designed networks enforce structure. They limit blast radius. They make lateral movement difficult. They encode architectural intent into routing and firewall policies.
The network layer is not a wall. It is a contract.
Workloads are where applications actually run, and they are often treated as the “main security problem.” In reality, they are only dangerous when other layers fail.
Most vulnerabilities inside workloads become catastrophic only if identities are over-permissioned, networks are flat, and data access is uncontrolled.
A secure platform assumes that workloads are always potentially compromised. They must authenticate explicitly, operate under strict policies, and be continuously validated.
Trusting workloads is one of the most common architectural mistakes in cloud security.
Organizations often spend millions securing infrastructure while exposing the very thing attackers actually want: data.
The data layer is about information flow, not storage systems. It is about who can read what, how data moves between environments, and how sensitive information is protected over its entire lifecycle.
Data security failures rarely come from sophisticated attacks. They come from shared analytics projects, open storage buckets, unrestricted exports, and forgotten backups.
If you cannot explain where your sensitive data lives, who can access it, and how it is audited, everything else is cosmetic.
The most overlooked layer in cloud security is the control plane.
This is where infrastructure is created, pipelines deploy code, and administrators operate the platform. If someone compromises this layer, they don’t need to attack production systems at all. They can redefine them.
Most attackers don’t “hack servers” anymore. They manipulate automation.
Control plane security is about securing the system that builds the system. It is about protecting the tools that shape reality.
Without governance, every other layer slowly decays.
Governance is what turns technical controls into a living system. It defines ownership, accountability, measurement, and evidence. It is the layer that allows organizations to answer questions like:
Are we actually improving?
Can we prove our security posture?
Do we know where our risks are?
Without governance, security exists only in people’s heads and slide decks.
The purpose of the 6-Layer Model is not documentation. It is clarity.
It allows engineering teams to design platforms deliberately. It allows leaders to reason about risk structurally. It allows security to become part of architecture instead of an afterthought.
The biggest lesson I’ve learned is simple:
Security fails not because teams ignore best practices, but because they never agreed on a system in the first place.
This is the foundation of how I approach every GCP engagement through the SCALE Framework — embedding security as an architectural property, not an afterthought.
Once you adopt layered thinking, security stops being reactive. It becomes an inherent property of how your platform is built.
And that is the only kind of security that actually scales.
