Auditing IAM Authentication for RDS Aurora MySQL

Hello There,

I hope you are doing well.

I understand that you would like to know about ways to audit IAM Authentication for RDS Aurora MySQL.

Before I continue, let me provide a little overview on how IAM authentication works with Aurora MySQL.

1. A generate-db-auth-token API is called to generate a token.
2. IAM then verifies if the user/role has permissions to generate a token.
3. If the user/role has the required privileges the correct token is returned to the client
4. The token is then sent to the RDS instance using the database client of your choice by passing the token through the password field.
5. RDS then decodes the token and verifies that it is correct.
6. If the token is correct the user is authenticated into the database

-> Currently, there are significant limitations in auditing connections that use IAM Database Authentication. The core challenge lies in how the authentication process works. While the generate-db-auth-token command creates authentication tokens for database access, these tokens are generated locally and don't create any trackable AWS API calls.

-> The process works as follows: When using IAM authentication, you create a MySQL user with the rds_iam authentication grant. However, when connections are made, the database only sees this database user, without any visibility into which IAM user or role generated the authentication token. This creates a blind spot in auditing individual access.

-> The limitation extends to AWS CloudTrail as well. While CloudTrail typically records AWS API activities, it cannot track generate-db-auth-token operations because these occur entirely on the client side. The command generates a pre-signed URL using Signature Version 4 Signing Process locally, without any direct AWS service interaction. AWS services only become involved when this pre-signed URL is used to establish a database connection, at which point RDS validates the permissions associated with the token.

-> There is, however, one potential workaround: implementing a one-to-one mapping between database users and IAM roles. This means creating individual database users that correspond directly to specific IAM users or roles. With this approach, you can use database-level auditing to track activities and correlate them back to specific IAM entities. Without this mapping, when multiple IAM users share the same database user, it becomes impossible to distinguish which IAM user initiated specific connections or actions.

-> Setting up separate database users for each IAM user/role is currently the only way to effectively track who is accessing the database, even though it takes more time and effort to manage. While this approach isn't ideal because it requires more work to maintain, it's the best solution available right now for monitoring database access when using IAM authentication with Aurora MySQL.

Workaround: ——————

Given this limitation, in order to audit the information, you can create a one-to-one mapping between IAM users/roles to DB users i.e.,

• IAM_USER_A has permissions to login to the instance using DB_USER_A
• IAM_ROLE_B has permissions to login to the instance using DB_USER_B

Using this, if you see a connection/query executed by DB_USER_A, it was executed by IAM_USER_A.

I have further researched internally and I could confirm that there is already a feature request present to have logging for users authenticated using IAM Database Authentication and the RDS internal development team is aware of this.

You can monitor these resources for any news about new future releases, as they will be posted on the below links:

AWS Forums: https://repost.aws/ What's New in Amazon RDS: https://aws.amazon.com/new/#database-services Amazon Blog: https://aws.amazon.com/blogs/aws/category/amazon-rds/