Provisioning of MySQL users

[estahn]

It would be great for the rotation function to create the user if it's not existing and grant the required permissions. This would act as an operator to sync secrets manager with MySQL users.

The secret would probably require to contain some further settings, e.g.

{
   "dbClusterIdentifier":"foboar",
   "engine":"mysql",
   "host":"myhost.ap-southeast-2.rds.amazonaws.com",
   "password":"foobarfoobarfoobar",
   "port":"3306",
   "username":"test-deleteme",
   "masterarn":"arn:aws:secretsmanager:ap-southeast-2:12345:secret:rds!cluster-0361984b970e",
   "rotate_cfg_user_host":"%",
   "rotate_cfg_grants":"SELECT, INSERT, UPDATE, DELETE ON `mydb`.*"
}

[ismaildasci]

Hey! 👋

That’s a great suggestion! Adding a feature to the rotation function that automatically creates the MySQL user (if it doesn’t exist) and grants the specified permissions would make managing users and permissions in Secrets Manager much easier.

With this approach, the rotation function would:

Check if the user exists. If not, create the user.
Apply the specified permissions from rotate_cfg_grants to the specified database(s).

Your suggested secret format is spot-on! The additional settings like rotate_cfg_user_host for user host and rotate_cfg_grants for permissions would give more control over user creation and access levels.

This feature would really help in syncing Secrets Manager with MySQL users dynamically. If this gets implemented, it would be a solid improvement for managing database credentials in a multi-environment setup.

Thanks for the idea! 😊

[simonmarty]

Opened #151 to investigate implementing this. There's some concerns we need to resolve internally before proceeding. For example, what happens when rotate_cfg_grants gets updated? Is the expectation that the new grant gets propagated to the associated role? This sounds like it might turn Secrets Manager into an identity provider for the associated SQL database, which isn't really something Secrets Manager was designed to do.

[estahn]

@simonmarty Thanks for looking into this.

I would looked at it of the lens of a Kubernetes Operator. Secret Manager contains the state (similar to a K8S Resource Definition) and a piece of software aka the operator (this Lambda code) sets the defined state in the target system (MySQL). MySQL would still handle the authentication hence I'm not sure if the comparison with an identity provider is valid.