Kubernetes Security Best Practices to Protect Your Cloud Containers

Lightweight cloud containers are fast replacing resource-sucking virtual machines, and Kubernetes is fast becoming the de facto standard for container orchestration. Kubernetes adoption doubled in 2018. Unfortunately, as with any popular technology, it was only a matter of time before hackers discovered a way to exploit it. Late last year, the first major Kubernetes security hole was discovered in the form of a serious privilege-escalation flaw.

Kubernetes is not inherently insecure, but it also isn’t secure by default, even if it is hosted by, managed by, and running on one of the Big Three cloud service providers, and even if that cloud provider is Google (which developed Kubernetes before releasing it as open source). Remember, cloud services operate on a shared responsibility model. Your CSP is responsible for security of the cloud, and your organization is responsible for security in it. Usually, attacks occur because of mistakes in the latter. Tesla fell victim to a cryptojacking malware attack on its AWS environment that was traced back to a Kubernetes console with no password protection. Once inside, hackers were able to steal access credentials for Tesla’s entire AWS server.

Here are some best practices for Kubernetes security that will help you keep a lid on your cloud containers.

Run the latest version and keep it patched

The only realistic fix for the Kubernetes security privilege escalation flaw was to update Kubernetes. Patches for the latest version are released every quarter, and they often include important security fixes, so make sure you keep up with them.

Know your Kubernetes clusters

As workloads increase and more clusters are deployed to handle them, cluster sprawl sets in, and ignoring this problem won’t make it go away. You cannot secure what you don’t know exists, so take advantage of the discovery tools offered by your CSP.

Use role-based access control(RBAC)

Use RBAC to control user access and permissions on your Kubernetes API, and always use the principle of least access; give employees as much access as they need to perform their jobs, and no more. Use namespace-specific permissions instead of cluster-wide permissions. Instead of giving users cluster admin privileges, grant temporary admin access only as needed.

RBAC is enabled by default in Kubernetes 1.6+, but check to make sure, especially if you upgraded from an earlier version of Kubernetes. Your old configuration may have carried over.

Seek outside help with Kubernetes security and compliance

Securing the cloud is different than securing an on-prem environment, and securing containers is different than securing a non-container system. Even though Kubernetes removes some of the headaches of cloud container management, container environments are still complex, dynamic and have a lot of moving parts. Container security is difficult, especially since new threats and vulnerabilities emerge every day. Organizations must also ensure that their configurations and security controls adhere to applicable compliance requirements. For example, some compliance standards require certain highly sensitive workloads to be isolated in a different machine or hosted on-prem.

Very few companies have the in-house resources to manage their own cybersecurity and compliance. It’s best to partner with a reputable cybersecurity firm with expertise in securing and ensuring compliance in container environments.