I am planning to create a special 'deployer' deployment on k8s (one 'deployer' per cluster). It's role would be to pull specifications from a central place, create k8s manifests and apply them. The end result should be multiple deployments, each in it's own namespace with service and ingress, as well as a secret containing DB credentials.

I don't want to directly transmit and manage the DB details. Instead, I was thinking of creating a CustomResourceDefinition 'dbservice' that would contain a DB service name among the rest. Then configure a k8s operator that would:

1. Take (monitor) such a 'dbservice' resource.
2. Check with a DB hosting service if such a service exists already. If not it would create it with some specifications from the custom resource.
3. Get the hostname, password, user, database name and port, and store them in a secret that would be used by the deployment (envvar).

That way:

1. Each deployment would wait for it's DB secret and would not start until the secret exists, which means that the DB is ready.
2. I wouldn't have to manage DB services manually.
3. I wouldn't have to transmit passwords via wire.

What needs to happen for this to work (according to my plan):

1. The operator would need to have permissions to talk with the DB hosting provider (will probably access another k8s stored secret with the API key).
2. The operator would need to have permissions to create secrets in all namespaces.

Since I'm fairly new to k8s and devops in general, I wanted to verify that this approach is sane and not an anti-pattern.