CIOs wish for simpler ways to wrangle data and experiment with business models – but change remains hard to scale. Also, it may be time to stop chasing “alignment.”
Kubernetes security: 5 mistakes to avoid
For teams managing containers, Kubernetes has strong security controls – but some common mistakes pop up, especially when teams rush into production
4. Leaving the Kubernetes API server vulnerable
We could have included this under #3, but it deserves its own spotlight: If you don’t properly control access to the Kubernetes API, you’re leaving yourself wide open to attack.
“The most common and risky mistake is not using authentication for access to the API server since that is the main administration entry point to your cluster,” Jerbi says. “This also applies to anything that connects to the API server, like the K8s console UI.”
Buntel from Threat Stack also notes that configuring clusters with an authentication token that provides access to the Kubernetes API by default is a high-risk – and avoidable – mistake.
“People miss this all the time,” Buntel says. “And if that token has cluster admin rights, an attacker could easily escalate privileges and take over the entire cluster just by accessing this single container.”
5. Not taking a holistic approach to container security
Paying attention to Kubernetes security is smart. Doing so at the expense of the bigger picture around Kubernetes is not.
That means you need to integrate security into your entire container lifecycle, notes Buntel.
“Don’t confuse ephemeral with secure,” Buntel says. “Many people assume that containers are inherently more secure because they are ephemeral. However, the ease of spinning up new containers automatically can backfire if your automated configuration includes security vulnerabilities.”
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.
“Even if you secured your cluster following best practices, that doesn’t mean that the applications you run on K8s are also secured,” Jerbi says. “They may still be vulnerable due to vulnerabilities in the code or bad setup of privileges, [such as] container images configured to run with root privileges.”
[ Kubernetes terminology, demystified: Get our Kubernetes glossary cheat sheet for IT and business leaders. ]