Gartner estimates that 50 percent of companies will use container technology by 2020, up from less than 20 percent in 2017. The operational benefits of containers, including optimized build times and more efficient use of infrastructure resources, have caused a surge in interest in container orchestration platforms like Kubernetes. At the same time, Kubernetes deployments have opened up a whole new set of infrastructure security concerns for Development and Operations teams.
For teams just getting started with Kubernetes deployments, here’s an overview of three things you need to know about securing your infrastructure from the outset.
1. Make Liberal Use of RBAC
In many cases, there’s no better substitute for good security hygiene, especially when it comes to role-based access control (RBAC) in a Kubernetes environment. Ultimately, you want to apply the principle of least access: Provide access only to the areas of your infrastructure that people need in order to do their jobs. Too much access can lead to unwanted mistakes, even if the user has the best intentions.
It’s a good idea to set up RBAC boundaries between resources to ensure that your Kubernetes deployments remain secure. By default, many Kubernetes clusters are configured where a token provides access to the Kubernetes API, which mounts into each container. If this token has cluster admin rights, an attacker who gains access to a single container in the cluster can easily escalate these privileges to control the entire cluster.
Kubernetes provides fairly extensive documentation on configuring RBAC to dynamically set up and administer policies through the Kubernetes API. Each role contains rules that demonstrate a set of permissions, which are additive only. The RBAC API covers these key areas and more:
- Role: Defining a role within a namespace
- ClusterRole: Defines a role across a cluster, such as nodes, non-resource endpoints, and namespaced resources across all namespaces
- RoleBinding: Grants the permissions defined in a role to a user or set of users
- ClusterRoleBinding: Grants permissions across a cluster to a user or set of users
It’s imperative to plan carefully when setting up these Roles and binding them to users, especially when they are applied cluster wide. Improper Role set-up can lead to opening up undesired access to vital resources!
2. Proper Configuration is Gold
One of the biggest cloud security issues in general is misconfiguration. Last year, Threat Stack’s research found that as many as 73% of companies had at least one critical cloud security misconfiguration, potentially leaving systems open to the entire internet. Examples of misconfiguration of publicly accessible cloud assets are can be found almost daily!
The Kubernetes administrative console itself can serve as a massive front door for attacks, including cryptomining. If this API isn’t configured properly (for example, if it isn’t password protected), or credentials are easily crackable, attackers can hide behind DNS systems and perform malicious activities without detection. Rotating credentials or using credentials that expire based on the amount of time a user needs access are two ways to prevent hackers from getting into the administrative console.
The Kubernetes configuration best practices page provides a great overview of how to address top configuration issues, with associated documentation.
3. Protect Cluster Components
Certain components of a cluster may be more subject to attack than others. For example, hackers can identify unprotected Kubernetes’ backend database (etcd) relatively easily by searching on web crawlers such as Shodan. Kubernetes security documentation explains how rrite access to the etcd backend for the Kubernetes API is equivalent to gaining root on the entire cluster!
When it comes to further protecting databases like etcd, services like Hashicorp Vault have created specific documentation for introducing Vault tokens into a Kubernetes Pod, helping with the issue of secrets management for infrastructure components.
Securing an Infrastructure in Transition
As we’ve discussed in the past, even if you’re just making the transition to containers, it’s important to build security into your infrastructure as early as possible. The Threat Stack Cloud Security Platform® can help by providing insights to help you understand your attack surface. The Threat Stack agent sits inside the host server, providing visibility into your containers by integrating with the Docker API and understanding Kubernetes managed clusters. With solutions focused on both the host and on containers, Threat Stack allows you to see deep into hybrid environments.
If you’re wondering where to start in terms of cloud security, take our Cloud SecOps Maturity Assessment to get an insight into your organization’s current security maturity level.