Hi @danlsgiga
I’ve never heard of any application requiring to use multiple AWS profiles concurrently
For most application, a single profile is enough to get things done. However, I strongly believe that there will come a time where people can’t deal things at the IAM level due to some restrictions–this scenario provides the need to have multi-profile support for automatic HTTPS in the route53 module.
you need to specify what profile to use for every call.
I agree with that. However, the current way of specifying a profile is Global (means you can only use 1 profile for all virtualhosts)… For me I think that method is very limiting… So I suggest that we add a new argument in the tls directive where people can specify a profile per virtual-hosts,… if there’s no profile specified in the virtual host, then it can fall back to a global/default profile.. Example caddyfile:
assets.staging-site.com:443 {
bind {$ADDRESS}
reverse_proxy /* web-server:80 {
header_up Host "assets.staging-site.com"
}
tls {
dns route53 {
max_retries 10
aws_profile "staging-profile" # New argument for multi-profile support
}
}
}
assets.production-site.com:443 {
bind {$ADDRESS}
reverse_proxy /* web-server:80 {
header_up Host "assets.production-site.com"
}
tls {
dns route53 {
max_retries 10
aws_profile "production-profile" # New argument for multi-profile support
}
}
}
even the aws cli does not support it
AWS-cli is very different from AWS-GO-SDK…
Please check this link to see the SDK support of case-based configuration for aws-go-sdk:
https://docs.aws.amazon.com/sdk-for-go/api/aws/session/#hdr-Creating_Sessions
If you need to work across different AWS accounts / roles, you need to do that at the IAM level assigning a role that gives you access to all resources you need.
As I said, handling things at the IAM level may not be an option for everyone.