feat(skills): add Kubernetes security testing skill

[mvanhorn]

Summary

Adds strix/skills/cloud/kubernetes.md - the first skill in the cloud/ category. Covers 7 attack domains for Kubernetes cluster security testing.

Why this matters

The cloud/ directory has a .gitkeep placeholder but zero skills (#324). Strix has 17 vulnerability skills, 9 tooling skills, and 3 framework skills - but no cloud infrastructure coverage. Kubernetes is the most common container orchestration target, and agents currently lack the domain knowledge to test it.

Changes

One new file: strix/skills/cloud/kubernetes.md (218 lines)

Covers:

• RBAC misconfigurations - wildcard verbs, cluster-admin over-grants, auto-mounted SA tokens
• Exposed APIs - API server anonymous auth, kubelet read-only port, etcd, Dashboard
• Container escapes - privileged containers, hostPID/hostNetwork, mounted sockets, cgroup release_agent
• Network policy gaps - missing NetworkPolicy, egress holes, DNS tunneling
• Secret management - base64 secrets in etcd, env var exposure, Helm release values
• Workload misconfigs - running as root, no resource limits, allowPrivilegeEscalation
• Supply chain risks - mutable image tags, unsigned images, unverified Helm charts

Each section includes specific kubectl commands, curl probes, and validation methods. Format matches the existing SSRF skill (the gold standard at 182 lines).

No code changes. The skill loader in strix/skills/__init__.py auto-discovers .md files in category directories.

Video Demo

Testing

No Python changes - make check-all is unaffected. The skill is a markdown knowledge package that gets injected into agent system prompts at runtime.

This contribution was developed with AI assistance (Claude Code).

Fixes #324

[greptile-apps]

Greptile Summary

Adds strix/skills/cloud/kubernetes.md, a 223-line Kubernetes security testing skill covering RBAC misconfigs, exposed APIs, container escapes, network policies, secrets management, workload hardening, and supply chain risks. All three issues flagged in the previous review round — the base64 -d on a JSON map, the anonymous-auth default description, and the Pro Tip #6 capability conflation — have been corrected in this version.

Confidence Score: 5/5

Safe to merge; only one minor P2 style issue remains with the cgroup subsystem choice in the escape snippet

All three previously blocking issues are resolved, the skill content is technically accurate, and the single remaining finding is a P2 suggestion that does not affect correctness of the skill as a knowledge document

No files require special attention

Important Files Changed

Filename	Overview
strix/skills/cloud/kubernetes.md	New 223-line Kubernetes security testing skill; all three previously flagged technical errors (base64 command, anonymous-auth default, Pro Tip #6 logic) are corrected; one minor issue remains with rdma cgroup subsystem specificity in the container escape snippet

Prompt To Fix All With AI

This is a comment left during a code review.
Path: strix/skills/cloud/kubernetes.md
Line: 83

Comment:
**`rdma` cgroup subsystem may not be available**

`mount -t cgroup -o rdma` requires `CONFIG_CGROUP_RDMA` to be compiled into the kernel, which is optional and absent on many production Linux distributions and cloud-provider node images. An agent following this command on such a node will get a mount failure and silently fail the entire escape attempt. The `memory` subsystem is available on virtually every kernel that supports cgroup v1.

```suggestion
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (4): Last reviewed commit: "Clarify cgroup escape requirements" | Re-trigger Greptile}

[bearsyankees]

@greptile

[greptile-apps]

Anonymous auth is enabled by default, not disabled

The parenthetical (disabled by default since 1.6 but still found in the wild) is factually backwards. The --anonymous-auth flag defaults to true in every Kubernetes release, including 1.6+. Unauthenticated requests receive the identity system:anonymous / system:unauthenticated. What changed in 1.6 is that the RBAC authorizer became the default and system:unauthenticated no longer has a default ClusterRole binding — so anonymous auth is on but unprivileged by default.

An agent reading this will assume the API server rejects anonymous requests unless explicitly misconfigured, and may skip probing for anonymous access on clusters where anonymous auth is working as-shipped (enabled, no useful RBAC). The correct framing:

Suggested change

	- Anonymous access (enabled by default but grants no permissions unless explicitly bound via RBAC; the API server accepts anonymous requests and assigns `system:unauthenticated` group membership by default)

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/skills/cloud/kubernetes.md
Line: 32

Comment:
**Anonymous auth is enabled by default, not disabled**

The parenthetical `(disabled by default since 1.6 but still found in the wild)` is factually backwards. The `--anonymous-auth` flag defaults to `true` in every Kubernetes release, including 1.6+. Unauthenticated requests receive the identity `system:anonymous` / `system:unauthenticated`. What changed in 1.6 is that the RBAC authorizer became the default and `system:unauthenticated` no longer has a default ClusterRole binding — so anonymous auth is **on** but **unprivileged** by default.

An agent reading this will assume the API server rejects anonymous requests unless explicitly misconfigured, and may skip probing for anonymous access on clusters where anonymous auth is working as-shipped (enabled, no useful RBAC). The correct framing:

```suggestion
- Anonymous access (enabled by default but grants no permissions unless explicitly bound via RBAC; the API server accepts anonymous requests and assigns `system:unauthenticated` group membership by default)
```

How can I resolve this? If you propose a fix, please make it concise.

[bearsyankees]

@greptileai

[greptile-apps]

Pro Tip #6 conflates privileged and CAP_SYS_ADMIN as independent co-requirements

privileged: true already grants every Linux capability, including CAP_SYS_ADMIN. Telling an agent they must find both will cause it to skip the cgroup release_agent escape for pods that have only CAP_SYS_ADMIN explicitly granted (without privileged: true) — which is a real and common scenario. The Container Escapes section above correctly states "CAP_SYS_ADMIN + unconfined AppArmor" is sufficient on its own; this tip contradicts that.

Suggested change

	3. Test metadata endpoint access early - cloud credentials from pods are the fastest path to cluster-admin
	6. Container escapes via cgroup release_agent require `CAP_SYS_ADMIN` (granted by `privileged: true` or as a standalone capability) and an unconfined AppArmor/seccomp profile - either condition grants the mount syscall needed for the technique

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/skills/cloud/kubernetes.md
Line: 213

Comment:
**Pro Tip #6 conflates `privileged` and `CAP_SYS_ADMIN` as independent co-requirements**

`privileged: true` already grants every Linux capability, including `CAP_SYS_ADMIN`. Telling an agent they must find *both* will cause it to skip the cgroup release_agent escape for pods that have only `CAP_SYS_ADMIN` explicitly granted (without `privileged: true`) — which is a real and common scenario. The Container Escapes section above correctly states "`CAP_SYS_ADMIN` + unconfined AppArmor" is sufficient on its own; this tip contradicts that.

```suggestion
6. Container escapes via cgroup release_agent require `CAP_SYS_ADMIN` (granted by `privileged: true` or as a standalone capability) and an unconfined AppArmor/seccomp profile - either condition grants the mount syscall needed for the technique
```

How can I resolve this? If you propose a fix, please make it concise.

[bearsyankees]

@greptileai

[bearsyankees]

Thanks @mvanhorn, merging now!

[mvanhorn]

Thanks for landing the Kubernetes security skill, @bearsyankees.