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

This PR adds strix/skills/cloud/kubernetes.md, the first skill in the cloud/ category, providing structured Kubernetes security testing knowledge covering 7 attack domains: RBAC misconfigurations, exposed APIs, container escapes, network policy gaps, secret management issues, workload misconfigs, and supply chain risks.

• The file follows the expected frontmatter format (name, description) and will be correctly auto-discovered and loaded by the skill loader in strix/skills/__init__.py
• Structure and section layout match the SSRF gold standard: Attack Surface → Key Vulnerabilities → Bypass Techniques → Testing Methodology → Validation → False Positives → Impact → Pro Tips → Summary
• One incorrect command in the Secret Management test block: kubectl get secret <name> -o jsonpath='{.data}' | base64 -d pipes a JSON map (not a base64 string) into base64 -d, producing garbled output; should reference a specific key (e.g. .data.password) or use jq's @base64d filter
• All other kubectl, curl, and jq commands are technically accurate and consistent with current Kubernetes API conventions
• The cross-reference to the ssrf skill for SSRF-mediated Kubernetes access is a good design choice, keeping the skills complementary and modular

Confidence Score: 4/5

• Safe to merge after fixing the one incorrect base64 decode command; no code or Python changes are introduced.
• The PR is purely additive documentation with no Python changes. The skill correctly integrates with the auto-discovery loader, the format matches the established convention, and the content is accurate throughout — with one exception: the base64 -d command applied to the full .data JSON map will silently fail when an agent attempts to use it. That's the only concrete fix needed before merge.
• strix/skills/cloud/kubernetes.md — fix the base64 -d command in the Secret Management test block

Important Files Changed

Filename	Overview
strix/skills/cloud/kubernetes.md	New Kubernetes security testing skill; well-structured and follows existing conventions; one incorrect base64 -d command in the Secret Management test block

Prompt To Fix All With AI

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

Comment:
**`base64 -d` applied to JSON map, not a base64 string**

`kubectl get secret <name> -o jsonpath='{.data}'` returns the entire `data` map as a JSON object (e.g. `{"password":"c2VjcmV0","token":"dG9rZW4="}`). Piping that JSON blob to `base64 -d` will produce garbled output or an error, not the decoded secret values. An agent following this command verbatim would get confused.

To decode all values at once:
```suggestion
kubectl get secret <name> -o json | jq '.data | map_values(@base64d)'
```
Or to decode a specific key:
```
kubectl get secret <name> -o jsonpath='{.data.password}' | base64 -d
```

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

_{Reviews (1): Last reviewed commit: "feat(skills): add Kubernetes security te..." | Re-trigger Greptile}

[greptile-apps]

base64 -d applied to JSON map, not a base64 string

kubectl get secret <name> -o jsonpath='{.data}' returns the entire data map as a JSON object (e.g. {"password":"c2VjcmV0","token":"dG9rZW4="}). Piping that JSON blob to base64 -d will produce garbled output or an error, not the decoded secret values. An agent following this command verbatim would get confused.

To decode all values at once:

Suggested change

	kubectl get secret <name> -o json | jq '.data | map_values(@base64d)'

Or to decode a specific key:

kubectl get secret <name> -o jsonpath='{.data.password}' | base64 -d

Prompt To Fix With AI

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

Comment:
**`base64 -d` applied to JSON map, not a base64 string**

`kubectl get secret <name> -o jsonpath='{.data}'` returns the entire `data` map as a JSON object (e.g. `{"password":"c2VjcmV0","token":"dG9rZW4="}`). Piping that JSON blob to `base64 -d` will produce garbled output or an error, not the decoded secret values. An agent following this command verbatim would get confused.

To decode all values at once:
```suggestion
kubectl get secret <name> -o json | jq '.data | map_values(@base64d)'
```
Or to decode a specific key:
```
kubectl get secret <name> -o jsonpath='{.data.password}' | base64 -d
```

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