Open mbrancato opened 4 years ago
Hi @mbrancato, does the provider_configuration
field does what you are looking for (https://github.com/remilapeyre/vault-acme/blob/master/website/source/api/secret/acme/index.html.md#parameters)?
@remilapeyre - yes, I saw that thanks to your comment. I think the problem is I was doing some development and I was using a newer upstream go-acme/lego
. Do you think there is another way to do the provider configuration without modifying NewDNSChallengeProviderByName
?
Hi @mbrancato, do you mean to not rely on https://github.com/remilapeyre/lego? If so since https://github.com/remilapeyre/vault-acme/commit/ba2ba5cc79e2de1506dcd7dceb3c08a55e483e27#diff-6f4933a3ee61e4cdec88d8b3af78abc3fa9062dd0a9b8931ab66cd989875cfcaR41-R46 there should be no need to rely on this fork now, I should be able to use the use https://github.com/go-acme/lego now.
Capturing this as an idea for securing the account config of the DNS provider, etc. Currently, the environment used to run Vault would need to already have the secrets used by LEGO configured in the env prior to start Vault. Instead, it would be nice if the user can configure a map in the account. Prior to performing LEGO operations, the vault-acme plugin could set env vars specified in the map.
The map could be treated as a secret and not returned when doing a read operation on the account.