Threat Modelling requirement T19: Restrict Application's Access to Database requires the following: "Restrict access to tables and schemas that are needed.  Restrict access to actions that are needed (such as select, update, and delete)."  As part of the discussion of this vulnerability for Nova, smooney@redhat.com specs out a feature of the mariadb-operator:

nova can use different accounts for executing nova-manage to modify db schemas vs at runtime for the nova services
those two different accounts could have restereded actions sets (i.e. the runtime account could have the ability to execute alter table commands removed) this is an installer functionality to implement and not something that requires codechange/support in nova.

this is a generic functionality in the deployment tool to configure the restricted account and then specify those account in the nova config file instead of a more privileged account.

This issue is raised to provide exactly such functionality.  Specifically, for each component create two accounts:

• The ${component} account has standard CRUD access to that component's database
• The ${component}-operator account has permissions to change schema as well as CRUD.

Providing the ability to have MariaDB accounts the operator would use for administrative functions like DB migrations would permit scoping the regular account used for component operational access down to the minimal access needed to function.  Once this change has been made, the operators would need to be adjusted to use the new privileged account and access reduced for the unprivileged component account.