Kubernetes is here to stay. The benefits the container-orchestration systems provide to cloud-native applications are incalculable. It has become the de facto standard for automating application deployment, scaling, and management. However as the ecosystem matures, several roadblocks have emerged on the way to a production-ready system. Several issues like high availability and monitoring have been addressed through upgrades to the core software, while others are still unsolved or have a half-baked solution.
When productionizing Kubernetes, one important security consideration to address is authorization. Not every user needs the capabilities to create, modify, and delete resources. Small teams can get away with assigning admin privileges but as the team or the reliance on Kubernetes grows, there is a need for a systematic and programmatic approach to authorization.
Kubernetes has a built-in framework for authorization. Role-Based Access Control ( RBAC) is a fairly simple framework that has been implemented very successfully in cloud environments. Broadly speaking, roles are assigned to users and each role defines what actions a user can take. Some of the default roles include cluster-admin, admin, edit, and view.
Description of Default Roles: Medium
There also exists the functionality to define custom roles detailing access to specific resources.
Detailed Explanation of Custom Roles: Logical Shift
However, though there exists the ability to handle authorization with granularity, as the number of users scale there are several practical challenges that emerge. The foremost is the manual configuration of roles. Kubernetes has no native tools for automatically updating or grating roles. When a new user joins the cluster, admins must manually bind the role for each user. If an existing role needs to be updated, a brand new role must be created to replace the old one. Even something as simple as revoking access requires an admin to manually delete the RoleBinding. Secondary issues like visibility into user access and visibility into cluster configuration ensure that the builtin RBAC framework is clunky to use at scale and in production.
One solution to the problem is to simplify RBAC through the use of Custom Roles and Service Accounts. This approach reduces manual effort by restricting users to a limited set of predefined roles. Instead of assigning a new role to each user, administrators can have sets of predefined permissions and assign a user to one of the existing roles. However, this approach has two major drawbacks. One, it doesn’t remove the configuration challenge. If there are a large set of roles or a need to create custom roles often, then this approach might not be suitable. Two, it doesn’t solve the problems surrounding visibility.
The second solution to managing complicated authorizations is by adopting third-party tools that allow admins to use role templates to automatically update and assign permissions to users. These third-party tools have additional benefits such as integrating with external identity providers, as well as solving core issues by providing a centralized control plane where admins can view user access and cluster configurations, and easily assign roles to users.
StrongDM provides zero trust access to Kubernetes.. It sits between the user and the cluster, providing a single gateway to manage and for access. When the user logs into the cluster, StrongDM leases credentials to the user based on the custom roles that the Admin has set up.
StrongDM Interaction: StrongDM Blog
In essence, StrongDM automates all the tedious work regarding role configuration and enables users to focus on more important things. Furthermore, StrongDM can work for other types of resources as well. SSH servers, databases, and other ephemeral infrastructure are all supported.
StrongDM Product Diagram: StrongDM Website
This approach enables admin to control access to all of their resources in a single centralized plane, eliminating the hassle of multiple authorization systems. This is especially useful in multi-cloud or hybrid cloud scenarios where significant time has to be invested in keeping distinct RBAC systems in sync and updated.
Managing access and authorization in today’s modern production environment is hard. Multiple cloud environments in combination with on-prem infrastructure with differing resource types ensure that maintaining disparate systems is a hair-pulling endeavor. Kubernetes clusters, databases, services, and web apps all have disparate systems that need to be synced and maintained. StrongDM is a proxy that manages and audits access. Admins can handle access through a central UI and developers can access those same resources without the need for a VPN or separate logins.
Sign up for a free, no B.S. demo of strongDM here.
The post Simplifying Access to Kubernetes appeared first on Software Engineering Daily.
* This article was originally published here
No comments: