[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AG9KVHV1SW17QKPGRWC855":3,"skill-same:01M6AG9KVHV1SW17QKPGRWC855":113},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":29,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":72,"commitSha":73,"skillDirectory":74,"forksCount":75,"repositoryHtmlUrl":76,"repositoryHomepageUrl":77,"ownerHtmlUrl":78,"ownerBlogUrl":79,"ownerDescription":80,"updatedAt":81,"install":82,"resources":95},"01M6AG9KVHV1SW17QKPGRWC855","securing-kubernetes-on-cloud",null,"Hardens managed Kubernetes clusters on EKS, AKS, and GKE by implementing Pod Security Standards, network policies, workload identity (IRSA for EKS, Workload Identity for GKE, Managed Identities for AKS), RBAC scoping, image admission controls, and runtime security monitoring. Use when deploying a new managed Kubernetes cluster with security requirements or hardening an existing EKS, AKS, or GKE cluster after an audit or pentest finding.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35990,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-kubernetes-on-cloud\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"cloud","securing kubernetes on cloud","kubernetes","cloud-security","pod-security-standards","security-standards","t1078","aks","gke","eks","network","security","image","monitoring","audit","pr","rbac","workload","identity","cybersecurity","2026-11-10 10:12:30",false,"---\nname: securing-kubernetes-on-cloud\ndescription: 'Hardens managed Kubernetes clusters on EKS, AKS, and GKE by implementing\n  Pod Security Standards, network policies, workload identity (IRSA for EKS, Workload\n  Identity for GKE, Managed Identities for AKS), RBAC scoping, image admission controls,\n  and runtime security monitoring. Use when deploying a new managed Kubernetes cluster\n  with security requirements or hardening an existing EKS, AKS, or GKE cluster after\n  an audit or pentest finding.\n\n  '\ndomain: cybersecurity\nsubdomain: cloud-security\ntags:\n- kubernetes-security\n- eks\n- aks\n- gke\n- pod-security-standards\n- container-runtime\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.IR-01\n- ID.AM-08\n- GV.SC-06\n- DE.CM-01\nmitre_attack:\n- T1078.004\n- T1530\n- T1537\n- T1580\n- T1610\n---\n\n# Securing Kubernetes on Cloud\n\n## When to Use\n\n- When deploying new managed Kubernetes clusters in production with security requirements\n- When hardening existing EKS, AKS, or GKE clusters after a security audit or pentest finding\n- When implementing workload identity to eliminate static cloud credentials in pods\n- When enforcing pod security policies across namespaces to prevent container escapes\n- When integrating runtime security monitoring for detecting container-level threats\n\n**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\u002FCD pipeline security (see implementing-cloud-devsecops).\n\n## Prerequisites\n\n- Managed Kubernetes cluster provisioned on EKS, AKS, or GKE with admin access\n- kubectl configured with cluster admin credentials\n- Familiarity with Kubernetes RBAC, namespaces, and security contexts\n- Container network interface plugin supporting network policies (Calico, Cilium)\n\n## Workflow\n\n### Step 1: Enforce Pod Security Standards\n\nApply 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.\n\n```yaml\n# Production namespace with restricted Pod Security Standard\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: production\n  labels:\n    pod-security.kubernetes.io\u002Fenforce: restricted\n    pod-security.kubernetes.io\u002Fenforce-version: latest\n    pod-security.kubernetes.io\u002Faudit: restricted\n    pod-security.kubernetes.io\u002Fwarn: restricted\n---\n# Staging namespace with baseline enforcement\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: staging\n  labels:\n    pod-security.kubernetes.io\u002Fenforce: baseline\n    pod-security.kubernetes.io\u002Faudit: restricted\n    pod-security.kubernetes.io\u002Fwarn: restricted\n```\n\n```yaml\n# Pod spec compliant with restricted profile\napiVersion: v1\nkind: Pod\nmetadata:\n  name: secure-app\n  namespace: production\nspec:\n  automountServiceAccountToken: false\n  securityContext:\n    runAsNonRoot: true\n    runAsUser: 1000\n    fsGroup: 1000\n    seccompProfile:\n      type: RuntimeDefault\n  containers:\n    - name: app\n      image: company\u002Fapp:v2.1@sha256:abc123...\n      securityContext:\n        allowPrivilegeEscalation: false\n        readOnlyRootFilesystem: true\n        capabilities:\n          drop: [\"ALL\"]\n      resources:\n        limits:\n          cpu: \"500m\"\n          memory: \"256Mi\"\n        requests:\n          cpu: \"100m\"\n          memory: \"128Mi\"\n```\n\n### Step 2: Configure Cloud-Native Workload Identity\n\nEliminate static cloud credentials in pods by binding Kubernetes service accounts to cloud IAM roles.\n\n```bash\n# EKS: IAM Roles for Service Accounts (IRSA)\neksctl create iamserviceaccount \\\n  --cluster production-cluster \\\n  --namespace production \\\n  --name web-app-sa \\\n  --attach-policy-arn arn:aws:iam::123456789012:policy\u002FWebAppS3ReadOnly \\\n  --approve\n\n# GKE: Workload Identity\ngcloud iam service-accounts create web-app-sa \\\n  --project=my-gcp-project\n\ngcloud iam service-accounts add-iam-policy-binding \\\n  web-app-sa@my-gcp-project.iam.gserviceaccount.com \\\n  --role roles\u002Fstorage.objectViewer \\\n  --member \"serviceAccount:my-gcp-project.svc.id.goog[production\u002Fweb-app-sa]\"\n\nkubectl annotate serviceaccount web-app-sa \\\n  --namespace production \\\n  iam.gke.io\u002Fgcp-service-account=web-app-sa@my-gcp-project.iam.gserviceaccount.com\n\n# AKS: Azure AD Workload Identity\naz identity create --name web-app-identity --resource-group production-rg\naz identity federated-credential create \\\n  --name web-app-federation \\\n  --identity-name web-app-identity \\\n  --resource-group production-rg \\\n  --issuer \"$(az aks show -n production-cluster -g production-rg --query oidcIssuerProfile.issuerUrl -o tsv)\" \\\n  --subject system:serviceaccount:production:web-app-sa\n```\n\n### Step 3: Implement Network Policies\n\nDeploy 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.\n\n```yaml\n# Default deny all ingress and egress in production namespace\napiVersion: networking.k8s.io\u002Fv1\nkind: NetworkPolicy\nmetadata:\n  name: default-deny-all\n  namespace: production\nspec:\n  podSelector: {}\n  policyTypes:\n    - Ingress\n    - Egress\n---\n# Allow web-app to receive traffic from ingress controller only\napiVersion: networking.k8s.io\u002Fv1\nkind: NetworkPolicy\nmetadata:\n  name: allow-ingress-to-web\n  namespace: production\nspec:\n  podSelector:\n    matchLabels:\n      app: web-app\n  policyTypes:\n    - Ingress\n  ingress:\n    - from:\n        - namespaceSelector:\n            matchLabels:\n              name: ingress-nginx\n      ports:\n        - protocol: TCP\n          port: 8080\n---\n# Allow web-app to connect to database only\napiVersion: networking.k8s.io\u002Fv1\nkind: NetworkPolicy\nmetadata:\n  name: allow-web-to-db\n  namespace: production\nspec:\n  podSelector:\n    matchLabels:\n      app: web-app\n  policyTypes:\n    - Egress\n  egress:\n    - to:\n        - podSelector:\n            matchLabels:\n              app: postgres\n      ports:\n        - protocol: TCP\n          port: 5432\n    - to:\n        - namespaceSelector: {}\n          podSelector:\n            matchLabels:\n              k8s-app: kube-dns\n      ports:\n        - protocol: UDP\n          port: 53\n```\n\n### Step 4: Configure RBAC with Least Privilege\n\nScope Kubernetes RBAC roles to specific namespaces and resources. Avoid ClusterRoleBindings for non-administrative users.\n\n```yaml\n# Developer role scoped to specific namespace\napiVersion: rbac.authorization.k8s.io\u002Fv1\nkind: Role\nmetadata:\n  name: developer-role\n  namespace: staging\nrules:\n  - apiGroups: [\"\"]\n    resources: [\"pods\", \"pods\u002Flog\", \"services\", \"configmaps\"]\n    verbs: [\"get\", \"list\", \"watch\"]\n  - apiGroups: [\"apps\"]\n    resources: [\"deployments\"]\n    verbs: [\"get\", \"list\", \"watch\", \"update\", \"patch\"]\n  # Explicitly deny secrets access\n---\napiVersion: rbac.authorization.k8s.io\u002Fv1\nkind: RoleBinding\nmetadata:\n  name: developer-binding\n  namespace: staging\nsubjects:\n  - kind: Group\n    name: developers\n    apiGroup: rbac.authorization.k8s.io\nroleRef:\n  kind: Role\n  name: developer-role\n  apiGroup: rbac.authorization.k8s.io\n```\n\n### Step 5: Deploy Image Admission Controls\n\nUse admission controllers to enforce that only signed images from trusted registries are deployed. Implement OPA\u002FGatekeeper or Kyverno for policy enforcement.\n\n```yaml\n# Kyverno policy: require images from approved registries\napiVersion: kyverno.io\u002Fv1\nkind: ClusterPolicy\nmetadata:\n  name: restrict-image-registries\nspec:\n  validationFailureAction: Enforce\n  rules:\n    - name: validate-registries\n      match:\n        any:\n          - resources:\n              kinds: [\"Pod\"]\n      validate:\n        message: \"Images must come from approved registries\"\n        pattern:\n          spec:\n            containers:\n              - image: \"123456789012.dkr.ecr.us-east-1.amazonaws.com\u002F* | gcr.io\u002Fmy-gcp-project\u002F*\"\n---\n# Kyverno policy: require image digest (no mutable tags)\napiVersion: kyverno.io\u002Fv1\nkind: ClusterPolicy\nmetadata:\n  name: require-image-digest\nspec:\n  validationFailureAction: Enforce\n  rules:\n    - name: require-digest\n      match:\n        any:\n          - resources:\n              kinds: [\"Pod\"]\n      validate:\n        message: \"Images must use digest references, not tags\"\n        pattern:\n          spec:\n            containers:\n              - image: \"*@sha256:*\"\n```\n\n### Step 6: Enable Runtime Security Monitoring\n\nDeploy runtime security tools to detect anomalous behavior inside containers including process execution, file system modifications, and network connections.\n\n```bash\n# Deploy Falco for runtime threat detection\nhelm repo add falcosecurity https:\u002F\u002Ffalcosecurity.github.io\u002Fcharts\nhelm install falco falcosecurity\u002Ffalco \\\n  --namespace falco-system --create-namespace \\\n  --set falcosidekick.enabled=true \\\n  --set falcosidekick.config.slack.webhookurl=\"https:\u002F\u002Fhooks.slack.com\u002Fservices\u002Fxxx\"\n\n# Run kube-bench for CIS Kubernetes Benchmark assessment\nkubectl apply -f https:\u002F\u002Fraw.githubusercontent.com\u002Faquasecurity\u002Fkube-bench\u002Fmain\u002Fjob-eks.yaml\nkubectl logs -l app=kube-bench\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Pod Security Standards | Three profiles (Privileged, Baseline, Restricted) enforced via Pod Security Admission that control pod security context capabilities |\n| Workload Identity | Cloud-native mechanism binding Kubernetes service accounts to cloud IAM roles for credential-free cloud API access (IRSA, GKE WI, AKS MI) |\n| Network Policy | Kubernetes resource defining allowed ingress and egress traffic flows between pods, enforced by the CNI plugin |\n| Admission Controller | Kubernetes plugin that intercepts API requests before persistence to validate or mutate resources against security policies |\n| RBAC | Role-Based Access Control in Kubernetes, defining what actions (verbs) identities can perform on which resources in which namespaces |\n| Seccomp Profile | Linux kernel feature restricting the system calls a container process can make, reducing the kernel attack surface |\n| Service Mesh | Infrastructure layer (Istio, Linkerd) providing mutual TLS, traffic policies, and observability for service-to-service communication |\n\n## Tools & Systems\n\n- **Falco**: Open-source runtime security engine detecting anomalous behavior in containers using kernel-level system call monitoring\n- **Kyverno**: Kubernetes-native policy engine for admission control, mutation, and generation of resources based on security policies\n- **kube-bench**: CIS Kubernetes Benchmark assessment tool checking cluster configuration against security best practices\n- **Trivy**: Vulnerability scanner for container images, file systems, and Kubernetes resources with SBOM generation\n- **Calico\u002FCilium**: CNI plugins providing network policy enforcement and advanced network security features including eBPF-based monitoring\n\n## Common Scenarios\n\n### Scenario: Cryptominer Deployed via Compromised Container Image\n\n**Context**: GuardDuty Extended Threat Detection generates an AttackSequence:EKS\u002FCompromisedCluster finding. A developer pulled a public Docker image containing an embedded XMRig cryptominer that executes at container startup.\n\n**Approach**:\n1. Isolate the affected pod by applying a deny-all network policy targeting its labels\n2. Capture the container image digest and scan it with Trivy to identify the embedded binary\n3. Review Kubernetes audit logs to identify who deployed the compromised image and when\n4. Deploy Kyverno ClusterPolicy requiring images from approved private registries only\n5. Enable image digest pinning to prevent tag mutation attacks\n6. Deploy Falco with rules detecting crypto mining process signatures (\u002Fusr\u002Fbin\u002Fxmrig, stratum+tcp connections)\n\n**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.\n\n## Output Format\n\n```\nKubernetes Security Assessment Report\n=======================================\nCluster: production-cluster (EKS 1.29)\nProvider: AWS (us-east-1)\nAssessment Date: 2025-02-23\nTool: kube-bench v0.8.0 + manual review\n\nCIS KUBERNETES BENCHMARK RESULTS:\n  Total Controls: 124\n  Passed: 98 (79%)\n  Failed: 18 (15%)\n  Warnings: 8 (6%)\n\nCRITICAL FINDINGS:\n  [K8S-001] 3 namespaces lack Pod Security Standards enforcement\n    Namespaces: monitoring, logging, default\n    Remediation: Apply restricted PSA labels\n\n  [K8S-002] Default service account tokens auto-mounted in 12 deployments\n    Risk: Credential theft if container is compromised\n    Remediation: Set automountServiceAccountToken: false\n\n  [K8S-003] No network policies in production namespace\n    Risk: Unrestricted lateral movement between all pods\n    Remediation: Deploy default-deny policy with explicit allow rules\n\nHIGH FINDINGS:\n  [K8S-004] 5 pods running as root with privileged security context\n  [K8S-005] Images deployed using mutable tags (:latest) in 8 deployments\n  [K8S-006] RBAC ClusterRoleBinding grants cluster-admin to developers group\n```\n","# Securing Kubernetes on Cloud\n\n## When to Use\n\n- When deploying new managed Kubernetes clusters in production with security requirements\n- When hardening existing EKS, AKS, or GKE clusters after a security audit or pentest finding\n- When implementing workload identity to eliminate static cloud credentials in pods\n- When enforcing pod security policies across namespaces to prevent container escapes\n- When integrating runtime security monitoring for detecting container-level threats\n\n**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\u002FCD pipeline security (see implementing-cloud-devsecops).\n\n## Prerequisites\n\n- Managed Kubernetes cluster provisioned on EKS, AKS, or GKE with admin access\n- kubectl configured with cluster admin credentials\n- Familiarity with Kubernetes RBAC, namespaces, and security contexts\n- Container network interface plugin supporting network policies (Calico, Cilium)\n\n## Workflow\n\n### Step 1: Enforce Pod Security Standards\n\nApply 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.\n\n```yaml\n# Production namespace with restricted Pod Security Standard\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: production\n  labels:\n    pod-security.kubernetes.io\u002Fenforce: restricted\n    pod-security.kubernetes.io\u002Fenforce-version: latest\n    pod-security.kubernetes.io\u002Faudit: restricted\n    pod-security.kubernetes.io\u002Fwarn: restricted\n---\n# Staging namespace with baseline enforcement\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: staging\n  labels:\n    pod-security.kubernetes.io\u002Fenforce: baseline\n    pod-security.kubernetes.io\u002Faudit: restricted\n    pod-security.kubernetes.io\u002Fwarn: restricted\n```\n\n```yaml\n# Pod spec compliant with restricted profile\napiVersion: v1\nkind: Pod\nmetadata:\n  name: secure-app\n  namespace: production\nspec:\n  automountServiceAccountToken: false\n  securityContext:\n    runAsNonRoot: true\n    runAsUser: 1000\n    fsGroup: 1000\n    seccompProfile:\n      type: RuntimeDefault\n  containers:\n    - name: app\n      image: company\u002Fapp:v2.1@sha256:abc123...\n      securityContext:\n        allowPrivilegeEscalation: false\n        readOnlyRootFilesystem: true\n        capabilities:\n          drop: [\"ALL\"]\n      resources:\n        limits:\n          cpu: \"500m\"\n          memory: \"256Mi\"\n        requests:\n          cpu: \"100m\"\n          memory: \"128Mi\"\n```\n\n### Step 2: Configure Cloud-Native Workload Identity\n\nEliminate static cloud credentials in pods by binding Kubernetes service accounts to cloud IAM roles.\n\n```bash\n# EKS: IAM Roles for Service Accounts (IRSA)\neksctl create iamserviceaccount \\\n  --cluster production-cluster \\\n  --namespace production \\\n  --name web-app-sa \\\n  --attach-policy-arn arn:aws:iam::123456789012:policy\u002FWebAppS3ReadOnly \\\n  --approve\n\n# GKE: Workload Identity\ngcloud iam service-accounts create web-app-sa \\\n  --project=my-gcp-project\n\ngcloud iam service-accounts add-iam-policy-binding \\\n  web-app-sa@my-gcp-project.iam.gserviceaccount.com \\\n  --role roles\u002Fstorage.objectViewer \\\n  --member \"serviceAccount:my-gcp-project.svc.id.goog[production\u002Fweb-app-sa]\"\n\nkubectl annotate serviceaccount web-app-sa \\\n  --namespace production \\\n  iam.gke.io\u002Fgcp-service-account=web-app-sa@my-gcp-project.iam.gserviceaccount.com\n\n# AKS: Azure AD Workload Identity\naz identity create --name web-app-identity --resource-group production-rg\naz identity federated-credential create \\\n  --name web-app-federation \\\n  --identity-name web-app-identity \\\n  --resource-group production-rg \\\n  --issuer \"$(az aks show -n production-cluster -g production-rg --query oidcIssuerProfile.issuerUrl -o tsv)\" \\\n  --subject system:serviceaccount:production:web-app-sa\n```\n\n### Step 3: Implement Network Policies\n\nDeploy 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.\n\n```yaml\n# Default deny all ingress and egress in production namespace\napiVersion: networking.k8s.io\u002Fv1\nkind: NetworkPolicy\nmetadata:\n  name: default-deny-all\n  namespace: production\nspec:\n  podSelector: {}\n  policyTypes:\n    - Ingress\n    - Egress\n---\n# Allow web-app to receive traffic from ingress controller only\napiVersion: networking.k8s.io\u002Fv1\nkind: NetworkPolicy\nmetadata:\n  name: allow-ingress-to-web\n  namespace: production\nspec:\n  podSelector:\n    matchLabels:\n      app: web-app\n  policyTypes:\n    - Ingress\n  ingress:\n    - from:\n        - namespaceSelector:\n            matchLabels:\n              name: ingress-nginx\n      ports:\n        - protocol: TCP\n          port: 8080\n---\n# Allow web-app to connect to database only\napiVersion: networking.k8s.io\u002Fv1\nkind: NetworkPolicy\nmetadata:\n  name: allow-web-to-db\n  namespace: production\nspec:\n  podSelector:\n    matchLabels:\n      app: web-app\n  policyTypes:\n    - Egress\n  egress:\n    - to:\n        - podSelector:\n            matchLabels:\n              app: postgres\n      ports:\n        - protocol: TCP\n          port: 5432\n    - to:\n        - namespaceSelector: {}\n          podSelector:\n            matchLabels:\n              k8s-app: kube-dns\n      ports:\n        - protocol: UDP\n          port: 53\n```\n\n### Step 4: Configure RBAC with Least Privilege\n\nScope Kubernetes RBAC roles to specific namespaces and resources. Avoid ClusterRoleBindings for non-administrative users.\n\n```yaml\n# Developer role scoped to specific namespace\napiVersion: rbac.authorization.k8s.io\u002Fv1\nkind: Role\nmetadata:\n  name: developer-role\n  namespace: staging\nrules:\n  - apiGroups: [\"\"]\n    resources: [\"pods\", \"pods\u002Flog\", \"services\", \"configmaps\"]\n    verbs: [\"get\", \"list\", \"watch\"]\n  - apiGroups: [\"apps\"]\n    resources: [\"deployments\"]\n    verbs: [\"get\", \"list\", \"watch\", \"update\", \"patch\"]\n  # Explicitly deny secrets access\n---\napiVersion: rbac.authorization.k8s.io\u002Fv1\nkind: RoleBinding\nmetadata:\n  name: developer-binding\n  namespace: staging\nsubjects:\n  - kind: Group\n    name: developers\n    apiGroup: rbac.authorization.k8s.io\nroleRef:\n  kind: Role\n  name: developer-role\n  apiGroup: rbac.authorization.k8s.io\n```\n\n### Step 5: Deploy Image Admission Controls\n\nUse admission controllers to enforce that only signed images from trusted registries are deployed. Implement OPA\u002FGatekeeper or Kyverno for policy enforcement.\n\n```yaml\n# Kyverno policy: require images from approved registries\napiVersion: kyverno.io\u002Fv1\nkind: ClusterPolicy\nmetadata:\n  name: restrict-image-registries\nspec:\n  validationFailureAction: Enforce\n  rules:\n    - name: validate-registries\n      match:\n        any:\n          - resources:\n              kinds: [\"Pod\"]\n      validate:\n        message: \"Images must come from approved registries\"\n        pattern:\n          spec:\n            containers:\n              - image: \"123456789012.dkr.ecr.us-east-1.amazonaws.com\u002F* | gcr.io\u002Fmy-gcp-project\u002F*\"\n---\n# Kyverno policy: require image digest (no mutable tags)\napiVersion: kyverno.io\u002Fv1\nkind: ClusterPolicy\nmetadata:\n  name: require-image-digest\nspec:\n  validationFailureAction: Enforce\n  rules:\n    - name: require-digest\n      match:\n        any:\n          - resources:\n              kinds: [\"Pod\"]\n      validate:\n        message: \"Images must use digest references, not tags\"\n        pattern:\n          spec:\n            containers:\n              - image: \"*@sha256:*\"\n```\n\n### Step 6: Enable Runtime Security Monitoring\n\nDeploy runtime security tools to detect anomalous behavior inside containers including process execution, file system modifications, and network connections.\n\n```bash\n# Deploy Falco for runtime threat detection\nhelm repo add falcosecurity https:\u002F\u002Ffalcosecurity.github.io\u002Fcharts\nhelm install falco falcosecurity\u002Ffalco \\\n  --namespace falco-system --create-namespace \\\n  --set falcosidekick.enabled=true \\\n  --set falcosidekick.config.slack.webhookurl=\"https:\u002F\u002Fhooks.slack.com\u002Fservices\u002Fxxx\"\n\n# Run kube-bench for CIS Kubernetes Benchmark assessment\nkubectl apply -f https:\u002F\u002Fraw.githubusercontent.com\u002Faquasecurity\u002Fkube-bench\u002Fmain\u002Fjob-eks.yaml\nkubectl logs -l app=kube-bench\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| Pod Security Standards | Three profiles (Privileged, Baseline, Restricted) enforced via Pod Security Admission that control pod security context capabilities |\n| Workload Identity | Cloud-native mechanism binding Kubernetes service accounts to cloud IAM roles for credential-free cloud API access (IRSA, GKE WI, AKS MI) |\n| Network Policy | Kubernetes resource defining allowed ingress and egress traffic flows between pods, enforced by the CNI plugin |\n| Admission Controller | Kubernetes plugin that intercepts API requests before persistence to validate or mutate resources against security policies |\n| RBAC | Role-Based Access Control in Kubernetes, defining what actions (verbs) identities can perform on which resources in which namespaces |\n| Seccomp Profile | Linux kernel feature restricting the system calls a container process can make, reducing the kernel attack surface |\n| Service Mesh | Infrastructure layer (Istio, Linkerd) providing mutual TLS, traffic policies, and observability for service-to-service communication |\n\n## Tools & Systems\n\n- **Falco**: Open-source runtime security engine detecting anomalous behavior in containers using kernel-level system call monitoring\n- **Kyverno**: Kubernetes-native policy engine for admission control, mutation, and generation of resources based on security policies\n- **kube-bench**: CIS Kubernetes Benchmark assessment tool checking cluster configuration against security best practices\n- **Trivy**: Vulnerability scanner for container images, file systems, and Kubernetes resources with SBOM generation\n- **Calico\u002FCilium**: CNI plugins providing network policy enforcement and advanced network security features including eBPF-based monitoring\n\n## Common Scenarios\n\n### Scenario: Cryptominer Deployed via Compromised Container Image\n\n**Context**: GuardDuty Extended Threat Detection generates an AttackSequence:EKS\u002FCompromisedCluster finding. A developer pulled a public Docker image containing an embedded XMRig cryptominer that executes at container startup.\n\n**Approach**:\n1. Isolate the affected pod by applying a deny-all network policy targeting its labels\n2. Capture the container image digest and scan it with Trivy to identify the embedded binary\n3. Review Kubernetes audit logs to identify who deployed the compromised image and when\n4. Deploy Kyverno ClusterPolicy requiring images from approved private registries only\n5. Enable image digest pinning to prevent tag mutation attacks\n6. Deploy Falco with rules detecting crypto mining process signatures (\u002Fusr\u002Fbin\u002Fxmrig, stratum+tcp connections)\n\n**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.\n\n## Output Format\n\n```\nKubernetes Security Assessment Report\n=======================================\nCluster: production-cluster (EKS 1.29)\nProvider: AWS (us-east-1)\nAssessment Date: 2025-02-23\nTool: kube-bench v0.8.0 + manual review\n\nCIS KUBERNETES BENCHMARK RESULTS:\n  Total Controls: 124\n  Passed: 98 (79%)\n  Failed: 18 (15%)\n  Warnings: 8 (6%)\n\nCRITICAL FINDINGS:\n  [K8S-001] 3 namespaces lack Pod Security Standards enforcement\n    Namespaces: monitoring, logging, default\n    Remediation: Apply restricted PSA labels\n\n  [K8S-002] Default service account tokens auto-mounted in 12 deployments\n    Risk: Credential theft if container is compromised\n    Remediation: Set automountServiceAccountToken: false\n\n  [K8S-003] No network policies in production namespace\n    Risk: Unrestricted lateral movement between all pods\n    Remediation: Deploy default-deny policy with explicit allow rules\n\nHIGH FINDINGS:\n  [K8S-004] 5 pods running as root with privileged security context\n  [K8S-005] Images deployed using mutable tags (:latest) in 8 deployments\n  [K8S-006] RBAC ClusterRoleBinding grants cluster-admin to developers group\n```\n",{"name":5,"tags":55,"author":58,"domain":49,"license":15,"version":59,"nist_csf":60,"subdomain":33,"description":65,"mitre_attack":66},[56,39,37,38,34,57],"kubernetes-security","container-runtime","mahipal","1.0.0",[61,62,63,64],"PR.IR-01","ID.AM-08","GV.SC-06","DE.CM-01","Hardens managed Kubernetes clusters on EKS, AKS, and GKE by implementing Pod Security Standards, network policies, workload identity (IRSA for EKS, Workload Identity for GKE, Managed Identities for AKS), RBAC scoping, image admission controls, and runtime security monitoring. Use when deploying a new managed Kubernetes cluster with security requirements or hardening an existing EKS, AKS, or GKE cluster after an audit or pentest finding.\n",[67,68,69,70,71],"T1078.004","T1530","T1537","T1580","T1610","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fsecuring-kubernetes-on-cloud",4395,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":83,"prompt":93,"zipAvailable":94},[84,87,90],{"tool":85,"command":86},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill securing-kubernetes-on-cloud",{"tool":88,"command":89},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill securing-kubernetes-on-cloud",{"tool":91,"command":92},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill securing-kubernetes-on-cloud","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-kubernetes-on-cloud\u002FSKILL.md",true,[96,101,107],{"path":97,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-kubernetes-on-cloud\u002FLICENSE",{"path":102,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fapi-reference.md","REFERENCE","参考文档",2273,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-kubernetes-on-cloud\u002Freferences\u002Fapi-reference.md",{"path":108,"resourceType":109,"resourceTypeDesc":110,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Fagent.py","SCRIPT","脚本",8705,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecuring-kubernetes-on-cloud\u002Fscripts\u002Fagent.py",[114,138,162,189,215,242],{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":121,"publishedAt":50},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[120],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[122,123,124,125,41,49,126,48,45,127,128,129,130,131,132,133,134,135,136,137],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":50},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[144],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[146,134,147,148,41,149,49,45,150,151,152,153,154,155,156,157,158,159,160,161],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":172,"publishedAt":50},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[168,171],{"categoryNo":169,"categoryName":170,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[156,173,174,175,176,49,177,178,150,179,180,181,182,183,184,36,185,186,187,188],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":196,"publishedAt":50},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[195],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[197,198,199,49,200,201,202,203,204,205,206,207,208,209,210,211,153,212,213,214],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":222,"publishedAt":50},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[221],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[223,224,225,49,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":243,"name":244,"nameZh":6,"description":245,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":246,"categories":247,"keywords":249,"publishedAt":50},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[248],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[41,250,49,251,252,253,254,255,256,257,258,36,259,185,260,261,262,263,264,265],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]