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.
Kubernetes does not mean you can skip foundational controls.
“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.”
Further on in the piece, Casey references the ten-layer approach to container security:
Red Hat security strategist Kirsten Newcomer advises a ten-layer approach to container security. This includes both the container stack layers (such as the container host and registries) and container lifecycle issues (such as API management). You can learn more from Newcomer about the ten layers of container security in this podcast or this whitepaper.
Focusing too narrowly on a single area – such as Kubernetes and orchestration – is likely to increase risks elsewhere. Don’t conflate the security of your cluster with the security of, say, your application code.
Head over to The Enterprisers Project to read the full article.
Introduction Wouldn’t it be nice if your developers could be kept within the boundaries of a secure, signed image management process? That’s what image registries are for, naturally, and working with ...