Securing a Managed Kubernetes Platform

A cloud infrastructure provider was preparing to offer managed Kubernetes to its customers, alongside an internal platform cluster hosting its own managed services. With no in-house security team, it asked Falx to find the weaknesses before customers did. Falx ran architecture and threat modelling workshops, reviewed the infrastructure-as-code, then tested both environments using a deliberately malicious workload. We demonstrated a container escape to a control-plane node and identified permission, secrets and supply-chain weaknesses, each with a prioritised fix, without disrupting any service.

At a glance

The challenge

The client had built two Kubernetes environments. The first was an internal platform cluster hosting managed services for its customers, including secrets management. The second was a multi-tenant managed Kubernetes service, where each customer gets their own cluster on shared infrastructure.

Before opening the managed service more widely, the client needed independent assurance on three questions. Could one customer’s workload reach another customer’s cluster? Could a compromised workload reach the platform underneath? And was the infrastructure-as-code that builds everything introducing weaknesses before a single workload ran?

The client had no dedicated security team, and the constraints were strict. Testing had to take place in non-production environments over restricted VPN access, with proof-of-concept exploitation only. Modifying data, service disruption and social engineering were not permitted, and total effort was capped at 31 consultant-days.

What we did

1. Architecture and threat modelling workshops

We started with workshops alongside the client’s platform engineers to map how both environments were built and connected. Together we defined what a realistic “malicious workload” would look like, from a customer deploying hostile code to an attacker who has compromised a legitimate container. This turned a large set of architecture documentation into a short list of attack paths worth testing.

2. Infrastructure-as-code and GitOps review

We reviewed the Terraform and Flux GitOps configuration that deploys both environments. This surfaced risks before any active testing began, including container images referenced without integrity checks, shared SSH keys, and secrets stored unencrypted in Terraform state.

3. Active testing with a malicious workload

We deployed a controlled malicious workload into each environment and tested from the perspectives of a tenant user, a compromised workload, and an unauthenticated and authenticated attacker against the Kubernetes and management APIs. Using a privileged pod configuration, we demonstrated a container escape to a control-plane node, showing how a single compromised container could reach host processes and sensitive API tokens.

4. Network, tenancy and control-plane testing

We tested whether network policy and segmentation held between namespaces, tenant clusters and platform services, and whether internal APIs could be reached through cluster networking components. We also checked authentication flows and how secrets were exposed to workloads.

Results

• A container escape path to a control-plane node, demonstrated safely, with stricter pod security controls recommended to close it.
• Overly broad administrative permissions identified, with a move to least-privilege roles recommended.
• Inconsistent pod security standards across clusters identified, with a single baseline recommended.
• Secrets in plain-text configuration and Terraform state identified, with a move to dedicated secrets management and encrypted state recommended.
• Cloud metadata reachable from workloads, with restrictions recommended.
• Zero disruption. All testing ran within the agreed rules, and every environment was returned to its pre-test state.

The client received separate detailed technical reports and debrief workshops for each environment, plus an executive summary for leadership. This gave the engineering team a prioritised fix list and gave leadership a clear view of risk before launch.

What happened next

Four months later, the client brought Falx back to test its secure data platform, focusing on tenant isolation and access control. Read that case study.

Advice for similar organisations

• Block privileged containers by default. Enforce Kubernetes Pod Security Standards with an admission controller such as Kyverno or OPA Gatekeeper, so a single misconfigured workload cannot escape to the host.
• Keep secrets out of ConfigMaps and Terraform state. Use a dedicated secrets manager, encrypt remote state, and treat anyone with state access as having access to every secret it contains.
• Threat model before you test. A few days of workshops focused the testing on the attack paths that mattered and avoided spending effort on low-value scanning.

Facing something similar?

If you are launching a Kubernetes platform or multi-tenant service and need independent assurance before customers arrive, book a call with Falx.