We are currently building a feature for Matillion ETL to support integration with secret managers to allow the use of secrets within credentials for components and environments. We will be supporting the configuration of secret managers per project group, the same as the existing password manager as the concepts are closely coupled.
Some of the early feedback suggested that setting up a secret manager should be an “administrator only” capability. Since there is currently no concept of a “project group administrator”, we wanted to know which, if any, of the existing roles in Matillion ETL would be appropriate to control access to the feature, i.e.:
Server admin
Global project admin
Project admin (though this may mean the user can set a secret manager for other projects in the group for which they are not admin)
One of our primary use case is in the the scope of centralized company data team (IT), the team wants to leverage Azure Key Vault for all our pipelines in Matillion, the Matillion environment is managed/used only by our Data Engineers, the team has Server admin rights and familiar with Azure services, hence can do this configuration work. So in short only Server admin is required for first use case, you might want to do "least privilege" in your design, but please keep it simple.
Another self-service use case(where KV is not applicable with current functionality) where IT team creates separate Matillion instance for business users, and separate them by projects. I think it is business user's responsibility to manage their secrets using security manager, where IT data team should not be involved in operation, it will be simply to expensive o keep IT data team in the loop to register everything in KV and operate on this model. You could however consider a "Azure KV backed Matillion security manager" so that the secrets are synced centrally in KV. Please look for databricks azure KV backed secrets for inspiration.
Since our Data Engineers are the only ones that have access to Matillion, and would have access to specific Secrets in the AWS Secrets Manager, our scenario is quite easy. Any role works for us since we manage access separately.