Wiz CTF #5: Game of Pods

No flags are included in this writeup.

Overview

Game of Pods was the first challenge where the championship really started feeling like a cloud security marathon. The starting permissions were intentionally tiny. The solve required understanding Kubernetes networking, service accounts, kubelet behavior, and how RBAC permissions can compose into something much stronger than they look.

Initial Position

The starting pod had limited namespace permissions. It could inspect a small amount of local context, but it was not handed secrets, cluster-admin, or obvious escape primitives.

The first useful checks were:

• kubectl auth can-i --list
• pod YAML and service account identity
• namespace-local services
• DNS and service CIDR behavior
• image names and registry clues

The registry clues were interesting, but the winning path was not simply “pull the flag image.” The challenge was designed to force a deeper Kubernetes chain.

Internal Service Discovery

The breakthrough was discovering an internal debug-style service. Debug services are dangerous because they often exist to make privileged operations convenient. In this case, the service acted as a bridge to kubelet-style functionality.

The service had multiple weaknesses:

• namespace validation that could be bypassed with path traversal
• URL construction that could be influenced through user-controlled parameters
• access to kubelet endpoints that should not have been exposed this casually
• a service account with permissions that became powerful in the wrong hands

This is where the challenge moved from “enumerate Kubernetes” to “exploit Kubernetes glue code.”

Token Movement

The next important move was extracting a more useful service account token through the debug bridge behavior. After that, Kubernetes’ own service-account-token secret behavior became the privilege escalation primitive.

Creating a secret of type kubernetes.io/service-account-token with the right annotation can cause Kubernetes to populate it with a token for the referenced service account. If an attacker can create such a secret in the right namespace, they can sometimes mint a token for a more privileged workload identity.

That is a painful behavior to rediscover mid-CTF, but it is also exactly why Kubernetes RBAC around secrets needs to be treated as highly sensitive.

Final Escalation

The final step used node-related permissions. The dangerous combination was the ability to manipulate node status/proxy behavior in a way that made the API server route traffic through a privileged path.

The shape of the chain was:

1. start with a restricted pod
2. discover internal debug bridge
3. bypass weak namespace/path validation
4. use SSRF-like behavior to reach kubelet functionality
5. extract a stronger service account token
6. create a token secret for an even stronger service account
7. abuse node proxy/status behavior to reach cluster-level data

Root Cause

This challenge was about compounding Kubernetes risk:

• debug tooling exposed privileged cluster internals
• validation logic trusted path structure too much
• user-controlled URL pieces reached sensitive kubelet paths
• secret creation permissions enabled service account token abuse
• node proxy/status permissions were too broad

Any one of those issues would be concerning. Together they become a full compromise path.

Takeaways

Game of Pods is the kind of Kubernetes challenge that forces good habits:

• never stop at pod RBAC; map service accounts and internal services
• treat debug bridges as high-risk infrastructure
• restrict secret creation permissions carefully
• avoid granting node proxy/status permissions to workload identities
• monitor service account token secret creation

This was one of the hardest early challenges because it required respecting Kubernetes as a distributed system, not a single API endpoint.