aws-secrets-manager-rotation-lambdas icon indicating copy to clipboard operation
aws-secrets-manager-rotation-lambdas copied to clipboard

MySql MultiUser RDS credential rotation causes problematic permission grants

Open cpr-chas opened this issue 2 years ago • 1 comments

Commit edd300ad2c33152e39d4c00fda6d777dbf1834ca ("Supports MySQL/Maria grants containing percent symbols.") added a replacement of '%' with '%%' because '%' is an escape character for python format strings. I don't know if something changed in the libraries used or if this is only necessary in certain situations, but it causes problems with the permission grants in the simplest case. This is the specific line that appears to be the problem: new_grant_escaped = new_grant.replace('%','%%') # % is a special character in Python format strings.

We are using this in a lambda with Python 3.7. We started with a user 'myuser', with a grant: GRANT SELECT, INSERT, UPDATE, DELETE, LOCK TABLES, EXECUTE, SHOW VIEW ON %.* TO 'myuser'@'%'

Each time the key rotation is run, we end up with a grant doubling the wildcard as the grant gets copied back and forth between the base account and the clone account. EG: GRANT SELECT, INSERT, UPDATE, DELETE, LOCK TABLES, EXECUTE, SHOW VIEW ON %%.* TO 'myuser_clone'@'%'

After several automatic rotations, we're up to 64 on the main account and 128 on the clone: GRANT SELECT, INSERT, UPDATE, DELETE, LOCK TABLES, EXECUTE, SHOW VIEW ON %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%.* TO 'myuser'@'%' GRANT SELECT, INSERT, UPDATE, DELETE, LOCK TABLES, EXECUTE, SHOW VIEW ON %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%.* TO 'myuser_clone'@'%'

I expect at some point we'll run up against a character limit and rotation will fail.

I can change the lambda locally, but if we ever take a further update from the template, that might get lost. Additionally, I expect other customers are likely to run into this problem if they restrict permissions in this way.

As a workaround, I can grant the privileges separately to each schema in the DB, but that's a little bit painful and error prone if we ever add an additional schema.

cpr-chas avatar Jun 14 '22 13:06 cpr-chas

Thanks for reaching out with the request. We are looking into it.

goyalya avatar Oct 06 '22 19:10 goyalya