k8s-security-baseline

Audits managed Kubernetes clusters against CIS benchmark checks and GPU-specific risks.

Updated Jul 16, 2026
One-click install
npx skills add https://github.com/Cloud-Byte-Consulting/plugins --skill k8s-security-baseline-cloud-byte-consulting
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: k8s-security-baseline
Source: https://github.com/Cloud-Byte-Consulting/plugins/tree/main/gpu-research-platform/skills/k8s-security-baseline
Command: npx skills add https://github.com/Cloud-Byte-Consulting/plugins --skill k8s-security-baseline-cloud-byte-consulting

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security audits of managed Kubernetes clusters often produce generic hardening advice that ignores the shared-responsibility split and misses GPU-specific risks like privileged device-plugin DaemonSets and NVIDIA container toolkit CVEs. This Skill produces an evidence-backed findings table where every check is either executed with a command or explicitly assigned to the provider. ## Core Features & Use Cases - Shared-responsibility scoping: Filters out provider-owned CIS sections 1-3 (control plane, etcd) and generates written attestation questions for the provider, treating unanswered items as open findings. - Customer-side CIS section 5 checklist: Executes RBAC minimization, Pod Security Standards labels, default-deny NetworkPolicies, secrets handling, and admission control checks with concrete kubectl commands. - GPU-specific risk audit: Covers privileged NVIDIA DaemonSet containment, container toolkit CVE inventory, untrusted ML images on shared GPU nodes, hostPath mounts, and JupyterHub attack surface. - Use Case: A platform team running a multi-tenant GPU research cluster on Lambda needs a quarterly security posture review; the Skill runs the checklist, captures command output as evidence, and delivers a severity-ranked findings table with a top-5 burn-down list. ## Quick Start Use the k8s-security-baseline skill to run a CIS security audit of my managed Kubernetes cluster and produce a findings table with severity and remediation.

Frequently Asked Questions about k8s-security-baseline

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a CIS benchmark audit on a managed Kubernetes cluster?

Run the customer-side CIS section 5 checklist covering RBAC, Pod Security Standards, NetworkPolicies, secrets, and admission control using kubectl commands. Provider-owned sections 1-3 (control plane, etcd) are excluded from scoring and handled through written attestation requests to the provider.

How to check who has cluster-admin access in Kubernetes?

List cluster role bindings with kubectl get clusterrolebindings and review every subject bound to cluster-admin. Rebind non-essential subjects to lesser roles, but never modify system:-prefixed bindings since cluster components depend on them.

What GPU-specific security risks exist on shared Kubernetes clusters?

Key risks include privileged NVIDIA device-plugin DaemonSets, container toolkit CVEs like CVE-2024-0132 enabling container escape, untrusted community ML images on shared GPU nodes, hostPath dataset mounts, and JupyterHub pods executing arbitrary user code. Contain privileged GPU components in dedicated namespaces while enforcing baseline PSS on tenant namespaces.

Does CIS benchmark apply to managed Kubernetes like Lambda or EKS?

Yes, but only partially. Sections 1-3 covering the control plane and etcd belong to the provider and should be marked N/A-provider rather than scored as passes. The customer owns section 5 policies and shares section 4 worker node checks depending on who manages node images.

How do I roll out Pod Security Standards without breaking workloads?

Label namespaces with warn and audit modes first, watch violations for about a week, then flip to enforce. Never enable enforce cluster-wide in one step, since that would evict legitimately privileged components like the GPU operator.

Why do default-deny NetworkPolicies break cluster workloads?

Default-deny policies without explicit allow rules block DNS resolution, ingress controller traffic, and Prometheus scraping. Ship deny rules together with narrow allows for DNS, object storage, registries, and telemetry as a single change.