Related to 🚀: For S3 authentication, use AWS EC2/ECS instance profile instead of secret keys · Issue #1593 · stalwartlabs/stalwart · GitHub, access to AWS resources including Route53, S3, and Postgres (RDS/DSQL) is via access key and secret. AWS best practice is to use the IAM role that is assigned to the EC2/ECS/Lambda task.
However, if the resources that need programmatic access are running inside AWS, the best practice is to use IAM roles instead. An IAM role is a defined set of permissions—it’s not associated with a specific user or group. Instead, any trusted entity can assume the role to perform a specific business task.
The request here is to use the task role instead, making access keys and secrets optional. If you use the official AWS SDKs, then this is done for you by those SDKs. Unfortunately, in the case of (for example) Route 53 integration, the current implementation uses Stalwart’s dns-update crate and hand-rolls SigV4 signing over reqwest instead of using the SDK.
IAM roles are used (and preferred) for many of the AWS services including RDS, DSQL, Route 53, S3, and OpenSearch. Route 53 would be the priority first if I was asked to pick one.
Note/Edit: The Stalwart docs for S3 (it won’t let me link here) is out of date, which means #1593 above is probably resolved and should be closed. The S3 provider is using rust-s3. x:S3Store.accessKey and x:S3Store.secretKey are nullable, which leads to rust calling Credentials::new(None, None, None, None, None) which falls back to Credentials::default(), whose chain is env → profile → instance/container metadata. We basically want the same thing for the other AWS services, like Route 53.