Lack of resources is a massive blocker, so you'll need to prioritise
Containers are a fantastic way for DevOps teams to break their toolchains down into a series of microservices, making it easy to swap a particular product out of the pipeline without needing to entirely rebuild it from scratch. Kubernetes is one of the most popular container platforms, but protecting a Kubernetes environment can be a daunting prospect.
Rory McCune of Aqua Security spoke about getting started with Kubernetes security at Computing's recent Deskflix: DevSecOps event, where he attempted to answer the question, 'What's the one thing I could do to try and improve my Kubernetes security?'
The first thing to think about, said McCune, is the available resources. Of course, in an ideal world you would have everything you need, with multiple teams to handle any issues. In reality, many IT leaders lack full-time employees who can focus exclusively on Kubernetes security. So where should you assign this limited resource?
"You talk to security people and you'll hear them say, 'You should do all these things, otherwise you're not going to be secure.' That's not the real world. The real world is we all have day jobs and many of them are not in security, so we need to try and work out where to apply our security."
When it comes to assigning priorities, McCune advised thinking about your threat model, or, 'Who's going to attack me and how?' He names three main threat models to consider:
- External attackers. There are increasingly more of these, acting faster; some vulnerable honeypots Aqua Security left exposed as research on the open internet were compromised within 50 minutes.
- Compromised containers. You could have as many as a thousand applications on a single cluster, so there is a real threat if just one is compromised. This threat model might not apply to every cluster, but could be a serious risk.
- Compromised credentials. As ever, attackers can use compromised credentials to access your network.
In addition to the threat model, you need to think about the attack surface. There's an obvious example when it comes to Kubernetes: network ports. "The main services run by Kubernetes all have a network port, so that's part of the attack surface," said McCune. But there are also non-obvious parts; for example, if you have a lot of containers running they are part of the attack surface, as you can assume an attacker will get access to one of them.
So: who, how and where are people going to attack?
This is only a summary of the first part of McCune's talk, which is a must-watch for anyone with a Kubernetes environment.