Cloud native security: A maturing and expanding arena

At the recent KubeCon + CloudNativeCon North America 2020, I had the opportunity to take part in a keynote panel with a number of other cloud native security practitioners. We got questions on a wide range of cloud native security topics and through those and other talks at the conference, I’ve been able to identify some key concerns around container security and the wider cloud native ecosystem.

It’s not just Kubernetes

The Kubernetes project understandably gets a lot of focus – it’s a key part of most companies’ cloud native strategies – but if you look at real-world deployments, you’ll see a host of supporting tools, from package managers and container image repositories to tools to help scaling. The cloud native landscape shows an infamously complex picture of the number of options available.

From a security perspective this is very important point: It’s not only Kubernetes security you need to consider when deploying cloud native technologies, but also the security of the surrounding tools. That’s why, when looking at a deployment, it’s worth asking what else is in the mix, and how those components handle security concerns.

And in addition to the supporting products, with every containerized deployment it’s also important to consider all the layers that make up a Kubernetes cluster. Besides Kubernetes itself, there will always be a container runtime (like Docker) and usually an underlying node operating system (mostly Linux). In sum, it’s not enough to just look at the security of Kubernetes itself—Docker security hardening, container image vulnerability management and operating system security are all still concerns.

Secure defaults matter

A lot of cloud native tooling is relatively complex, with a large number of configuration options. As a result, for good reasons and bad, many companies will start from the default settings. In fact, looking at the default posture of projects and their security should be an important part of the decision-making processes when deploying cloud native solutions.

There is external help available: as part of its graduation process, the Cloud Native Computing Foundation (CNCF) requires a complete and independent security review. Going through these reviews can help companies determine whether the project’s approach to security matches their own requirements.

Detection and response

Along with the usual array of preventative controls that are deployed as part of a cloud native platform, companies need to focus on detection and response to breaches. It’s important to note that the usual toolsets that are put in place will need to be supplemented by cloud native tools that can provide targeted visibility into container-based workflows.

Projects like Falco, which can integrate with container workloads at a low level, are an important part of this. Additionally, companies should make sure to properly use the facilities that Kubernetes provides. For example, Kubernetes audit logging is rarely enabled by default, but it’s an important control for any production cluster.

Getting it right from the start

A key takeaway for container security deployments is the importance of getting security controls in place before workloads are placed into production. Ensuring that developers are making use of Kubernetes features like Security Contexts to harden their deployments will make the deployment of mandatory controls much easier.

Also ensuring that a “least privilege” initial approach is taken to network traffic in a cluster can help avoid the “hard shell, soft inside” approach to security that allows attackers to easily expand their access after an initial compromise has occurred.

Keeping up with developments

One constant of the cloud native world, which was reinforced at KubeCon, is that there are always new products and services on the horizon, and all of them need to be considered from a security perspective. This year, one of the themes of the cloud native landscape has been the rise of operators and using Kubernetes as a control plane for other services like databases instead of only to manage containers. Expanding the scope of services run by Kubernetes means that the impact of any security misconfiguration may be more widely felt across the IT environment.

This places more emphasis on the Kubernetes RBAC system, and requires ensuring that both users and services with access to it are working on a least-privilege basis. All too often, software installed on a cluster will request “cluster-admin” access, which provides blanket access to every resource managed by the Kubernetes API.

Bringing it all together

It’s clear from the continued success of containerization and cloud native computing that they’re going to be a long-lasting trend in the IT world, and while there are many new buzzwords to absorb, a lot of the security controls that need to be deployed are essentially the same as for more traditional environments. However, care needs to be taken to ensure that our existing security environments are updated to account for differences in how the cloud native world operates.