Manage deprecation

[ldez]

Do you want to request a feature or report a bug?

proposal

What did you do?

Deprecated in the future:

• EntryPoint.Compress: will become a struct
• ACME.OnDemand: will be removed, use OnHostRule instead
• By default, don't trust given X-Forwarded-For, unless in a whitelist
• 0 server weight disables it (see Change default server weight #1780 (comment))
• Etcd API V2 : etcd.useAPIV3 will be removed and Etcd v3 become the default.
• suppress old basic auth, move HeaderField into basic/Digest auth.
• don't allow dot in the segment name (label)
• drop redundant log fields (ex: OriginStatusLine which is just a representation of OriginContentSize, OriginDuration, and OriginStatus)
• remove passHostHeader in with KV (use lower-case key instead)
• replace http and https as entry point name by web and websecure

[dottgonzo]

why ondemand will be deprecated? is useful for multiple traefik instances, where only the routed one try to renew it's certificate, instead of every traefik instances with hostrule. Removing this feature, we need to separate the toeml file for each instances, place there a constraint option, and update all the containers with the label used for the constraint rule. This because not every traefik instances exposing their 80 port has the same dns records associated. Acme validation will fail on the traefik instances not pointed by dns records. Using ondemand is an easy solution because will check acme ssl only for the one reached by dns

[nmengin]

Hello @dottgonzo.

is useful for multiple traefik instances

I guess you want using multiple instances of Træfik in a cluster?
If you want it, the configuration is different.

indeed, you have to use a KV store which will save and share your configuration and your ACME certificates as desbribed in the documentation and this user guide.

Thanks to this cluster configuration, only the leader instance will create and renew the certificates. The option onDemand is not required in this use case.

WDYT?

[dottgonzo]

yes i understand, but i've some issues with your compose proposed on documentation. My swarm is not using consul as discovery service (and i'm not experienced with consul at all, but this is not the point). in swarm mode with traefik running as replicated instance on every host ("mode: global"), consul accept only the first instance and says that can't associate the others, because it says that the id is taken (i've not the log here). You can try to deploy the compose as suggested on your documentation, changing only the number of traefik instances, from replica:1 to mode global.
The point is: why not supporting file storage with multiple instances, if it only need some stronger support to the ondemand rule?

[emilevauge]

@dottgonzo ACME.OnDemand has nothing to do with your cluster issue. I suggest we move the swarm mode + Consul + Traefik discussion from this Github issue to the #support channel on Slack. Thanks :)

[nmengin]

The acme.onDemand option is deprecated and has to be deleted in the future because of all the problems it can induce.
When ACME has been introduced in Træfik, this option was created to allow users to create easily all their ACME certificates once before restarting Træfik without this option.

Indeed, keeping the onDemand option has many disadvantages :

• Slow when requesting a hostname certificate for the first time : The ACME challenge and the certificate generation are executed on the first request. These operations take time and can lead to DoS attacks.
• Slow requests : An ACME challenge will be done for all the (sub)domains detected in all the requests, even if they do not exist or they are not reachable by the Let's Encrypt server. In this particular use case, every requests will be slow.
• Rate limiting : An ACME challenge will be done for all the (sub)domains detected in requests, even if they do not exist or they are not reachable by the Let's Encrypt server. This can lead to exceed the Let's Encrypt rate limits, and thus prevent from renewing or creating any certificates.

We introduced the acme.onHostRule option to replace acme.onDemand. Using this, we don't have to wait for the first request to get the certificate as it is created as soon as the backend is deployed. Thus, there is no impact on the reverse proxy performances.

If you are using Træfik in a particular context which does not seem to be compatible with the onHostRule option, please give more details on your use case in a comment below.
We will see if it is possible to address your use case and how we can do it.

Thanks in advance.

[dottgonzo]

Thanks for your explaination, i understand this limits some months ago, when i start to try traefik. i had switched from ondemand to onhost rule, due to some issues related to such you just write.

it's hard to explain my use case, it involve the problem of keep separate live streamings connectivity of some containers on the swarm, from theirself and from other kind of request to other containers. They must be reached from diferent and precise ip to the swarm (i can't delegate some kind of load balancer or risk that streaming connectivity of an istance block other kind of services), so every traefik/proxy must live separate from others, on the same swarm.

Testing consul, i can't obtain that, only by spawning it as kv store, and configuring something like the toeml, i need also (but i'm not sure) of the discovery service provided (so this is equal to shut down everything to reconfugre the nodes on the swarm), probably some kind policy for the access and maybe this is not sufficient.
The only solution is using constraints, but is tricky

So for this reason, i'm requesting if is possible that the instance consider the acme validation process only when it will be really reached the first time from that domain (and they have not yet a certificate of course) and not only thanks by the label/constraint matching. I thing that this will be useful for many cases (consul or not)

[fkrauthan]

I actual have a use-case for the on demand rule. We are planning to provision custom sandbox access to our customers. For that we do not know the actual domain at the beginning. With the onDemand flag we just need to point the new DNS record to our sandbox environment and it will generate the correct certificate for us. Or what would be the suggested alternative?

[Yggdrasil]

We have a use case for onDemand that I don't have a good alternative for. It's similar to @fkrauthan's.

We run Traefik on a few dozen servers, with a file-based config managed by Puppet. Most servers use onHostRule already but there's one where that is not feasible.

Our customers can point their domains to our parking/redirects-server. This server is configured to return a HTTP redirect if configured or present a static domain parking page if no redirect is configured.

Because we have a TLS-everywhere policy we've enabled onDemand. Some of the domains are registered and managed by us, others by customers themselves. We simply don't know which domains may be served by this server. Currently we have over 2000 TLS certs on this server.

We've received a rate-limit increase from Let's Encrypt so that's not a bottleneck for us. The DoS effect described above has not been an issue for us.

[fkrauthan]

I think an easy "workaround" for an DoS attack prevention would be calling a external tool that returns with status code 0 if the domain is allowed to be issued a certificate and anything else if it is not. That way I can write a simple tool that either queries my database or calls an API server to validate the host file but keeps the flexibility of onDemand certificate generation.

[dhrp]

my (our) 2ct as well, regarding OnDemand certificates.

We have a use-case where we allow our customers deploy our software in their own cloud environment through the AWS marketplace. We ask the user to point a domain of their own to our software and have a TLS certificate generated for that address on first request.

Regarding DDOS attacks (and friends) we may implement a restart with that option OFF after the first certificate was generated.

Also; (outside the scope of the use-case above).. Not all use-cases of TLS are business critical, and the ease of use of this option can be super helpful. -> So please document the risk, but don't remove the option.

[fkrauthan]

Are there any news in regards of supporting OnDemand with optional verification step (e.g. program execution that returns if that domain should be allowed)?

[kajmagnus]

Look here how lua-resty-auto-ssl lets one specify a callback function for determining if a domain is alowed or not:
https://github.com/GUI/lua-resty-auto-ssl#allow_domain

to me looks similar to what you suggested @fkrauthan — so seems that's a works-fine approach then, I'm thinking.

My use case, b.t.w., is I have a SaaS and people can connect their custom domains, to this SaaS. And I don't know beforehand which domains they'll want to use. ... Turns out I can alternatively use the File provider, and have the app server update a file with frontend rules, once someone has added a custom domain. Traefik then watches this file and auto reloads the rules.

[ldez]

as v2 is now available since 2019-09-16, we will close this issue.