Container adoption is on a meteoric rise. Gartner estimates that 50 percent of companies will use container technology by 2020, up from less than 20 percent in 2017. It’s not hard to see why — containers’ offer greater DevOps flexibility along with an optimized build/deployment pipeline.
The surge in container adoption is the driving force behind a new phenomenon in developer circles that we at Threat Stack lovingly refer to as “Kubernetes FOMO.” Eager to get on board with the most popular orchestration platform around, organizations are jumping on the Kubernetes bandwagon.
And why not? Kubernetes speeds container deployment and enables the management of multi-container clusters at scale. It allows for continuous integration and delivery; handles networking, service discovery, and storage; and has the ability to do all that in multi-cloud environments.
Some would call Kubernetes a silver bullet in the world of container deployment and management, but that doesn’t mean it comes without security concerns. In this post, we’ll discuss a few things to watch out for if you’re considering a move to Kubernetes, as well as some tips on ensuring that your infrastructure remains secure during a transition.
Configuration Errors
We already know that configuration errors abound in the cloud: Our recent study found that 73% of companies have at least one critical AWS security misconfiguration. With containers being a relatively new technology in software deployment, the risk of misconfigurations due to inexperience is only multiplied. And many organizations adopt container orchestration platforms like Kubernetes before they truly understand the technology. Their inexperience leaves them particularly vulnerable to making configuration errors as they deploy.
As with most software today, containers work with secrets that you don’t want hardcoded, including service passwords and API keys. Third-party tools such as Docker secrets and HashiCorp Vault are able to encrypt such sensitive information, but many Kubernetes users will rely on Kubernetes’ own mechanism to perform this function. There’s nothing wrong with this, except that any configuration errors could leave your private information perilously exposed. Kubernetes has detailed documentation that you’ll need to review carefully and follow carefully to avoid such mistakes.
Another common configuration error seen when deploying Kubernetes is that, by default, many clusters are configured where an authentication token automatically provides access to the Kubernetes API. Configuring role-based access controls (RBAC) can help mitigate the risks, but if that token has cluster admin rights, an attacker who accesses a single container can easily escalate these privileges to take over the entire cluster. This brings us to the next issue…
Blast Radius
One of the attack scenarios that has garnered the most attention in Kubernetes-controlled environments is the idea of blast radius. Just as the blast radius of a nuclear bomb refers to the distance from the source that will experience damage, the blast radius of Kubernetes-controlled deployments is how far a malicious party can gain access from the initial point of compromise..
This blast radius is increased often due to the fact that an attacker can escalate privileges to take control of other containers in a cluster once a container is compromised. Therefore, any secure deployment of Kubernetes will put a heavy focus on the necessity of minimizing blast radius.
Past attacks have shown us that certain components of a cluster may be more vulnerable than others. Hackers can identify an unprotected Kubernetes’ backend database (etcd) relatively easily, for example, by searching on web crawlers such as Shodan. And, according to Kubernetes security documentation, “Write access to the etcd backend for the API is equivalent to gaining root on the entire cluster, and read access can be used to escalate fairly quickly.” Very scary!
Kubernetes does have built-in controls regulating container access, which can help limit the impact of compromised containers. This isolation is further strengthened by leveraging Kubernetes’ isolation mechanisms like namespaces and network segmentation. It is also advisable to limit the number of containers that can run in a privileged mode. After all, a compromised privileged container would cause a much greater degree of damage than a compromised normal container.
Securing Infrastructure in Transition
Besides following the Kubernetes security documentation closely, the best way to ensure a secure Kubernetes deployment is to build security into your deployment as early as possible. (Actually, that’s the advice we give when undertaking any type of infrastructure transition!) Securing your environment proactively through proper configuration is much simpler and less expensive than trying to respond to a data breach after it occurs. And, leveraging advanced SecOps practices through proactive monitoring provides you with the visibility you need to protect your increasingly serverless environment.
Think you’re ready to make the move to Kubernetes? Take our Cloud SecOps Maturity Assessment to see where your organization’s security maturity stands and get off on the right foot with your infrastructure transformation.
