Temporary Access to MySQL with Sym

Jon Bass
October 13, 2022

Sym now supports temporary MySQL access using a newtemplate in our examplesrepo! We released an example back inMay for setting up temporary Postgresaccess with Sym, and have had many requests for a MySQL example to complementit. Our new example also takes a different approach to user management than ourPostgres example. Insteadof granting or removing access to an existing database user, our MySQL examplegenerates temporary users and shares them in AWS Secrets Manager.

We're going to walk through how the basic integration works, and then highlight howwe're leveraging AWS Secrets Manager to securely deliver the temporarycredentials.

Sym's Lambda Strategy

Sym uses AWS Lambdas deployed into customer accounts to integrate with customer systems that are not on the publicinternet. No need for firewall rules, you just need to give Sym'slambda-connector permission toinvoke your Lambda function. Your function then needs VPC access to theservice that you want to integrate with.

Sym invokes your function with a payload that includes all themetadata youcould want in order to act on an escalation or de-escalation request. Thisincludes the requesting user, the approver, the target that the user wantsaccess to, and any other form fields you've included in your Flow modal.

Sym also can handle receiving data back from a Lambda function. You can use thisdata in the Sym SDK to message users, making routing decisions, or trigger otherSDK integrations.

Creating Temporary Users

Our example makes it easy to configure what permissions to grant to temporaryusers once they're created. For each SymTarget that you configure in yourFlow, the Lambda implementation will look for a corresponding SQL file in thetargets directory. The Lambda will execute this file, supplying the generatedusername of the temporary user.

Here's the Sym Target configuration we include in our example:

And here's the SQL file we provide that corresponds to the readonly target:

Using Tag Conditions to Access Secrets

To ensure users can only access their own secrets, we'll use IAM TagConditions to limit access to secrets tagged with the current user's aws:userid. Policy variables like aws:userid can be confusing, especially since they vary depending on the type of AWSUser that is currently active.

The aws:username value is only present when the current user is an IAM user.If you're using federation (such as with Okta or AWS IAM Identity Center), thenyou need to use the aws:userid value. The aws:userid value hasmultiple components: a role-id (which is not particularly useful for us) and a namewhich should identify the user that is making the request.

With an IAM Identity Center session, the aws:userid looks something like thefollowing where the UserID contains a role-id, then a colon, and finally a username:

Now that we know the format of aws:userid, we can build an IAM PolicyCondition that tests for it. We will test if a given secret has a sym.user tagvalue that matches the part of the aws:userid that comes after the role-id,using a wildcard like this: "*:${secretsmanager:ResourceTag/sym.user}":

Our MySQL Lambda tags generated secrets with sym.user, and includes a managed policythat you can use to set up the aws:userid tag condition. This will work in most cases where the username that comes in from Sym matches the username in your aws:userid. If they don't match thenlet us know, we can help!

Helping Users Access Their Secrets

Our example will DM the requesting user with the info they need to request their secret:

Once the user knows the secret name, they can use the AWS CLI to request it:

How to Use the Sym SDK to DM Users

How this works under the covers is that the Sym SDK can work with response data from your Lambda implementation. Using the secret_name that we get from the Lambda, we then use Sym's Slack SDK to message the user:

Next Steps

We'll be providing an updated Postgres implementation that also generates temporary users. We're also interested in how we can help teams more seamlessly integrate access to generated secrets into their workflows, perhaps with CLI extensions. And finally we'll be looking at alternate spots to share generated passwords, like 1Password.

Please let us know if you have questions on this example and/or want to try it out!

Recommended Posts