Kubernetes is by default insecure, and with hundreds of API objects to configure across pods, services, ingress, and RBAC, misconfiguration is almost inevitable without automation. Jim Bugwadia, Co-founder and CEO of Nirmata and co-creator of Kyverno (the CNCF policy engine for Kubernetes), explains how policy as code solves the fundamental challenge of securing complex distributed systems. As co-chair of the Kubernetes Policy and Multitenancy working groups, Jim brings a unique perspective from telecommunications network management where policy-based management has been standard practice for decades.
You can read the complete transcript of the episode here >
How does the shared responsibility model apply to Kubernetes?
In managed Kubernetes (EKS, GKE, AKS), the cloud provider manages the control plane: API server, scheduler, etcd database, and core controllers. Everything above that is the user’s responsibility:
- Worker nodes: Configuration, security, and scaling
- Workloads: Pod security contexts, resource quotas, and deployment configurations
- Networking: Ingress controllers, service mesh, and network policies
- Identity: RBAC roles, service accounts, and access controls
The critical point: Kubernetes is insecure by default. Even with a managed service, the customer must actively configure security. The defaults are not secure, and the shared responsibility model means the cloud provider will not do this for you.
Why does Kubernetes have so much configuration and how does policy solve it?
Kubernetes uses a declarative API where you specify desired state and the system figures out how to achieve it. Because it is a platform for building platforms, it exposes configuration for developers, operations, and security teams simultaneously. A single workload might require a dozen or more objects to be configured correctly.
This is why 70% of Kubernetes issues stem from misconfigurations. The solution is policy as code:
- Security teams define policies for pod security contexts (no privilege escalation, no host namespace access)
- Operations teams define policies for CA certificate injection, resource quotas, and monitoring
- Developers manage their application images and configurations
- Policies overlay on each other so the final deployed workload meets all organizational requirements
Policy engines like Kyverno act as admission controllers, validating and mutating configurations before they reach the cluster. This approach mirrors how telecommunications networks have operated for decades: small teams managing global infrastructure through policy-based management rather than manual configuration.
What are the essential Kubernetes security best practices?
Jim outlines a layered approach to Kubernetes security:
- Pod Security Standards: Every Kubernetes version publishes these. Set Pod Security Admission to “restricted” or at minimum “baseline.” Never leave it at “privileged” (allow all).
- Resource quotas and limits: Without these, one workload can consume all cluster resources, enabling denial-of-service attacks.
- Image scanning: Scan container images for vulnerabilities before deployment.
- Ingress controller CVEs: Keep ingress controllers patched and prevent script execution that could lead to container escapes.
- Service mesh security: If running a service mesh, it adds another layer that must be secured.
- Infrastructure as Code controllers: If using tools like Crossplane to provision cloud resources (S3 buckets, databases), those configurations need policy enforcement too.
For self-hosted Kubernetes, all of the above applies plus CIS benchmarks for control plane configuration. Every component (API server, scheduler, etcd) has recommended settings that must be explicitly configured and verified.
How should organizations secure their software supply chain in Kubernetes?
Attackers have figured out that CI systems are often easier targets than production. That Jenkins server in someone’s data center may not have been patched in months. Jim outlines the modern approach to supply chain security:
- Sign images at build time: Use a private key or keyless signing through Sigstore, which integrates with OIDC for machine identities.
- Attach signed attestations: Record where the image was built, which script built it, which branch, who invoked the build, and whether code reviews were completed.
- Verify at admission: Use admission controllers (like Kyverno) to check signatures, provenance, and attestations before allowing images into the cluster.
- Periodic re-scanning: New CVEs emerge after deployment. Run continuous scans against deployed images and flag new vulnerabilities.
- SBOMs as attestations: Attach Software Bills of Materials as signed attestations for deeper supply chain visibility.
The Sigstore keyless signing approach is particularly powerful: it uses machine identities from the build system, eliminating the need to manage signing keys while still providing cryptographic proof of image provenance. This connects to broader supply chain, container security, and SBOM practices in the cloud native ecosystem.
How do developers, security, and operations collaborate on Kubernetes security?
The challenge: three different roles need to manage parts of the same configuration object. A pod has security contexts (security team), mount points for CA certificates (operations), and application images (developers). Without coordination, configurations conflict or get overridden.
Policy as code solves this by allowing each team to define their concerns independently:
- Security policies: Enforce security context settings, prevent privileged containers, restrict host access
- Operations policies: Inject sidecar containers, configure monitoring, manage certificates
- Developer policies: Validate image sources, enforce naming conventions, require labels
These policies compose together through the admission control pipeline. The result is a deployed workload that satisfies all organizational requirements without any single team needing to understand every configuration detail. This is the practical implementation of DevSecOps in Kubernetes at scale.
Why should security be part of platform engineering, not a separate function?
Jim’s background in telecommunications, where security was always part of the operations management plane, makes the separation of security into its own team seem strange. Cloud native is moving back toward that integrated model:
- Everything as code: Infrastructure as code, policy as code, security as code, compliance as code. All managed through the same workflows: code reviews, automated testing, release processes.
- Platform engineering owns security: Security is a Day Zero concern, not an afterthought delegated to a separate team running audits later.
- Kubernetes enables this: Its declarative API and admission control architecture make it possible to embed security checks directly into the deployment pipeline.
The principle: delegating security to a separate team sitting in an ivory tower does not work. The industry moved from separate teams to DevOps to DevSecOps to platform engineering precisely because integration produces better outcomes than separation. Security policies managed as code, reviewed like code, and deployed like code is the path forward for Kubernetes security in ephemeral environments.
