We are looking to connect an Postgres Database hosted on AWS, connecting via IAM. Our Security policy mandates that any IAM access is restricted to a specific AWS Account ID.
My question is, is Retool able to provide their Account ID for this purpose? I couldn't find any mention of this in the documentation. Thanks!
Hi @josh_sc, I talked to a few engineers and the consensus is that you shouldn't need a Retool AWS account ID in order to connect your database. Unless you have some additional context about your setup, you can use your own AWS account ID in your security policy, and all you need to provide in Retool is the db username, region, and AWS access/secret key:
If you have any specific errors or other issues in setting up this connection, let me know!
Thanks @Mike_M, perhaps I didn't explain it properly. This has also been asked in this thread: Improve AWS resource connection security
The process is also outlined in option #2 in Knock's documentation for reference: How to send SMS messages with AWS SNS | Knock Docs
Hey @josh_sc - We don't currently have a role attached to our cloud pods to assume cross-account roles like that yet, on the list long term!
+1 for adding this support in the cloud host offering.
Retool's own security documentation recommends: "Prefer IAM role assumption over static access keys." We'd like to do exactly that — but we can't without platform support for IAM role-based authentication.
Static access keys are a liability. They're long-lived, they require rotation, and rotation introduces operational overhead and risk — a missed rotation or a leaked key creates real exposure. IAM roles eliminate all of that. No credentials to generate, no secrets to store, no rotation schedule to maintain, no blast radius if something is accidentally exposed.
This isn't a nice-to-have. For organizations with security and compliance requirements, long-lived static credentials are increasingly a non-starter. Your docs already make the case for why — we just need the feature to act on it.
Thanks for sharing, @Ken_De_La_Guera! I'm doing some additional investigation on this and will share my findings shortly. 
I've confirmed that, in this case, our docs were one step ahead of our implementation, @Ken_De_La_Guera. We're currently evaluating the lift associated with fully supporting IAM assumed roles.
