Least Privilege Developer Access for Kubernetes Clusters¶
In our recent release in July, we enhanced our zero trust kubectl service to address the needs to two completely different cohorts of customers. At a high level, users of the Rafay Platform fall into two ends of the access spectrum when it comes to answering the following question.
Should developers be allowed to view Kubernetes Secrets?. Should they be allowed to exec into running containers/pods for troubleshooting purposes?
Background¶
Many users deploy and operate complex containerized applications on their Kubernetes clusters. Since developers are closest to the applications, the reality is that they will need to have at least read only access to the Kubernetes cluster so that they can troubleshoot their applications if and when required.
Many of our customers are organizations that have 10s or 100s of Kubernetes clusters org wide that support 1000s of developers. Given this scale, it is not practical for them to implement a manual process dealing cluster-by-cluster. Therefore, most of them resort to centralizing access and role assignments since this allows them to implement and enforce organizational policy for developers.
The Rafay platform is used extensively by 1000s of developers at our customers since it provides several tools that allow them to seamlessly debug and troubleshoot applications on remote clusters. Out of the large list of integrated capabilities, there are two features that "security" teams may wish to limit access to developers with read only roles.
Access to Kubernetes Secrets¶
Since Kubernetes secrets can contain sensitive data such as credentials, application secrets etc, organizational policy may require developers with "read only" roles to not be able to view/access Kubernetes secrets. When developers with a read only role attempt to view/access Kubernetes secrets on remote clusters, they will be blocked by default. The screenshot below shows the default experience for read only users.
Note
This default behavior can be overridden by Org Admins now.
Shell to a Running Container¶
The Rafay platform provides an Integrated Kubernetes Resources dashboard that is heavily used by developers. This also provides a one-click experience for developers to securely shell into a remote container. When developers with a read only role attempt to do this on remote clusters, they will be blocked by default. The animated gif below shows the default experience for read only users.
Least Privileges by Default¶
We are strong believers in the least privilege by default philosophy. The default behavior in the Rafay Kubernetes Operations Platform is for users with read only roles to not have access to Kubernetes secrets and not be able to shell into a running container on remote clusters. With this release, organizations have the option to fine tune the secure defaults and allow developers with read only roles to perform the following:
- View/Access Kubernetes Secrets OR/AND
- Shell into a Running Container.
Note
Users with an Org Admin role are authorized to update these settings.
What's Next?¶
Our customers have expressed to the Rafay Product Team that they would like the ability to customize this further. We are actively working to enhance this capability further in the coming months. We plan to write a follow up blog on this topic at that time with additional details. Our sincere thanks to our customers and readers for spending time reading our product blogs. Please Contact us if you would like us to write about other topics.