Where two teams share a cluster and each has their own namespace, that separation tends to get described as isolation. The namespace does prevent one team from reading the other's config maps, but it does not prevent a pod from mounting a service account token, and it does not prevent that token from federating out to a cloud identity that can read a storage account belonging to neither team. What the workloads in the cluster can reach outside it is therefore as important as what is running inside it.
That path, from a workload through a federated identity into the cloud account, exists half in the cluster and half in the cloud account, so we assess both sides of it in the same engagement.
What we assess
- Workload identity into the cloud, covering pod, workload identity and managed identities. We then establish what each of those cloud identities is permitted to do once assumed
- RBAC, covering Role and ClusterRole aggregation, wildcard verbs, escalate, bind and impersonate, service account token automounting, long-lived tokens, and who is able to create pods where. Pod-create on a shared node pool is effectively node compromise
- Tenancy and cluster architecture, e.g. namespace and node pool design, what the tenancy claim actually is, control plane endpoint exposure, API server authentication, kubeconfig sprawl and break-glass access
- Escape paths, covering privileged pods, hostPath, hostNetwork and hostPID, capabilities, seccomp and AppArmor profiles, and whether Pod Security Admission is set to enforce or only to warn
- Admission control, covering Gatekeeper, Kyverno or native validating admission policy, whether it fails open or closed, which namespaces are exempt, who is permitted to edit the policies, and how far mutating webhooks are trusted
- Supply chain, covering image sources and registry authentication, whether signatures and provenance are verified rather than only produced, and what your pipeline is permitted to do to the cluster
- Network policy and service mesh configuration, and whether the default is deny or the default is everything
How we work
We ask for a read-only ClusterRole covering resources including RBAC and admission configuration, a read role on the cloud side for the identities the cluster federates to, and access to the infrastructure as code and GitOps repositories that produce the cluster. Where live access is not possible, an offline dump works.
We run the standard open source checks as a baseline, e.g. CIS benchmark tooling, and treat that output as a starting point. Most teams have already run those and found the results difficult to act on.
The work that follows is building the graph: every workload identity, what it federates to, and what that cloud identity is able to do.
What you get
- A cluster-to-cloud identity map, listing every service account that federates, the cloud identity it assumes, and what that identity can reach
- A findings report where each finding names the binding, manifest or module it lives in, what it enables, and the fix expressed as a change to your code, e.g. an RBAC diff, a NetworkPolicy or a policy definition
- Example admission policies written out for the highest priority findings
- A roadmap split into quick wins measured in weeks and platform changes measured in quarters
- A technical walkthrough with the platform team and business owners