[New Resource]: Independent provisioning of RDS Proxy and AWS Secret Manager Secrets Association

[gianni-fiore-prometeia]

Description

This proposal focuses on improving the integration between RDS Proxy resources and AWS Secret Manager Secrets. The goal is to enable independent provisioning of the association between these two resources.

Current implementation and limitations

In the existing implementation, the provisioning of an RDS Proxy resource requires user credentials to be encapsulated within AWS Secret Manager Secrets. These secrets are then used as input for the authentication configuration of the RDS Proxy resource. This approach diverges from best practices which advocate for the ability to independently provision the relationship between an existing Secret and an existing RDS Proxy through a dedicated Terraform resource.

Use Case Scenario

Context: A Terraform module exists to provision databases and database proxies for a multi-tenant environment, where tenants share the database layer. Challenge: Each tenant has specific Secrets defined in their Terraform configurations. The requirement is to create an RDS Proxy that facilitates access using the credentials in these tenant-specific Secrets.

Desired Functionality

Expectation: While provisioning for a specific tenant, there should be functionality to associate a newly provisioned tenant-specific Secret with a pre-existing RDS Proxy. This is similar to the configuration of Load Balancer listeners, where the Application Load Balancer represents the shared resource, and the Listener is the tenant-specific resource you can define and associate later in time and in a way that is independent. Current Limitation: The only available method enforces a dependency between the generic multi-tenant database module and the tenant-specific modules, contradicting the principles of dependency inversion.

Proposal

Enhancement Request: Introduce a feature that allows for the independent provisioning of the association between AWS Secret Manager Secrets and RDS Proxy resources. This addition would increase the modularity and flexibility of infrastructure provisioning in complex, multi-tenant environments, while still allowing to define the initial (mandatory) secret the Proxy will use by default.

Requested Resource(s) and/or Data Source(s)

• aws_rds_proxy_auth_item, with a reference to the ARN of the Secret and a reference to the ARN of the Proxy you want to associate the secret to

Potential Terraform Configuration

# all_tenants/resources.tf

resource "aws_db_proxy" "this" {
    # Add necessary proxy properties here
    # (can still enforce the presence of minimum 1 auth item here as before)
}

# In a separate folder:
# tenants/tenant1/resources.tf

resource "aws_secretsmanager_secret" "tenant_secret" {
    # Define properties for the secret (username/password)
}

resource "aws_db_proxy_auth_item" "this" {
    description               = "Association for Secret with RDS Proxy"
    iam_auth                  = "DISABLED"
    secret_arn                = aws_secretsmanager_secret.tenant_secret.arn
    proxy_arn                 = aws_db_proxy.this.arn
    # Note: 'aws_db_proxy.this.arn' references the ARN of the shared tenancy proxy
}

References

No response

Would you like to implement a fix?

No

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[alexandermarston]

PR #35951 ready to resolve this.