A now-classic 2014 study by IBM concluded that an astonishing 95 percent of all digital security breaches it investigated were either caused, or contributed to, by human error – presumably including those of the software developers. The remaining few were largely the results of technical faux pas. Subsequent disclosures about breaches and attacks have cited the same finding – with all kinds of digital tools, it’s easy for people to make mistakes. Often the root cause is granting privileges to assets where access should have been denied.

Kubernetes is no different from any other digital infrastructure in this respect. Cloud-native software, just as with software deployed through legacy data centres, require administrators and end users to identify and prevent misconfigurations such as unwittingly granting elevated privileges to the wrong people or programs. How privileges are granted in Kubernetes, often via role-based access control settings, can mistakenly allow full cluster administrative permissions, even when it’s unneeded and unwanted.

The power of Kubernetes to enable automated and large-scale infrastructure operations also means it can be a path to abusing permissions and attacking containers and applications. It includes many built-in security features, but they are not enabled by default, since the mission of Kubernetes is to enable rapid application development and rollout. During the build phase, Kubernetes controls can get in the way of fast development. However, once an application is deployed and made available to all users, such lax security configurations quickly multiply the risk, since so many more users and assets are now involved. 

Achieving security for cloud-native workloads using containers requires a different approach than security strategies that were created for legacy infrastructure systems. Traditional security tools simply don’t work with Kubernetes. And as cloud-native adoption has matured, so too has the market around container security, which has fostered two distinct approaches to security: those that are container-centric, and those that are Kubernetes-centric or Kubernetes-native.

Security approaches that operate at the container level are focused on securing container images and runtimes. Their controls use techniques such as inline proxies and shims to control cross-container communications. They are effective at a certain scale. The Kubernetes-native solutions, however, leverage the inherent flexibility and scalability of Kubernetes itself. They operate at the Kubernetes layer, advancing policies that Kubernetes itself then enforces. These solutions are based on the principle that security is implemented most effectively when it’s closely aligned with the system that manages containers and their applications and data – in other words, make Kubernetes the control plane not just for infrastructure but also for security. And as a result, enable security that’s built in, not bolted on.

So what, exactly, are the characteristics that make a security platform “Kubernetes-native?”  It is a combination both of how they work and what they do. For example, they need to directly integrate with the Kubernetes API server for first-hand visibility into workloads and infrastructure. They need to assess vulnerabilities in Kubernetes itself. They must base their security functions on resources within Kubernetes object models, including deployments, namespaces, services and pods. And they need to leverage Kubernetes’ own built-in security features. As far as what it does – the security features it delivers – the nature of a deep integration with Kubernetes helps cover a full range of use cases enabling comprehensive visibility into all Kubernetes environments as well as vulnerability management, network segmentation, configuration management, compliance, threat detection, and incident response. 

If you’re working in containers, why are Kubernetes-native security platforms considered superior?  They provide three distinct advantages:

• Kubernetes-native security provides increased protection through richer insights and more effective discovery, both in Kubernetes itself and within the containers it orchestrates. They leverage all the declarative data of Kubernetes to inform visibility and contextualise risk
• They provide greater operational efficiency, enabling faster threat detection and prioritised risk assessments. Your teams work faster, and troubleshoot issues faster, because they’re speaking a common language and looking at the same source of truth about what’s happening in infrastructure and in security
• They reduce operational risk because using Kubernetes’ native controls means security matches the adaptability and scalability of Kubernetes. In addition, there’s no room for conflict between external controls and the orchestrator

The native security capabilities of Kubernetes are one of the best lines of defense in protecting your container ecosystems. Successfully operationalising those capabilities so that your DevOps, security, and infrastructure teams can harness their full potential requires the added control and visibility enabled through a Kubernetes-native approach to security. Given we’ll always have error-prone humans in the mix, the ability to continuously identify and stop threats at the Kubernetes layer is critical to protecting your cloud-native applications. 

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.