[FEATURE REQUEST] Nested / Wildcard path for database roles

[ispyinternet]

I have an automated workflow, and it would like to use the Database Provider to create roles that it can then issue tokens against.

Currently when you set up the database config, you specify the roles, e.g...

vault write database/config/mysql ..... allowed_roles='dev1,live,test'

This is limited in that the roles need to be known in advance. In my use case I need to create roles later on that would use the same user/connection, but have different grants for dynamic data setup later, e.g. databases.

I see two possible solutions that would would enable such a use case:

Option A)

Wildcard roles and nested role paths:

vault write database/config/mysql ..... allowed_roles='dev/*
...
vault write database/roles/dev/role1 db_name=mysql
vault write database/roles/dev/role2 db_name=mysql

Option B)

A command / endpoint to amend the allowed roles post the config being created.

I like Option A.

Would you be interested in supporting this? If yes, is there somebody who could implement it?

Thanks, and fingers crossed! :)

[Xopherus]

I don't like option A - I think option B is more consistent with the Vault API in how you can "tune" mounts. In this case option B would allow you to "tune" a database connection after it has already been created. I'm very surprised that the new database backend did not include this capability from the start.

It seems like the old, deprecated backends (the MySQL secret backend for example) forced you to create the database connection first, then create roles. Each time a role was created it was automatically added to the connection. With the new database secret backend, this forces you to create the roles first and then create the connection with allowed_roles. Having the ability to tune an existing connection is a much cleaner workflow when you want to add roles to an existing connection.

[jefferai]

In this case option B would allow you to "tune" a database connection after it has already been created. I'm very surprised that the new database backend did not include this capability from the start.

@Xopherus What exactly is it you think is missing? You can update the connection information at any time you please, including allowed_roles, via a simple vault write.

It seems like the old, deprecated backends (the MySQL secret backend for example) forced you to create the database connection first, then create roles.

They didn't; you could use whatever order you pleased and update either at any time.

With the new database secret backend, this forces you to create the roles first and then create the connection with allowed_roles

It doesn't; you can update both roles and connection information at any time you want.

My understanding of the OP's ask is that he wants more flexibility for globbing than simply setting allowed_roles to *, which is already supported. It would be easy to implement for an interested party; we already support globbing elsewhere through a library.

[jefferai]

Note: I forgot in my last comment there that there is already a PR to do what we assume is the OP's ask, at #3387

[Xopherus]

@jefferai the biggest hurdle I see is that connection_url is always required for that vault write - if you wish to change other connection parameters (e.g., allowed_roles, max_connections_open, etc) you have to specify that url, even if you change it or not. this presents a problem for my team because we codify our mount/policy/role configurations in code, so we can't put connection_url there for obvious reasons.

Also fwiw, I don't think globbing is necessarily a bad idea - it's probably good to prepend your roles with tags if you want certain roles to be assigned to certain connections. But if you don't know that from the start, or if your roles evolve over time, globbing won't really help you - assuming that you use a similar setup to provision your vault cluster.

[jefferai]

connection_url is always required for that vault write - if you wish to change other connection parameters (e.g., allowed_roles, max_connections_open, etc) you have to specify that url, even if you change it or not.

This could be changed. It just needs to be brought to our attention as a use case, which has not happened before.

[Xopherus]

Would you like a separate issue opened for further discussion @jefferai? I'd be happy to try and explain further.

[jefferai]

It's not an issue of not understanding, it's that nobody has requested it before, hence it was neither in our design goals nor implemented afterwards to this point.

Please open a new issue, as this one has been completed.