☁️ Cloud with Tanweer — Future of Cloud Series • Episode #5

2:17 PM — The First Alert

Imagine you're on the security team of a company running a customer-facing payment application on Kubernetes.

At 2:17 PM, monitoring detects something unusual.

A production pod called:

payment-api

is making outbound requests it has never made before.

The SOC begins investigating.

They discover that the application process inside the container has been compromised.

Bad.

But initially, it still looks contained.

One application.

One container.

One pod.

Then the investigation goes deeper.

The pod has a Kubernetes ServiceAccount.

That ServiceAccount has broader RBAC permissions than the application actually needs.

The workload also has a cloud identity.

That identity can access production cloud resources.

The pod can communicate with internal services it has no business talking to.

And it can access application secrets.

What looked like:

Vulnerable Application
        ↓
Compromised Pod

has suddenly become:

Application
     ↓
Container
     ↓
Kubernetes
     ↓
Identity
     ↓
Cloud
     ↓
Data

The most important question is no longer:

How did they compromise the container?

It is:

How far can they go from here?

Note: This is a fictional incident reconstruction based on realistic Kubernetes and cloud-security failure modes. It does not describe a breach of any specific organization.

The Container Wasn't the Security Boundary

Container scanning is important.

But a production Kubernetes workload sits inside a much larger trust system.

                    CLOUD
                      ↑
                  Cloud IAM
                      ↑
              Workload Identity
                      ↑
                      │
              COMPROMISED POD
             /        │        \
            ↓         ↓         ↓
          RBAC      Secrets   Network
            ↓         ↓         ↓
       K8s API    Credentials Services

So instead of asking only:

"Is this container secure?"

architects should also ask:

"If this container is compromised, what identities, permissions, secrets, services and data become reachable?"

That's blast-radius thinking.

Attack Path #1 — Kubernetes RBAC

Our compromised payment-api uses a Kubernetes ServiceAccount.

Maybe the application only needs to read a ConfigMap inside the payments namespace.

But during development, someone gave it broader permissions to make deployment easier.

Now:

Compromised Pod
       ↓
ServiceAccount
       ↓
Broad RBAC
       ↓
Kubernetes API
       ↓
Other Resources

The application vulnerability created the foothold.

RBAC determines what the attacker may be able to do with it.

This is why namespace-scoped permissions and least privilege matter.

If a workload needs:

Read ConfigMap
      ↓
payments namespace

why give it cluster-wide permissions?

Convenience during deployment can quietly become blast radius during an incident.

Attack Path #2 — Secrets

Next, investigators check what Secrets the workload can access.

Imagine the compromised identity can retrieve:

DATABASE_PASSWORD

INTERNAL_API_TOKEN

PAYMENT_GATEWAY_KEY

Now the attack path changes again.

Compromised Pod
       ↓
Secret Access
       ↓
Credentials
       ↓
Another System
       ↓
Sensitive Data

The attacker didn't need to compromise the second system directly.

The first compromised workload gave them another identity.

That's why secret access deserves the same scrutiny as application vulnerabilities.

And where possible, workloads should use identity-based authentication rather than carrying unnecessary long-lived credentials.

Attack Path #3 — The Network Is Too Open

Now the attacker begins exploring internal services.

Suppose payment-api genuinely needs to communicate with only:

Payment Database
Payment Gateway

But it can also reach:

Admin API
Reporting Service
Inventory API
Internal Database
Other Workloads

Why?

Because east-west network access was never tightly restricted.

Weak model:

Payment Pod
     ↓
Anything Reachable

A better model:

                 ┌──→ Payment Database
Payment API ─────┤
                 └──→ Payment Gateway

Payment API ──X──→ Admin API
Payment API ──X──→ Unrelated Database
Payment API ──X──→ Sensitive Workloads

Controls such as Kubernetes NetworkPolicy can help create these boundaries where supported by the environment.

Network segmentation doesn't stop every compromise.

It helps stop:

one compromise from becoming everyone's compromise.

Attack Path #4 — Kubernetes Meets Cloud IAM

This is where Kubernetes security becomes cloud security.

Our payment application needs access to one cloud resource.

On AWS, for example, the intended requirement might be:

payment-api
     ↓
Read configuration
     ↓
Specific S3 location

But imagine its cloud role contains:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

The application works.

Nobody notices anything wrong.

Until the workload is compromised.

Compare it with:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject"
  ],
  "Resource": [
    "arn:aws:s3:::payment-config/prod/*"
  ]
}

The application may work exactly the same way.

But the attacker's potential access is completely different.

Least privilege isn't just an IAM best practice.

It's blast-radius engineering.

Workload Identity Changes the Game

Modern managed Kubernetes platforms allow workloads to access cloud services using workload identities instead of embedding permanent cloud credentials.

Conceptually:

AWS EKS

Pod
 ↓
ServiceAccount
 ↓
EKS Pod Identity / IRSA
 ↓
IAM Role
 ↓
AWS Resource

Azure AKS

Pod
 ↓
ServiceAccount
 ↓
Microsoft Entra Workload Identity
 ↓
Azure Identity
 ↓
Azure Resource

Google GKE

Pod
 ↓
ServiceAccount
 ↓
Workload Identity Federation
 ↓
Cloud IAM
 ↓
GCP Resource

Different platforms.

Same architectural principle:

Give the workload an identity instead of giving it a permanent credential.

But workload identity alone isn't enough.

That identity must still follow least privilege.

A temporary credential with excessive permissions is still excessive permission.

Now Look at the Complete Attack Path

Our investigation started with one vulnerable application.

But this is what the architecture allowed:

                    Internet
                       ↓
             Application Vulnerability
                       ↓
                COMPROMISED POD
                       │
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
     RBAC           Secrets          Network
       ↓               ↓               ↓
  K8s Resources    Credentials   Internal Services
       │               │               │
       └───────────────┼───────────────┘
                       ↓
               Workload Identity
                       ↓
                   Cloud IAM
                       ↓
              Production Resources
                       ↓
                     Data

This is the real problem.

The application vulnerability opened the door.

The architecture decided how many rooms the attacker could enter.

How I Would Redesign It

Now let's assume something important:

The application may eventually be compromised.

That assumption changes the architecture.

Instead of:

Compromised Pod
      ↓
Broad RBAC
      ↓
Accessible Secrets
      ↓
Flat Network
      ↓
Broad Cloud IAM
      ↓
Large Blast Radius

design for:

                   Application
                        ↓
                  Restricted Pod
                        ↓
        ┌───────────────┼───────────────┐
        ↓               ↓               ↓
   Minimal RBAC    Limited Secrets   NetworkPolicy
        │               │               │
        └───────────────┼───────────────┘
                        ↓
              Dedicated Workload
                   Identity
                        ↓
              Least-Privilege IAM
                        ↓
             Approved Cloud Resource

                        +

                Runtime Monitoring
                        ↓
                Security Alert
                        ↓
               Incident Response

Now imagine the application is compromised again.

The attacker discovers:

No broad Kubernetes access

No unrelated Secrets

No unrestricted east-west access

No broad cloud permissions

Suspicious behaviour is monitored

The incident still matters.

But:

Compromise ≠ Total Access

That's what good security architecture should achieve.

Why Vulnerability Counts Don't Tell the Whole Story

Imagine your security platform reports:

4,382 vulnerabilities

Which one should the engineering team fix first?

Consider these two workloads.

Workload A

Critical CVE
No internet exposure
Minimal permissions
Restricted network
No sensitive data

Workload B

Critical CVE
Internet exposed
Broad RBAC
Sensitive Secret access
Powerful cloud identity
Production data access

Same severity?

Maybe.

Same risk?

Absolutely not.

This is where context matters.

Instead of saying:

"This container has a critical vulnerability."

a more useful security story is:

"This internet-facing production workload has an exploitable vulnerability, broad Kubernetes permissions, access to sensitive credentials and a cloud identity capable of reaching production data."

Now the priority becomes much clearer.

This is also why attack-path context has become increasingly important in modern cloud-security and CNAPP approaches.

The Architecture Review Question I Would Ask

Forget a 50-item checklist for a moment.

Before approving an important Kubernetes workload, ask:

Assume this pod is compromised right now. Show me what the attacker can reach.

Then answer these five questions:

1. What Kubernetes permissions does it have?

Check the ServiceAccount and RBAC.

2. What secrets can it access?

And what systems do those credentials unlock?

3. What workloads can it communicate with?

Is east-west traffic actually constrained?

4. What cloud identity does it receive?

And exactly what can that identity do?

5. Would we detect abnormal behaviour?

What happens if the workload suddenly behaves differently?

If your architecture team can answer those five questions clearly, you're already thinking beyond container security.

Kubernetes Security Isn't Only a Kubernetes Problem

Look at the path again:

Code
 ↓
Container
 ↓
Kubernetes
 ↓
Identity
 ↓
Network
 ↓
Cloud
 ↓
Data

Which team owns this?

Developers?

DevOps?

Platform Engineering?

Cloud?

Security?

SOC?

In reality:

all of them.

Team	Security Responsibility
Developers	Application and dependency security
DevOps	CI/CD and deployment controls
Platform Engineering	Kubernetes guardrails
Cloud Engineering	IAM, networking and cloud services
Security Engineering	Architecture and policy
SOC	Detection and incident response
Architects	Trust boundaries and blast radius

Attack paths don't respect organizational boundaries.

Our security architecture shouldn't either.

The Bigger Lesson

Cloud security often focuses on:

How do we stop attackers from getting in?

We absolutely should.

But architects need to ask another question:

What happens when one security control eventually fails?

Because eventually:

A dependency may become vulnerable.

A configuration mistake may happen.

A credential may leak.

A workload may be compromised.

A security tool may miss something.

Good architecture assumes individual controls can fail.

And then makes sure:

One failure doesn't become total compromise.

Final Thought

Our fictional incident started with:

payment-api

One application.

One pod.

But the potential blast radius was determined by everything connected to it:

RBAC.

Secrets.

Network access.

Workload identity.

Cloud IAM.

Data.

That's why the Kubernetes security question I would ask isn't:

"Is my container secure?"

I'd ask:

"If this container is compromised, how far can the attacker go?"

If you can answer that confidently, you're thinking like an architect.

If you can't...

that's probably where your next security review should begin.

Your Turn

At 2:17 PM, you're told a production Kubernetes pod has been compromised.

You can investigate one area first:

RBAC

Cloud IAM

Secrets

Network

Runtime activity

Which one do you check first — and why?

My starting point would be:

Identity and permissions.

Because before deciding how serious the incident is, I want to understand its potential blast radius.

I'd be interested to hear how other Cloud, Kubernetes, Platform, DevOps and Security engineers would approach it.

☁️ Future of Cloud Series

Episode #1

🤖 AI is Writing Cloud Infrastructure — Are We Creating the Next Security Crisis?

Episode #2

⚙️ Why Every Cloud Engineer Should Learn Terraform in 2026

Episode #3

🌐 Is Multi-Cloud the Future or Just an Expensive Trend?

Episode #4

🔐 10 AWS IAM Mistakes That Still Put Cloud Environments at Risk

Episode #5

☸️ The Pod Was Compromised. Why Did the Attacker Reach the Cloud?

References & Further Reading

Kubernetes Documentation — RBAC Good Practices
Kubernetes Documentation — Network Policies
Kubernetes Documentation — Pod Security Standards
Amazon EKS — Security Best Practices
Amazon EKS — Pod Identity / IRSA
Microsoft Azure — AKS Workload Identity
Google Cloud — GKE Security Best Practices
Google Cloud — Workload Identity Federation for GKE

Disclaimer: The incident described in this article is a fictional scenario created to explain realistic Kubernetes and cloud-security architecture risks. It does not describe a breach of any specific organization. Security controls should be selected according to workload, platform, regulatory and organizational requirements.

Cloud with Tanweer

Practical perspectives on Cloud Architecture, Cloud Security, Multi-Cloud, AI, DevSecOps and the technologies shaping modern infrastructure.

Command Palette