● Talk to a security engineer: +92 323 8295031info@protonyte.com  ·  PCSF batch enrolling now

Kubernetes security assessment: from one pod to the whole cluster

A container is not a security boundary, and a cluster that assumes it is will hand an attacker the node and then the cloud account underneath. We review the cluster against the CIS Kubernetes Benchmark and then take a single compromised pod and see how far it goes - through RBAC, through a mounted service account token, through the node, and out into the account that owns it.

Book a free consultation See our method
the nodethen the account one pod

ENGAGEMENT SCOPEtypical 1 - 2 week review

Cluster RBAC and service accountsIN SCOPE
Pod security and workload isolationIN SCOPE
Network policy, in practiceIN SCOPE
Secrets handling and encryption at restIN SCOPE
Node and control plane configurationIN SCOPE
Image and registry supply chainIN SCOPE
// the basics

The question is always "and then what"

Assume one workload is compromised. It will happen eventually through a dependency, an exposed application or a poisoned image, and nothing about the cluster changes that. What the cluster decides is what happens next.

In a well-built cluster the answer is very little: the pod runs unprivileged, its service account can do almost nothing, network policy stops it talking to anything it does not need, and the node credentials are not reachable. In most clusters we look at, the answer is the node, then the cloud account, then every other workload on it. That distance is the finding.

  • 01Starts from a podBecause that is where a real compromise starts, not at the API server.
  • 02RBAC read properlyIncluding the bindings inherited from Helm charts that nobody has looked at since install.
  • 03Network policy testedNot read. A policy that exists and does not apply is worse than none, because it is believed.
  • 04Managed or self-hostedEKS, AKS, GKE or your own, including the path from the cluster into the cloud account.
// coverage

What we go through

Structured on the CIS Kubernetes Benchmark and the NSA/CISA Kubernetes Hardening Guidance, with the breakout work taken further than either asks.

// permissions

RBAC

Who can do what in the cluster, and what that reaches.

  • Roles and cluster roles with wide verbs
  • Service account bindings per namespace
  • Default service account token mounting
  • Paths from a namespace to cluster-admin
// the workloads

Pod security

What a container is allowed to do to its host.

  • Privileged containers and host namespaces
  • Capabilities, seccomp and AppArmor
  • Host path mounts and docker socket exposure
  • Pod Security admission enforcement
// the wire

Network policy

Tested from inside a pod, not read from a manifest.

  • Default-deny presence by namespace
  • Pod-to-pod reachability in practice
  • Egress to the internet and to metadata
  • Service mesh policy, where used
// the secrets

Secrets and identity

What credentials a compromised workload can read.

  • Secrets in environment variables and manifests
  • Encryption at rest for etcd
  • Cloud identity bound to workloads
  • External secret store integration
// the breakout

Node and account

The path most clusters do not close.

  • Container to node escape routes
  • Node instance credentials from a pod
  • Metadata service reachability
  • Cluster to cloud account escalation
// the record

Control plane and audit

Whether any of this would be visible.

  • API server flags and anonymous auth
  • Audit policy and log destination
  • Admission controllers in use
  • Kubelet configuration and authorisation
// methodology

How the work runs

  1. 1

    Access and scope

    A read-only kubeconfig to start, plus a test namespace for the breakout work.

    • View or audit cluster role
    • Clusters and namespaces in scope
    • A namespace we may deploy into
    • Written authorisation
  2. 2

    Read the cluster

    Configuration, RBAC and workloads before anything is run.

    • Control plane and node configuration
    • Every role and binding
    • Workload manifests and security context
    • Images and where they come from
  3. 3

    Measure

    Against the benchmark, so there is a number.

    • CIS Kubernetes Benchmark controls
    • Pass, fail or not applicable, with evidence
    • Managed-cluster controls marked as such
    • False positives removed by hand
  4. 4

    Start from a pod

    The part that tells you what a compromise costs.

    • A test workload deployed with your agreement
    • What its token and network reach
    • Escape attempts against the node
    • The path onward to the cloud account
  5. 5

    Report and retest

    Fixes ordered by how much of the path they break, and a free retest.

    • Benchmark result and gap list
    • Breakout path with evidence
    • Manifests and policies you can apply
    • Retest and closure summary
// the deliverable

What you are left holding

Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.

  • Executive summary in plain language, with the business risk first
  • Technical findings with the evidence that proves each one
  • CVSS score and a risk rating that reflects your business, not a template
  • Remediation written for the stack you actually run
  • A free retest, and a closure summary you can hand to a customer
  • A debrief call with the tester who did the work, not an account manager
Ask for a sample report
// the standards

Measured against something

The work follows CIS Kubernetes Benchmark, NSA/CISA Kubernetes Hardening Guidance, MITRE ATT&CK for Containers and NIST SP 800-190, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.

This page is one part of our cloud security service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.

// faq

Common questions

Do you need to deploy anything into our cluster?

For the review, no - a read-only kubeconfig is enough. For the breakout work we ask for a namespace we may deploy a test workload into, because "what can a compromised pod reach" cannot be answered from a manifest. Everything we deploy is listed and removed.

We use a managed cluster. Is there anything left to assess?

Yes, and usually a lot. The provider secures the control plane; everything above it - RBAC, pod security, network policy, secrets, workload identity - is yours. The benchmark marks which controls the provider owns, so the report does not claim credit for things you did not configure.

Is network policy really worth testing if we have it?

Especially then. A policy that exists but does not select the pods you think it does is worse than no policy, because it is believed. We test reachability from inside a pod rather than reading the manifest.

Does this include the cloud account the cluster runs in?

The path from the cluster into the account does, because that is the most valuable thing a cluster compromise buys. A full review of the account itself is the AWS, Azure or Google Cloud assessment.

Can you review our images and pipeline too?

Image provenance, registry permissions and what the build pipeline is trusted to do are in scope. A full software supply chain review is a larger piece of work and we will scope it separately rather than imply it is included.

// also under cloud securityAWSAzureGoogle CloudAll cloud security
// further readingWhere cloud risk actually sitsA scan is not a pentestWhat a good report looks like
// start here

Let's protect your business together.

Tell us what you need tested. Our team will reply with a clear scope and quote.

✉Emailinfo@protonyte.com ☏WhatsApp+92 323 8295031
⌖OfficeKarachi, Pakistan
By submitting, you agree to our Terms of Use and Privacy Statement.