[Feature] Postgres cluster manifest in separate namespace than its child resources

[frittentheke]

Currently, at least as far as I understand the available configuration options, the postgres-operator will create the clusters or rather the related resources in the same namespace as the custom resource "postgresql" - https://github.com/zalando/postgres-operator/blob/master/pkg/cluster/cluster.go#L135

In order to allow folks to "request" a database, but to not have them access the actual pods, it would be nice to be able to configure a target namespace for the operator to create all those statefulsets, secrets and whatnot.

Provided there is some "external" authentication or db credentials are provided by something like Hashicorp Vault, there is actually "no need" to place the resources into the same namespace as i.e. the application in need of a database cluster.

Would you be open to add this feature or even accept a PR?

[FxKu]

I think, I'm not really getting your point. If the operator is configured to watch all namespaces, you can create database clusters in any namespace you want.

[frittentheke]

@FxKu the idea is to split the custom resource "postgresql" from the actual resources created by the operator. I would like to "allow" people to create a database cluster, but not actually have access to the resources (pods, secrets, ...) this creates. Kind of like AWS RDS. The custom resource serves as the API to request a database cluster. An surely this happens in the users namespace. But then the operator then gets to work and creates the database in a namespace the user cannot access and they never get to "see" or even "exec" into the actual pods that is created to provide it. They can simply access the postgresql service via its service name.

[FxKu]

Coming back to this, I'm finally getting your idea. Would the namespace then be configurable in the Postgresql manifest? Does any other operator do this? Hm, feels odd to me. Finding stuff would be slightly more confusing.

In terms of user access, have you looked at the user-facing cluster roles?

[frittentheke]

@FxKu the idea was to have a single distinct namespace which is configured in the operator configuration - NOT to be changed or "selected" by anyone or per postgresql manifest.

As a result the only resource regarding the postgresql instances that the users would touch is the CR in the form of the postgresql manifest - also containing the status of their requested clusters. Apart from a security standpoint in regards to databases not to be "fiddled" with by users, this would also keep database resources (pods, services, ...) away (different namespace) from the application pods.

[cskarby]

I think I understand the use case, but it sounds odd to me to make the postgres-operator create pods in a different namespace. How would you ensure that the user that creates the postgresql manifest in one namespace is allowed spawn PODs (and use quota/resources) in the other namespace (especially when you say that they should not have access to the other namespace)?

For what it's worth I think that if you really need this you could create a meta operator, that uses a different CRD, so when your user creates a manifest for your operator, that operator could create the necessary manifests in the desired secondary namespace for the postgresql-operator to manage. Then you could also have custom logic that suits your needs, eg. from namespace project you could create a postgres instance in project-postgres etc. - Perhaps even the secondary namespace could be implicit and inferred from the name of the namespace where your operator is picking up the custom resource? Or created with a random name by your operator?

Or perhaps even easier - when you create namespace for your users, you could also create the secondary namespace upfront and provide desired RBAC-credentials, so that they can create/edit/delete the postgres manifests, but only view other resources in the secondary namespace.

[frittentheke]

I think I understand the use case, but it sounds odd to me to make the postgres-operator create pods in a different namespace. How would you ensure that the user that creates the postgresql manifest in one namespace is allowed spawn PODs (and use quota/resources) in the other namespace (especially when you say that they should not have access to the other namespace)?

@cskarby it's just the other way around ... Only the operator is required access to the namespace the PostgreSQL pods are created in. The idea is to allow users to create postgres CRs in their own namespace, but to have the resulting clusters be created "externally" from the users requesting it.
So the operator is actually requiring less access (as it does not create pods / services / ... in arbitrary namespaces, but rather in one i.e. called "databases".

Kinda like a managed database. You get access to some IP or hostname to reach the managed service, but you don't actually have access to the resource building blocks.