Modern applications and infrastructure no doubt require modern security practices, but the fundamentals still apply.
“The majority of data breaches are easily preventable with basic cybersecurity hygiene,” says Tim Buntel, VP of application security at Threat Stack.
That should be received as good news: Fundamental issues such as access and privilege remain fundamental, even as containers, microservices, orchestration, and other evolutionary developments continue to shake up IT. In fact, one of the biggest out-of-the-gate risks that can occur as organizations adopt new technologies is that they develop amnesia around best practices like enforcing the principle of least privilege.
Consider the rise of Kubernetes in the enterprise: Like any tool or technology, it comes with security considerations. That’s not because Kubernetes is inherently risky or insecure – far from it. Rather, many of the risks occur because teams get caught up in the power and popularity of Kubernetes without properly considering what it will take to effectively run it in production, says Matt Wilson, chief information security advisor at BTB Security.
“The most important step in avoiding Kubernetes security mistakes is to apply to Kubernetes, or any new-to-you technology, the same foundational controls you would expect in an IT environment ten-plus years ago,” Wilson says. “Yes, Kubernetes and its ilk are a dramatically different way to develop and deploy applications, which can be game-changers in many organizations. However, patching, hardening, security monitoring, along with the law of least privilege, go a long way in reducing information security risk.”
[ Want to help others understand Kubernetes? Check out our related articles, How to explain Kubernetes in plain English and How to explain Kubernetes Operators in plain English. ]
Of course, Kubernetes comes with some specific considerations when it comes to security. With that in mind, we asked Wilson, Buntel, and other security pros to share the missteps they see teams commonly make when they begin using Kubernetes to manage their containerized applications. Here are five to guard against:
1. Moving Kubernetes into production too quickly
There can be significant differences between running Kubernetes in a dev/test environment and running it in production – including security. Some teams will learn this the hard way; smart teams will plan properly to minimize issues when they move into production.
“Newer individuals and organizations looking to leverage the power of Kubernetes can easily gloss over important configuration and hardening details,” Wilson says. “The biggest risks are rooted in the lethal combination of overconfidence, ignorance, and pressing deadlines that push organizations to adopt a new technology then rapidly move through – or worse, skip! – thorough testing. Unsurprising results follow.”
Furthermore, as Red Hat technology evangelist Gordon Haff notes, Kubernetes can serve as the basis for a highly automated infrastructure platform that can underpin effective DevSecOps. But you first need the right policies, processes, and test coverage. Otherwise, watch out: “Automation is just going to give you false confidence and help you make mistakes more quickly and consistently,” Haff says.
IT leaders have a key role to play in avoiding this mistake. Don’t push teams to move into production before they’re ready for prime-time.
2. Assuming you’re secured by default with Kubernetes
Kubernetes has many robust security controls. That dupes some people into thinking that they’re secure by default. We’ll let Amir Jerbi CTO and co-founder at Aqua Security, clarify: “You’re not.”
Jerbi notes this is particularly true if you’re running your own version of the open source Kubernetes project instead of a commercial or managed platform.
Wei Lien Dang, VP of product at StackRox, says this is the most common misunderstanding that he encounters among teams beginning to use Kubernetes in production environments: Because the Kubernetes community has shown a strong commitment to security, and because the orchestrator itself has lots of security-oriented features, some organizations overestimate their posture out of the box.
“Those native capabilities get discussed a lot, so people assume Kubernetes has a lot of security,” Dang says. “The mistake, however, is in assuming those native controls are configured by default – they’re not.”
[ Related read: 6 Kubernetes security questions, answered. ]
3. Improperly configuring (or ignoring) native Kubernetes features
This naturally means that you’ve got some configuration work to do – and that’s the next significant source of potential missteps.
“It’s easy to misconfigure settings – for example, incorrectly setting role-based access controls (RBACs) that allow too much or even too little access,” says Gary Duan, CTO and co-founder at NeuVector. “This causes potential security holes or deployment issues when apps try to communicate.”
RBAC is a powerful security tool that helps enable teams to enforce least-privilege policies, for example. But Jerbi quickly reminds us of #2 above: It’s not going to be configured by default.
“The intent here is to limit what users, including admins, can do on the cluster, and enforce segregation of duties (SoD),” Jerbi says.
Dang notes that Kubernetes settings generally allow for broad permissions for development and other purposes. But that means Kubernetes administrators sometimes grant roles and privileges that are too broad in production.
“For example, the default setting for network policies is to leave deployments open to all traffic, so every resource can talk to every other resource,” Dang says. “This open setup vastly increases the blast radius – the range of territory an attacker can reach.”
Dang offers another example of a potentially risky default configuration: “Workloads are deployed into the default namespace, which means those workloads are not isolated from each other even though the mechanism of namespaces allows for such isolation – again, unnecessarily increasing the blast radius.”
In general, networking in Kubernetes can come with a significant learning curve, which in turn makes it fertile terrain for security mistakes – one reason why some security experts recommend a zero trust approach.
“There’s often very little understanding of how Kubernetes networking works under the hood, and security teams don’t realize that they should be demanding the same level of segmentation and firewalling that exists today in non-container environments,” Duan says.
