Hey everyone! I'm part of the ops team that's managing a few Kubernetes clusters. The development team has requested permission to install and handle the CloudNativePG operator in a specific namespace for deploying PostgreSQL in their development area. However, creating a cluster role for managing the Custom Resource Definitions (CRDs) goes against our company's policy. I'm wondering if there are other ways we can allow the developers to manage the CloudNativePG operator themselves while adhering to the principle of least privilege?
5 Answers
Consider using tools like Kyverno or OPA to establish restrictions on which namespaces they can deploy to. This way, you maintain control while still giving them a degree of autonomy.
From my perspective, managing the CloudNativePG operator is your responsibility. The dev team should receive just enough permissions to create and manage CloudNativePG clusters in their namespaces, without needing access to anything else.
Honestly, it's not really the development team's role to manage the operator; that falls under the ops team. Their focus should be on utilizing it, not operating it.
You don’t necessarily have to use the service account and cluster role specified in the CloudNativePG Helm chart. Instead, create a new service account with tailored permissions and assign it to the pod instead.
One option could be to set up a separate, pseudo cluster just for the developers. This way, they would have ownership without risking any impact on the real cluster. At a previous company, we implemented vCluster to create virtual Kubernetes clusters for development teams. It allows them to install CRDs and operators freely while we handle the main cluster's management.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures