Kubernetes is the de facto standard for deploying and managing application workloads and containers. Lee has written quite a bit about the power of Kubernetes as an innovation platform, but while development and architecture teams are bullish on Kubernetes, security teams can find themselves scrambling to secure Kubernetes environments as they hurtle toward production.

The chief challenge in securing Kubernetes is that it’s not just about securing the Kubernetes infrastructure but about securing all the pieces that touch that infrastructure. That includes addressing identity, network security, and container security as part of your Kubernetes security plan. The good news is that security pros can adapt their existing control frameworks and Zero Trust approach to secure Kubernetes environments. In fact, our interviews found that organizations are highly creative in using open source to harden Kubernetes infrastructure in ways beyond what those projects provide or what vendors give them out of the box.

Here are just a few things to think about as you develop your Kubernetes security strategy:

  • 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.

For a full view into the challenges of securing Kubernetes, technical and nontechnical best practices, and the Kubernetes security ecosystem, check out our report, Best Practices: Kubernetes Security. To start building your own Kubernetes security strategy, the Kubernetes Security Controls Checklist will help you clarify how you plan to address issues such as identity, container security, and network security. Finally, join us for a webinar on July 21 to get a deeper dive into this research. And as always, if you have any questions, please set up an inquiry.