Skip to main content

Identity-Centric Security: The New Perimeter

What This Concept Is​

"The perimeter" used to mean a corporate firewall: a strong wall between "inside" and "outside". In cloud systems, that wall does not exist, or rather it exists in thousands of small pieces.

Identity-centric security replaces the wall with a rule: every request, from every caller, to every resource, must be authenticated and authorized based on identity, independent of where the request came from on the network.

This idea has a name: Zero Trust. The canonical statement lives in NIST Special Publication 800-207, which defines Zero Trust as a set of principles that move defenses from static network-based perimeters to users, assets, and resources, and that "no implicit trust" is granted based on network location or asset ownership.

In operational terms, identity-centric security means:

  • every workload has a verifiable identity (a service account, workload identity, or cert)
  • every request is checked: who is calling, for what, on what resource, under what conditions
  • network position is a signal, not a blanket permission
  • secrets, keys, and long-lived credentials are treated as identity leaks waiting to happen

Why It Matters Here​

In cloud breaches, the attacker rarely "breaks the firewall". They get a credential (leaked key, phished session, overly broad role, stolen token) and use it as that identity. From the cloud's perspective, there is no break-in -- the requests look exactly like legitimate ones.

If identity is weak, nothing else matters. You can have a perfect VPC and it does not help when the workload inside the VPC has Admin everywhere.

Concrete Example​

A deployment pipeline runs in CI and needs to push a container image, update a managed Kubernetes cluster, and read a secret from a key store. There are two ways to give it permissions.

Pre-Zero-Trust approach: mint a long-lived access key, paste it into a secret in the CI system, give it broad write access. Network controls are used as the main defense -- maybe the CI system only egresses from a handful of IPs.

Identity-centric approach:

  • CI authenticates to the cloud using federated identity (OIDC token proving "this is our GitHub repo on this workflow on this branch")
  • The cloud exchanges that for a short-lived credential scoped to exactly three actions on exactly three resources
  • Every action is audit-logged with the federated identity, not a shared role
  • No long-lived credential is ever written to disk

A concrete AWS trust policy for this flow (GitHub OIDC -> short-lived role):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::123:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:acme/orders:ref:refs/heads/main"
      }
    }
  }]
}

Three things are load-bearing in that policy: the Principal pins the specific OIDC issuer; the aud condition ensures the token was intended for AWS; the sub condition pins the specific repo and branch. Loosen any of those and the role becomes assumable by something you did not intend.

Same capability as the old shared-key flow, but the attacker surface moved from "whoever gets the shared key" to "whoever can push to that specific branch with review". That difference is the new perimeter.

Common Confusion / Misconception​

"Zero Trust means no trust." No. It is "no implicit trust based on where the packet came from". Authentication still happens, authorization still happens, and you still trust identities you have verified. The "zero" is about location-based assumptions: being inside the VPC does not grant you anything on its own.

"Identity-centric means turn off the VPC." Network controls are still valuable as defense in depth; they just stop being the primary boundary. See Concept 3 and Concept 7 -- VPC moats contain lateral movement, even in a Zero Trust world.

"Least privilege is a slogan." It is an operating discipline. A role that is "close enough to what this service needs" is the wrong role. It will be used by the attacker you have not met yet. NIST SP 800-207 lists least privilege as a core Zero Trust principle for exactly this reason.

"Workload identity is just a service account." A service account is the name. Workload identity is the full flow: attest the workload, bind it to a cryptographic identity (SPIFFE SVID, GCP workload identity, IRSA on EKS), exchange that for a short-lived token, audit every call. If any of those steps is missing, you have a shared secret with fancy packaging.

"Humans and workloads can share the same identity model." They should not. Humans need SSO, MFA, session lifetime, and device posture. Workloads need programmatic attestation and short-lived tokens. Collapsing both into one model ends with humans sharing service accounts or workloads going through a login flow.

How To Use It​

For every workload and every human identity in your system, ask:

  1. What identity is making this call? (not "what IP", not "what account")
  2. What is the minimum it needs? Down to the specific action and the specific resource. Write the IAM policy as JSON; if you cannot name actions and resources explicitly, you have not done the work.
  3. How short-lived is the credential? Minutes is good, hours is fine, days is a smell, months is a problem. For humans, prefer SSO with short session lifetimes; for workloads, prefer OIDC federation or workload identity with <= 1 hour tokens.
  4. Is there an audit record of what this identity did? If not, R (repudiation) is open. The audit log must include the federated subject (branch, pod, node), not just the assumed role.
  5. What would compromise of this identity cost? If the answer is "account-wide", the identity has too much. Tier identities by blast radius; keep the blast-radius-wide ones behind breakglass + multi-party approval.
  6. Is this identity reachable from outside intended channels? An OIDC role assumable from any GitHub repo is not scoped. A service account usable by any pod in the namespace is not scoped. Bind the identity to the smallest attestable context.

Check Yourself​

  1. What is the difference between authentication and authorization, and which one is usually over-trusted in cloud systems?
  2. Why is "inside the VPC" not a sufficient trust boundary?
  3. Give one example of a long-lived credential that should probably be a short-lived one.

Mini Drill or Application​

Pick any service in a system you know. Write down:

  • its identity (role, service account, or equivalent)
  • the three highest-risk actions its role can perform
  • whether each of those is actually used today
  • one action you would remove if you redesigned the role tomorrow

If you cannot answer these in 15 minutes, the role has too much in it.

See also (external)​

Depth Path​

Source Backbone​

Security and observability require official docs, but these books provide the systems and reliability backbone behind the practices.