Kubernetes security under the spotlightIf 2017 was the year of container experimentation, 2018 has seen containers begin to be deployed. Even ignoring the overhyped numbers from vendors, the scale of container deployment cannot be ignored. This is despite the fact that a lot of companies are still unsure of how to use containers effectively. They are not sure if they are simply an alternative to virtual machines (VMs) or a way of deploying micro-services.

What is certain is that for the technology to succeed, security needs to be dealt with now, before the size and quantity of deployments gets too large. Since May, there have been a number of security announcements. Some, for example by Google, have seen new tools and solutions delivered to help improve security. Others, such as CVE-2018-1002105 have revealed critical security gaps in Kubernetes.

With the Kubernetes (KubeCon) and Cloud Native Computing Foundation (CNCF) conferences taking place in Seattle this week, it was the right time to hold the first KubeSec conference. Although the name of the conference implies it is just about securing Kubernetes, it chose to address the wider container security problem as well.

Secure by design or just more same old, same old?

Secure by design is somewhat of a tired mantra. It has been doing the rounds for well over a decade yet the quality of software, at least from a security perspective, seems no better. Microsoft even held up the delivery of an operating system to go back and address fundamental ways of dealing with security earlier. The problem with secure by design is that it never gets considered early enough in the lifecycle of technology.

In some ways this is true of containers. Four years ago the conversation was about controlled deployment. Today it is about multi-cloud and deploy at scale. The security model that worked four years ago will not work today. Importantly, this was a key element from several speakers at KubeSec.

One of the shifts is to move away from getting developers to deal with security and instead making it part of the frameworks. This is a smart solution. It allows an organisation to set a secure baseline that is suitable for all projects. If a project needs greater security, then it can be added in during the development process. To all intents and purposes this is secure by design.

This approach also takes into account the breadth of different security models that organisations run. That doesn’t mean security has to be weak but implementing very high security across all projects creates an impossible bar for developers. For containers and the low-code, no-code environments, it also means that developing and deploying code becomes incredibly difficult. End user assembly of components to create new software cannot happen if security is pushed out to the developers. Secure frameworks appear to offer a great solution all round.

Do the basic security hygiene

This sounds obvious and most people might think that they have a good level of basic security hygiene. Experience, however, shows that is not the case. Like many cloud technologies, Kubernetes is about configuration not customisation. That means that it is just as easy to create default settings that are bad as it is defaults that are secure. Organisations need to make sure they use best practices.

Delegates were shown tools such as Kube-bench. This takes the best practice as designed by the Centre for Internet Security and delivers an automated checker. The output will show what passes, what fails and what could be improved. For security teams and developers, this is a good start point to improve overall security of their Kubernetes deployments.

There were other steps that companies can take.

  • Do not run as root or superuser: The fact that in late 2018 we are still saying this shows how poor basic security is. Running as root makes it easy to create privilege escalation and break out of one container into others using the same kernel.
  • Container image management: Use master images that are immutable. Ensure that nobody can inject code and that the images are scanned for vulnerabilities. They should also be signed so that any attempts to change or substitute a hacked image can be quickly spotted.
  • Sandboxes: VMs and containers should take advantage of sandboxing. This makes it easier for security teams to contain any attack. It also reduces the risk of a wider attack should a container be breached.
  • Visibility: You cannot fix something unless you know it is broken. Greater visibility is not just about using logs and technology to spot anomalies, it is about having expected behaviours mapped so that the unexpected is obvious.

Enterprise Times: What does this mean

Over the last 35 years we have seen multiple new technologies come to market. Most of them deliver benefits to the business. They also bring their own security issues that are often not addressed until the technology is in widescale adoption. KubeSec is an attempt to change this. It shows that the open source community who have chosen Kubernetes as their technology for deployment and orchestration, are looking to address security now, not wait for problems.

This is a good sign and it will be interesting to see how quickly this develops. There are currently very few specialist container security companies out there. As container deployment increases over the next few years this will change. Many will bring their existing tools to the container market but they will be late and trying to retrofit. The community doesn’t want that.

The message from KubeSec was give us security options now. Those end-users and vendors who stood on stage are doing that. Let’s see how widely and how quickly it is adopted.

1 COMMENT

LEAVE A REPLY

Please enter your comment!
Please enter your name here