Providing Least Privilege Access for AWS Aurora Postgres Database with ChatOps

Muhammed Said Kaya
Picus Security Engineering
4 min readMay 15, 2023

For Security Concerns/Reasons and to prevent potential errors, access to databases that operate in a Production environment should not be granted to anyone except database administrators.

Photo by <a href=”https://unsplash.com/ja/@jdent?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Jason Dent</a> on <a href=”https://unsplash.com/photos/3wPJxh-piRw?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>
Photo by Jason Dent on Unsplash

Here are some of the most common scenarios that could be encountered:

  • A person who is not a database administrator may attempt to access the production database. This can cause data loss or data integrity issues.
  • If a user accidentally attempts to add, modify, or delete data from the production database, the data may become corrupted or lost. (DATABASE DROP / TRUNCATE TABLE)
  • A system with security vulnerabilities can allow malicious individuals to access the production database. This can result in sensitive data being exposed or a malicious attack being carried out.
  • Any changes or misconfigurations made to the production database server can cause the system to crash or result in data loss. Therefore, only experienced and authorized database administrators should perform such operations.

If it is absolutely necessary to access the production database, for example in the event of an incident where there is a migration failure during the release of a product and there is an incompatibility between the DB and APP, and it is not possible to revert to a snapshot from the past in order to avoid data loss.

In such a scenario, the Developer/SRE/DBA who is on-call would need to perform manual operations on the database.

Developing a Platform that enables access to databases through Least Privilege Access is very important in order to manage such scenarios comfortably.

In this blog post, I will attempt to explain how we can design a platform using Slack and Amazon Web Services based on the architecture diagram shown below.

Database Access Platform with Slack APPs

The technologies used

  • Slack / API / Bot
  • AWS (Route53 / EC2 / Lambda / S3 / DynamoDB / Aurora / Eventbridge )
  • Docker

In today’s world, we can extend messaging tools like Teams/Slack/Discord to easily perform our operational tasks. In other words, we can perform ChatOps.

  1. Creating DB Roles
  • In our example, when any stakeholder writes a message “create-db-user” in the Slack app, Slack API automatically sends the text written in the payload to our containerized Go application served on AWS EC2 via an HTTP request
  • Once you receive the payload, you can do whatever you want with it. In our example, our bot serves as our platform. Our platform application calls a Lambda function named “create-db-user” for the database scenario.
  • In this Lambda function, we are fetching the necessary credentials for accessing the Database located in the S3 Bucket. Then, we connect to the Aurora Database and create a Role for the person who ran the Slack command. This Role is given for a certain duration and to keep track of it, we store information about the Role in DynamoDB. We send the necessary credentials for the Role to the stakeholder via Slack Private Message. Happy ending. Everyone is happy.

2. Removing DB Roles

Eventbridge is a powerful tool for scheduling and triggering events within our infrastructure. By using it to trigger a scheduled Lambda function every 5 minutes, we can check the DynamoDB table for expired items and delete the corresponding roles from Aurora. This ensures that we keep our access control clean and up-to-date, and avoid the accumulation of unnecessary roles over time.

By developing this platform with the components we added, we make sure that the stakeholders can create their own DB users while also ensuring Least Privilege Access. We achieve this by dynamically creating a Role with the least amount of privileges necessary for the user’s specific task and expiring it after a certain period of time. The stakeholder is not burdened with the responsibility of managing and securing database access, and they can focus on their own tasks with confidence.

Conclusion

As a result, If you want to provide the least privileged access to Production Database when you encounter an incident, you can easily create your Database Access Platform for Stakeholders by using Slack and AWS.

Thanks for reading. If you have questions or comments regarding this article, please feel free to leave a comment below.

Would like to get in touch? Reach me on LinkedIn:

https://www.linkedin.com/in/muhammedsaidkaya/

--

--