Menu

Individual skill

attacking-eks-gke-aks

0upvotes

Assess managed Kubernetes clusters on EKS, GKE, and AKS by exploiting the seams between cloud IAM and Kubernetes RBAC -- IRSA/OIDC trust abuse, Workload Identity Federation, pod-to-IMDS escalation, aws-auth ConfigMap takeover, node pool service account abuse, and AAD integration weaknesses. Use when pentesting a managed k8s cluster, reviewing RBAC in EKS/GKE/AKS, testing pod-to-cloud escalation, or assessing network policy enforcement across namespaces.

secskills-offense/skills/attacking-eks-gke-aks/SKILL.md

Read pinned source

Source commit ca53957bcd8e3b83b5d4d190bb3ad008a4f15c84

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 6, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
188
Repository last updated
Sep 4, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# Attacking Managed Kubernetes (EKS, GKE, AKS)

Managed Kubernetes is a special target because it operates across two
independent authorization planes: the cloud provider's IAM layer and
Kubernetes' own RBAC layer. Each plane has its own identities, policies, and
trust boundaries. The escalation paths live at the seams -- where a Kubernetes
service account maps to a cloud IAM role, where a pod inherits a node's cloud
credentials via the instance metadata service, or where a cluster-admin
binding was granted through a cloud identity mapping that nobody audits. An
attacker who understands only one plane misses the paths that cross into the
other.

Only against systems you are authorized to test.