Combating Kubernetes — the Newest IAM Challenge

Since its release in 2014, Kubernetes has emerged as one of the most widely used open source systems for containers — and for good reason. The container management tool allows agencies to improve organizational efficiency, enable advanced security monitoring, and reduce costs.

Bad actors have also recognized the rich potential of Kubernetes, as it can provide complete access to organizational data to leverage for extortion or theft. As the platform becomes more popular, its array of endpoints — and potential vulnerabilities — expands.

Upon its introduction, Kubernetes was seen as a system that allowed for enhanced security measures. But in 2021, Siloscape malware emerged, targeting poorly configured Kubernetes clusters to plant backdoors that allowed criminals to steal data and user credentials.

As the first instance of an attack against a Kubernetes environment, organizations began expanding their cybersecurity resources, but were challenged by the thorough knowledge required to create and work within clusters. Every time a cluster is compromised, bad actors gain access to multiple cloud applications, including confidential files, usernames, and passwords.

Many organizations have deployed basic identity and access management (IAM) functionality to address these security gaps, but these solutions tend to provide master authorization and do not allow for effective access governance. 

In order to best secure Kubernetes environments, organizations need customizable IAM solutions to adjust for specific roles and access and, if needed, adjust the role once a cluster creation is completed. Customizable IAM for containers can ease the process of configuring, managing, and ensuring scalability of clusters.

Specified IAM Roles 

The first step organizations should take to secure Kubernetes clusters is to clearly define roles and permissions for each user. Creating more granular rules for individual cluster access can ensure one cluster doesn't provide access to the entire organization's data. A user with permission to edit the Kubernetes data set but unable to create and manage roles poses less of a threat than a user with full administrative permissions.

With defined roles in place, organizations can then specify authorization levels by establishing access rules for different types of users, as permission needs will vary based on the cluster. Users with power-user access can be granted similar authority to administrators without the ability to adjust settings and utilities, while other users can be limited to certain services within the cluster. These specific roles can then be mapped to Kubernetes role bindings for proper authorization.

While IAM is used to authenticate individuals, it still relies on the native Kubernetes role-based access controls (RBACs) for management, which may need to be adjusted. A cluster's creator will automatically be granted master permissions in its RBAC configuration, as a result granting limitless administrative permissions. To prevent bad actors from taking advantage of these permissions, security teams should only enable this role for cluster creation and delete it after the configuration map is defined.

Grant the Least Access Necessary

Since the IAM role initially established provides the user unlimited access to the respective cluster, organizations must be careful to remove these privileges once the task is completed. If a malicious actor gains access to these credentials, they will have complete control over that cluster.

Organizations should establish a creator role with the least access necessary to configure a cluster. Further, as stated above, since the role's only purpose is to set up the cluster, it should be deleted after the cluster is developed.

Additionally, IT leaders should grant the least level of privilege necessary when creating roles for each group of users. Maintenance of these privileges is also important. Administrators need to be vigilant about removing old users and making adjustments as roles change, considering automation for these updates where appropriate.

Kubernetes is still a relatively new system, and security features will continue to develop for the complex environment. While IAM plays an important role in its security, best practices must be carried over and adjusted for the unique features of a Kubernetes environment. 

By specifying each user's role, and limiting cluster access and management controls accordingly, IT leaders can ensure Kubernetes clusters don't become a gateway for cybercriminals to access their organizational data. While security methods will evolve as Kubernetes and its uses advance, correctly assigned roles will always provide a crucial layer of protection.