To Secure Kubernetes, Think Beyond Kubernetes

Kubernetes releases balance backwards compatibility with secure defaults. Kubernetes has a defined release cadence of three releases per year, and minor releases are supported with patches for about a year after their release, forcing organizations to stay up to date with Kubernetes versions. This approach means that backwards compatibility is critical — users must be able to upgrade quickly, and releases that break existing deployments are untenable. Therefore, security features that risk breaking backwards compatibility will be disabled upon upgrade, and security teams bear the responsibility of understanding and configuring new security features. Our research dives into how organizations embrace that cadence.

Your standard identity best practices apply to Kubernetes, too. The US National Security Agency and Cybersecurity and Infrastructure Security Agency jointly published Kubernetes Hardening Guidance. Written for US critical infrastructure organizations, its key points apply to all Kubernetes users: Run containers and pods with the least possible privileges; block unneeded network traffic; ratchet up authentication and authorization; and scan and log everything feasible. Our interviewees explain how they do it.

Namespaces have become the common approach to isolate applications. Kubernetes namespaces were designed to be a mechanism for isolating most Kubernetes resources such as pods, services, and replication controllers within a single cluster. We found that Kubernetes users consider namespaces as fundamental to Kubernetes security, not only to separate teams but also to isolate applications and tie user and service accounts to identity. Users show us how they went off the script to innovate.

The open source community actively promotes Kubernetes security tools. Organizations have built a robust ecosystem of open source projects to address the different layers of Kubernetes security. In some cases, the Cloud Native Computing Foundation (CNCF) incubates these projects — as it did for Kubernetes itself — and in other cases, security vendors manage the projects, often with the free open source version serving as a gateway to premium paid products. Our interviewees draw on the CNCF community brain trust to secure cloud-native infrastructure.