Skip to main content

How Kubernetes and microservices can change thinking about security

(Image credit: Image Credit: B-lay)

Kubernetes has been one of the great tech success stories in the past few years.  Just a few years ago it was widely seen as a niche technology but there is a clear trend towards its adoption. According to a StackRox survey, 91 percent of IT professionals are implementing Kubernetes in some form, even if it’s not always part of the corporate system … yet.

There are some clear advantages in using Kubernetes – which we’ll come to later – but it should also be understood that not all is rosy. The biggest concern that users have about the technology is whether there has been adequate investment in security.

In some sense, this is understandable; the roll-out of Kubernetes has transformed corporate infrastructure, and, such is the nature of things, there is nearly always a lag between implementation of a new technology and the rollout of ancillary services such as security.

This is not a trivial issue: the StackRox report revealed that 44 percent of survey respondents had delayed a rollout because of security concerns, limiting one of the main advantages of Kubernetes – its agility to adapt to certain situations.

Consequently, there needs to be a transformation in the way that companies take security into account; considering it from the outset, not as something to be baked in later.

Fortunately, Kubernetes itself provides ways of doing this, so CIOs and CISOs do have a variety of options available. 

The microservices mindset

However, it is not something that is immediately straight-forward, it necessitates a complete change in mindset to adapt to this new way of working.

The whole concept of microservices is a radical departure from traditional software architecture. Instead of running an entire application as a single entity, it is split into many, much smaller, elements. What this means is that it is much simpler to identify and isolate security threats.

What makes Kubernetes particularly useful in this regard is that not only will it bring up another service to replace the one that has been destroyed, but it is possible to bring up a new service before the older one has been dealt with. This means that there is no interruption within the application and less possibility of downtime.

It does this by setting up what is called a declarative definition of deployment, where a company can state how they want services to perform and assign priorities to them – for those that are particularly important, then replicas are created, ready-made to drop in when there is an attack on the system.

By using declarative definitions it is also possible to change risk assigned to certain services depending on where they are running, so that a risky service running in the back end may be less of a problem than a less risky one in the front end. CISOs have much greater say in how risk is handled, again ensuring that systems are kept running.  It is also possible to not run particular elements: if a certain activity is not required for the application that you’re running, then it is possible to block it, reducing the area that’s liable to be attacked.

New approach to security

Adopting Kubernetes with microservices is a radical approach to adopt, but it’s one that could transform the way that security is being handled within organizations. As with many aspects of technology, it’s not the technical issues that are proving to be the barrier to innovation; cultural issues are much harder to overcome.

In some ways, this is easy to understand.  Most security professionals have been working in the area for twenty years – sometimes more – and their approach to security is a reactive one. The instinct is to build security measures – firewalls and endpoint protection, for example – so that they’re able to react to any event. It’s hard to change that philosophy; corporations don’t shift an entire approach in a matter of weeks.

But they really should be giving careful thought as to what’s possible. What Kubernetes provides them with is the means to be proactive, ensuring that there’s minimum downtime and that all systems are operating at maximum efficiency,

There is one other issue: while most enterprises have moved at least some of the corporate infrastructure to cloud, there are complications in adopting this route.

Don’t shift monoliths

What has been happening in too many instances is that companies opt for cloud without thinking through the full repercussions of the decision.  They lift and shift applications wholesale and think they’ve moved on because they’re now operating ‘in the cloud’, but all that’s happened is that a company has swapped from running a monolith on-premises to running that monolith in the cloud.  They’ve certainly not embraced Kubernetes by shifting such a block.

It’s easy to see why this happens as there’s certainly been a pressure to adopt cloud – it’s become the go-to philosophy. But it’s important to think about what this entails and what the ultimate aim is. By not changing the underlying architecture, an organization is storing up problems for the future.

There will be some companies who are always going to find a microservices, Kubernetes- based shift difficult. Large corporations with many decades of IT behind them will find such a move particularly problematic but that doesn’t apply to all.

Planning ahead

With the number of cyber-attacks proliferating almost weekly, it’s important to plan a system that’s resilient and that maintains the maximum possible uptime. There’s been too much focus on vulnerability management and not enough on risk management, identifying potential problems and dealing with them early.

The history of IT security has been a reactive one, it’s time to take a proactive approach and use the agility and granularity of Kubernetes to make a real difference. The ability to make decisions about where to deploy software and to manage risk more effectively could be a genuine game changer.

Richard Olver, Vice President of International, Stackrox