I need feedback about the DbUser resource

[allanger]

I'm currently working on the new api version for DbInstances and I have thought that the DbUser resource doesn't really make a lot of sense. I've got a feeling that it's almost always used to simple provide permissions to existing users, so people which accounts are not manager by the operator can access the databases managed by the operator.

I've decided that I would like to deprecate the DbUsers and instead move this logic to the DbInstance level. What I currently have in mind is adding following to the CRD:

# Naming might change in the future
kind: DbInstance
metadata:
  name: some-instance
spec:
  autoGrantRules:
    - namespace: my-application-prod
      role: devops
      accessLevel: readOnly
    - namespace: my-application-dev-*
      role: dev
      accessLevel: readOnly
    - namespace: my-application-dev-*
      role: devops
      accessLevel: readWrite

And then when a following database is created:

kind: Database
metadata:
  name: not-important
  namespace: my-application-prod

ReadOnly access is automatically added to the devops role.

And if database is created in the my-application-dev-pr-103 namespace, it will be ReadWrite for devops and ReadOnly for dev

Then no DbUser resource is needed, it will be possible to manager users via for example Workload Identity, and the operator will only assign.

@mruoss @a-dekker I hope you don't mind that I ping you directly. I think you are using the DbUser resource and I wanted to ask whether this approach would also work for you? And if not, could you please describe, what would be missing in that case?

Thanks

[a-dekker]

Thanks for the ping.
As database users are managed at an instance level, it makes sense to me.
Do the DbUser spec attributes like secretName, grantToAdmin and extraPrivileges also move to DbInstance?
And do the users defined at DbInstance level have access to specific databases based on the namespace?
As you might know we have an application-owner user and application-rw and application-ro user per databases/namespace.

[allanger]

It seems like my idea wouldn't work for you then. I wanted to spot managing users with it, and only do the grants.

Could you please describe how you use rw and ro users?

Are they needed for an app or for a human access?

If first, could you please describe, how the owner and rw are different? Would it not be enough to have read-only and owner users? I thought that I could add automated eead only user creation to the db resource

If second, how do you distribute secrets? Do people with manual access just go to k8s to get creds? And would it not be more convenient to move the user management part out of operator (user creation and credentials handling) and let the operator only grant permissions to dbs?

[a-dekker]

The ro and rw users are meant for users who need to access the database. The authentication is rds-iam based.
The owner user is the owner of all related database objects. The rw-user can modify data and sequences, but cannot create or drop tables etc. So it more limited than the owner itself.

The password is stored as a k8s secret, but not really accessed/needed, because people using the rw and ro user authenticate themselves via rds-iam.

As we don't want to manage the users manually, it is very convenient we can define them via for example the db-operator. But who knows there are other solutions for that.

[allanger]

Just to be clear, I'm asking exactly to understand whether removing of the DbUser resource can hurt somebody, it's not a statement that I'm removing them.

So you actually need users, not the grants, and you need users per db. I guess DbUser really does make sense. Then I'll just add functionality to the DbInstance, but the DbUsers will stay as well

Thanks