This skill covers hardening managed Kubernetes clusters on EKS, AKS, and GKE by implementing Pod Security Standards, network policies, workload identity, RBAC scoping, image admission controls, and runtime security monitoring. It addresses cloud-specific security features including IRSA for EKS, Workload Identity for GKE, and Managed Identities for AKS.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
This skill covers hardening managed Kubernetes clusters on EKS, AKS, and GKE by implementing Pod Security Standards, network policies, workload identity, RBAC scoping, image admission controls, and runtime security monitoring. It addresses cloud-specific security features including IRSA for EKS, Workload Identity for GKE, and Managed Identities for AKS.
When deploying new managed Kubernetes clusters in production with security requirements
When hardening existing EKS, AKS, or GKE clusters after a security audit or pentest finding
When implementing workload identity to eliminate static cloud credentials in pods
When enforcing pod security policies across namespaces to prevent container escapes
When integrating runtime security monitoring for detecting container-level threats
Do not use for non-Kubernetes container deployments like ECS Fargate or Azure Container Instances, for application-level security within containers (see securing-serverless-functions), or for CI/CD pipeline security (see implementing-cloud-devsecops).
Common Misconfigurations & Verification
PSA labels only protect labeled namespaces: new namespaces and kube-system/default are unprotected, and warn/audit labels don't block. Verify with kubectl get ns -L pod-security.kubernetes.io/enforce and confirm enforce: restricted is set where required.
NetworkPolicies are no-ops without an enforcing CNI: on EKS the VPC CNI needs the network-policy controller enabled (or use Calico/Cilium). Test a default-deny by kubectl exec-ing into a pod and curling a blocked peer - it must time out.
Default-deny egress that omits DNS (kube-dns UDP/TCP 53) silently breaks name resolution. After applying, confirm pods still resolve a service name.
Workload identity fallback: IRSA / GKE WI / AKS federated credential needs the SA annotation AND the trust subject to match system:serviceaccount:NS:SA exactly; a mismatch falls back to the (broader) node role. Verify by exec-ing and running aws sts get-caller-identity or hitting the metadata endpoint.
automountServiceAccountToken: false must be set on the pod or SA, or the default token is still mounted - confirm /var/run/secrets/kubernetes.io/serviceaccount is absent.
Kyverno in Audit mode doesn't block; require validationFailureAction: Enforce and a registry pattern that matches the real path.
Verify it actually works: run kube-bench after changes; attempt to schedule a privileged/root pod in a restricted namespace (expect rejection); and deploy a disallowed-registry or mutable-tag image to confirm the admission policy denies it.
Prerequisites
Managed Kubernetes cluster provisioned on EKS, AKS, or GKE with admin access
kubectl configured with cluster admin credentials
Familiarity with Kubernetes RBAC, namespaces, and security contexts
Apply Pod Security Admission labels at the namespace level to enforce the Restricted profile in production namespaces. Pod Security Policies were removed in Kubernetes v1.25 and replaced with Pod Security Admission.
# Production namespace with restricted Pod Security StandardapiVersion:v1kind:Namespacemetadata:name:productionlabels:pod-security.kubernetes.io/enforce:restrictedpod-security.kubernetes.io/enforce-version:latestpod-security.kubernetes.io/audit:restrictedpod-security.kubernetes.io/warn:restricted---# Staging namespace with baseline enforcementapiVersion:v1kind:Namespacemetadata:name:staginglabels:pod-security.kubernetes.io/enforce:baselinepod-security.kubernetes.io/audit:restrictedpod-security.kubernetes.io/warn:restricted
# Pod spec compliant with restricted profileapiVersion:v1kind:Podmetadata:name:secure-appnamespace:productionspec:automountServiceAccountToken:falsesecurityContext:runAsNonRoot:truerunAsUser:1000fsGroup:1000seccompProfile:type:RuntimeDefaultcontainers:-name:appimage:company/app:v2.1@sha256:abc123...securityContext:allowPrivilegeEscalation:falsereadOnlyRootFilesystem:truecapabilities:drop: ["ALL"]
resources:limits:cpu:"500m"memory:"256Mi"requests:cpu:"100m"memory:"128Mi"
Step 2: Configure Cloud-Native Workload Identity
Eliminate static cloud credentials in pods by binding Kubernetes service accounts to cloud IAM roles.
# EKS: IAM Roles for Service Accounts (IRSA)
eksctl create iamserviceaccount \
--cluster production-cluster \
--namespace production \
--name web-app-sa \
--attach-policy-arn arn:aws:iam::123456789012:policy/WebAppS3ReadOnly \
--approve
# GKE: Workload Identity
gcloud iam service-accounts create web-app-sa \
--project=my-gcp-project
gcloud iam service-accounts add-iam-policy-binding \
web-app-sa@my-gcp-project.iam.gserviceaccount.com \
--role roles/storage.objectViewer \
--member "serviceAccount:my-gcp-project.svc.id.goog[production/web-app-sa]"
kubectl annotate serviceaccount web-app-sa \
--namespace production \
iam.gke.io/gcp-service-account=web-app-sa@my-gcp-project.iam.gserviceaccount.com
# AKS: Azure AD Workload Identity
az identity create --name web-app-identity --resource-group production-rg
az identity federated-credential create \
--name web-app-federation \
--identity-name web-app-identity \
--resource-group production-rg \
--issuer "$(az aks show -n production-cluster -g production-rg --query oidcIssuerProfile.issuerUrl -o tsv)" \
--subject system:serviceaccount:production:web-app-sa
Step 3: Implement Network Policies
Deploy network policies to restrict pod-to-pod communication following the principle of least privilege. By default, Kubernetes allows all pods to communicate with each other.
# Default deny all ingress and egress in production namespaceapiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-deny-allnamespace:productionspec:podSelector: {}
policyTypes:-Ingress-Egress---# Allow web-app to receive traffic from ingress controller onlyapiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-ingress-to-webnamespace:productionspec:podSelector:matchLabels:app:web-apppolicyTypes:-Ingressingress:-from:-namespaceSelector:matchLabels:name:ingress-nginxports:-protocol:TCPport:8080---# Allow web-app to connect to database onlyapiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-web-to-dbnamespace:productionspec:podSelector:matchLabels:app:web-apppolicyTypes:-Egressegress:-to:-podSelector:matchLabels:app:postgresports:-protocol:TCPport:5432-to:-namespaceSelector: {}
podSelector:matchLabels:k8s-app:kube-dnsports:-protocol:UDPport:53
Step 4: Configure RBAC with Least Privilege
Scope Kubernetes RBAC roles to specific namespaces and resources. Avoid ClusterRoleBindings for non-administrative users.
Use admission controllers to enforce that only signed images from trusted registries are deployed. Implement OPA/Gatekeeper or Kyverno for policy enforcement.
# Kyverno policy: require images from approved registriesapiVersion:kyverno.io/v1kind:ClusterPolicymetadata:name:restrict-image-registriesspec:validationFailureAction:Enforcerules:-name:validate-registriesmatch:any:-resources:kinds: ["Pod"]
validate:message:"Images must come from approved registries"pattern:spec:containers:-image:"123456789012.dkr.ecr.us-east-1.amazonaws.com/* | gcr.io/my-gcp-project/*"---# Kyverno policy: require image digest (no mutable tags)apiVersion:kyverno.io/v1kind:ClusterPolicymetadata:name:require-image-digestspec:validationFailureAction:Enforcerules:-name:require-digestmatch:any:-resources:kinds: ["Pod"]
validate:message:"Images must use digest references, not tags"pattern:spec:containers:-image:"*@sha256:*"
Step 6: Enable Runtime Security Monitoring
Deploy runtime security tools to detect anomalous behavior inside containers including process execution, file system modifications, and network connections.
Three profiles (Privileged, Baseline, Restricted) enforced via Pod Security Admission that control pod security context capabilities
Workload Identity
Cloud-native mechanism binding Kubernetes service accounts to cloud IAM roles for credential-free cloud API access (IRSA, GKE WI, AKS MI)
Network Policy
Kubernetes resource defining allowed ingress and egress traffic flows between pods, enforced by the CNI plugin
Admission Controller
Kubernetes plugin that intercepts API requests before persistence to validate or mutate resources against security policies
RBAC
Role-Based Access Control in Kubernetes, defining what actions (verbs) identities can perform on which resources in which namespaces
Seccomp Profile
Linux kernel feature restricting the system calls a container process can make, reducing the kernel attack surface
Service Mesh
Infrastructure layer (Istio, Linkerd) providing mutual TLS, traffic policies, and observability for service-to-service communication
Tools & Systems
Falco: Open-source runtime security engine detecting anomalous behavior in containers using kernel-level system call monitoring
Kyverno: Kubernetes-native policy engine for admission control, mutation, and generation of resources based on security policies
kube-bench: CIS Kubernetes Benchmark assessment tool checking cluster configuration against security best practices
Trivy: Vulnerability scanner for container images, file systems, and Kubernetes resources with SBOM generation
Calico/Cilium: CNI plugins providing network policy enforcement and advanced network security features including eBPF-based monitoring
Common Scenarios
Scenario: Cryptominer Deployed via Compromised Container Image
Context: GuardDuty Extended Threat Detection generates an AttackSequence:EKS/CompromisedCluster finding. A developer pulled a public Docker image containing an embedded XMRig cryptominer that executes at container startup.
Approach:
Isolate the affected pod by applying a deny-all network policy targeting its labels
Capture the container image digest and scan it with Trivy to identify the embedded binary
Review Kubernetes audit logs to identify who deployed the compromised image and when
Deploy Kyverno ClusterPolicy requiring images from approved private registries only
Enable image digest pinning to prevent tag mutation attacks
Deploy Falco with rules detecting crypto mining process signatures (/usr/bin/xmrig, stratum+tcp connections)
Pitfalls: Deleting the pod before capturing the image digest and audit logs destroys forensic evidence. Blocking only the specific image tag allows the attacker to re-push with a different tag.
Output Format
Kubernetes Security Assessment Report
=======================================
Cluster: production-cluster (EKS 1.29)
Provider: AWS (us-east-1)
Assessment Date: 2025-02-23
Tool: kube-bench v0.8.0 + manual review
CIS KUBERNETES BENCHMARK RESULTS:
Total Controls: 124
Passed: 98 (79%)
Failed: 18 (15%)
Warnings: 8 (6%)
CRITICAL FINDINGS:
[K8S-001] 3 namespaces lack Pod Security Standards enforcement
Namespaces: monitoring, logging, default
Remediation: Apply restricted PSA labels
[K8S-002] Default service account tokens auto-mounted in 12 deployments
Risk: Credential theft if container is compromised
Remediation: Set automountServiceAccountToken: false
[K8S-003] No network policies in production namespace
Risk: Unrestricted lateral movement between all pods
Remediation: Deploy default-deny policy with explicit allow rules
HIGH FINDINGS:
[K8S-004] 5 pods running as root with privileged security context
[K8S-005] Images deployed using mutable tags (:latest) in 8 deployments
[K8S-006] RBAC ClusterRoleBinding grants cluster-admin to developers group
