Kubernetes is highly ephemeral, and a static scan at a point in time can become outdated within seconds. Securing it requires continuous coverage across manifests, admission control, and runtime. Jimmy Mesta, Co-founder and CTO of KSOC, has spent 15 years in application and infrastructure security, working both offensive and defensive sides. Previously at Signal Sciences (acquired by Fastly), he led a team of researchers and engineers and contributed to the OWASP Kubernetes Top Ten. In this episode, he breaks down the shared responsibility model for managed Kubernetes, misconfiguration best practices, and why learning Kubernetes deeply matters more than any tool.
You can read the complete transcript of the episode here >
How does the shared responsibility model apply to managed Kubernetes?
The shared responsibility model applies to managed Kubernetes (EKS, AKS, GKE) just as it does to other cloud services, but with Kubernetes-specific nuances.
What the cloud provider manages:
- Control plane components (API server, scheduler, controller manager)
- etcd (the key-value store for cluster state)
- Underlying networking and hardware
- Physical security of data centers
What remains your responsibility:
- Workloads: The containers running in your pods and their security posture
- Secrets management: Choosing and correctly implementing secrets solutions
- Base images: Ensuring container images meet security standards
- RBAC: Configuring role-based access control with appropriate granularity
- Network configuration: Ensuring nodes are in the right VPC and the API server is not unnecessarily exposed to the internet
- Dashboards and logs: Enabling and using them properly
The misconception is that a managed EKS cluster is a hardened environment by default. It is not. The cloud provider gives you guardrails and operational simplicity, but the security of what runs inside the cluster is entirely on you.
What are the best practices for avoiding Kubernetes misconfigurations?
Because Kubernetes is highly ephemeral, a point-in-time scan is insufficient. Jimmy recommends checking for misconfigurations at three stages:
- Manifest analysis (CI/CD): Static analysis of YAML manifests before they touch a cluster. Catches low-hanging fruit early.
- Admission control: Before a workload is scheduled onto the cluster, validate it meets baseline security standards. This is your last gate before deployment.
- Runtime monitoring: After workloads are running, verify they behave as expected and remain configured correctly. Drift happens.
For what to check, three frameworks provide coverage:
- CIS Benchmarks: The de facto standard for common misconfigurations. Checks for running as root, mounting sensitive file systems, privileged pods, and more.
- NSA Hardening Guide: Guides operators toward running the most hardened cluster configuration possible.
- OWASP Kubernetes Top Ten: A practitioner’s high-level checklist of the ten most critical areas to address.
The critical advice: do not try to achieve 100% CIS compliance on day one. It is overwhelming and possibly not achievable in all environments. Start with misconfigurations your security team has identified as relevant to your threat model, understand the impact, and have a clear remediation path. This connects to how strategies for defending Kubernetes clusters should be prioritized based on actual risk.
How does self-hosted Kubernetes differ from managed offerings?
Self-hosting Kubernetes means signing up for significant operational and security overhead that managed services abstract away:
- Certificate authorities: You manage the PKI infrastructure for cluster communication
- etcd configuration: Multiple security-relevant flags that managed services handle for you
- Control plane hardening: API server, scheduler, and controller manager all need proper configuration
- Upgrade management: Safely performing version upgrades across all components
- Platform team requirement: You need dedicated engineers who understand Kubernetes internals deeply
The trade-offs:
| Managed | Self-Hosted | |
|---|---|---|
| Operational overhead | Lower | Significantly higher |
| Security configuration | Guardrails provided | Entirely your responsibility |
| Cost | Cloud provider pricing | Potentially lower infrastructure cost |
| Flexibility | Limited control plane access | Full configurability |
| Use cases | Standard workloads | IoT, air-gapped, specialized |
Jimmy’s recommendation: if possible, use managed Kubernetes. The security challenges of self-hosting are substantial, and most organizations underestimate the internal skill set required. Government entities and specialized use cases may justify self-hosting, but for most teams, the managed offering provides better security outcomes with less effort.
Why is learning Kubernetes more important than choosing tools?
Before recommending any tool, Jimmy recommends that teams learn Kubernetes deeply. The reasoning:
- Context is required: Open source scanning tools produce enormous output. Without understanding what the results mean and whether they apply to your environment, you are chasing noise.
- Tools are not programs: Running a CLI tool against one cluster does not constitute a security program. Enterprise environments with 50+ clusters across multiple regions need centralized posture management.
- Platform teams know more: Security teams that only talk to other security people miss the operational reality. Platform engineers deal with Kubernetes in ways that security teams never touch.
Practical learning recommendations:
- OWASP Kubernetes Top Ten: Designed as the entry point for learning, not just a checklist
- kubernetes.io documentation: Contains extensive RBAC best practices and security content
- Build and break clusters: Hands-on experience with creating, misconfiguring, and attacking clusters teaches more than any book
- Learn from platform engineers: They manage the biggest clusters and understand operational trade-offs that pure security practitioners miss
This philosophy aligns with the broader principle that Kubernetes security requires understanding the platform before layering tools on top.
How should organizations approach runtime security for containers?
The statistic that 70% of clusters use open source for container and runtime security does not surprise Jimmy. His assessment:
- Open source is fine for quick assessments: Tools like kube-bench or OPA Gatekeeper work well for individual cluster scans.
- Enterprise programs need more: Central management, vulnerability triage, cross-cluster visibility, and integration with existing security workflows require purpose-built platforms.
- Noise is the enemy: Without proper context and prioritization, scanning tools produce overwhelming output that teams cannot act on.
The recommendation is a threat-modeling approach rather than a checklist approach:
- Identify what you are protecting and from whom
- Determine which misconfigurations present real risk in your specific environment
- Build continuous monitoring rather than periodic scans
- Integrate findings into existing engineering workflows rather than creating separate security processes
For teams starting their container runtime security journey, the key is starting small with high-impact checks rather than trying to boil the ocean with every possible scan.
