Hi all, I’m currently running Caddy from a docker image (latest), and alpine builder (latest)…
I was able to get Automatic HTTPS working (thru DNS Validation) by building caddy with route53 dns module and adding the default “Profile” in the AWS Credentials configuration in the ~/.aws/credentials path as in:
And now I don’t know how to specify in the virtual-host section of the caddyfile about which aws profile/account it should use to connect for route53 dns validation…
dev.example.com:443 {
bind {$ADDRESS}
header X-Robots-Tag noindex
reverse_proxy /* dev:80 {
header_up Host "dev.example.com"
}
tls {
dns route53 # from the development aws account
}
}
prod.example.com:443 {
bind {$ADDRESS}
header X-Robots-Tag noindex
reverse_proxy /* dev:80 {
header_up Host "prod.example.com"
}
tls {
dns route53 # from the production aws account
}
}
In contrast to the cloudflare DNS module, I can specify the API key in the caddyfile itself so no worries on how many cloudflare accounts I use it with as in:
Tried it already, but it will only limit me to use one Profile at a time so it will only let me use Automatic HTTPS for domains thats registered in route53 in that aws account.
I need to use 2 different profiles to make it work for Automatic HTTPS for two domains. The production and development domains belong to two different aws account, so different access keys/id.
I’ve never heard of any application requiring to use multiple AWS profiles concurrently… even the aws cli does not support it… you need to specify what profile to use for every call. 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.
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
}
}
}
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.
I’ve made some changes and added the feature that I was needing. Please see the following links below to and check if I am up to your standards as the maintainer of the original repo. hehehehe!
Hi @danlsgiga, cool! I will check @matt 's review later today, and make some changes.
The current code works already, though still need improvements to comply on the code standards.
Eitherway, still need you to double check, since I’m pretty new to golang, im more of a PHP guy hahha!. If you can join in the discussion or make a recommendation over at github, please do!
Really appreciate all you guys are doing to help me achieve this goal. I’d rather spend hours working on a fix for this than to spend time every 2 months trying to renew ssl.
Can we get a new release of this Route53 plugin with these changes? The docs reflect this new feature but are out of sync with actual releases (doing a build with xcaddy to include the Route53 module currently breaks because it does not recognize the aws_profile attribute.
Hi @harrisreynolds, apologies for the delay… The Added multi-profile support #1 PR works already as per my testing… However, I haven’t been able to find time to test it with “EC2 Instance profiles” as per @danlsgiga ‘s request… :’(
The past few days have been rough for me (at work). I’ll try to test this later tonight to and push this through…
The docs reflect this new feature but are out of sync with actual releases.
I thought that this won’t be documented until all PR’s have been merged and a proper release was done…
I mean, I thought people will all refer to this documentation?
Edit: Should anyone want to help me do the testing for “EC2 Instance Profiles”, please do… All help is really appreciated.
If you can join in the discussion or make a recommendation over at github, please do!