What do you think about inserting the cache between dbauthz and the real database? We pass db.Store around a lot, and I don't want people to call the low-level config queries and bypass the authorization.

@spikecurtis I looked into that awhile back when doing the dbauthz layer. The downside is the interface for db store is massive. So in this case, I'd have to stub out 349 of the 352 functions, since the cache only cares about the functions related to runtime config settings.

The other issue is the runtime config is using a single query to interact with all config settings. Just GetRuntimeConfig(ctx context.Context, key string) (string, error). The dbauthz (at least today), does not know what the setting is, aside from the key.

This is instead of making a different set of CRUD queries for each settings. So the RBAC needs to be defined by the caller somehow. Or dbauthz needs to inspect the key and determine the rbac requirements.