-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect TLS cert changes automatically #3083
Comments
Hello @spawnia . If I understand correctly your use case, I presume it's not a bug but the expected behavior. Do you want to propose a feature to listen to the certificate files modifications? |
Surely that would be a great feature to have. I can not think of a use case where you update the certificate files but would like to hold off on publishing those changes. Reflecting the change immediately makes sense and goes nicely with traefik's killer feature, the way it can dynamically update its configuration. |
One concern here is that if you update the certificate using a new key, the keypair will be mismatched for a period of time, which will cause a TLS failure. I'm wondering if there should be a delay after a triggered update to prevent this. |
Good point, there are a few ways to ensure no such mismatch happens. The common pattern would be that this mechanism should ensure that key updates are atomic. Adding a delay has the advantage of being relatively simple and should cause little to no performance hit for the time inbetween, where only one part of the keypair has been changed. Another way could be this flow:
This would make it so that a successful update could be reflected right away. Both approaches have the disadvantage that if the user is unaware of this mechanism, a problematic key change will look like it worked fine when checking the page right after. Because of this, the delay/timeout should be kept relatively short. |
Hello @spawnia, Many thanks for your propositions. The solution you described is more complicated and, even if it can work, it contains disadvantages and can generate misunderstoods for users, as you noticed. I guess none of the solutions (the current, yours) allows addressing entirely the problem and this one needs more investigations. WDYT? |
I think that what needs to be figured out is how to make this the most convenient and clear for users. Watching for TLS updates could be a configuration option, something like this: [[entryPoints.https.tls.certificates]]
certFile = "tests/traefik.crt"
keyFile = "tests/traefik.key"
watch = true Choosing the correct default seems difficult. Having traefik pick up the changes automatically might lead to a nice experience and fits with traefiks dynamic configuration approach - in most cases this should not cause problems and feel like it just works™. The underlying challenge here is finding the right balance between convenience and magic. Anyways, users should be made aware of the underlying limitations of this option in a short paragraph. For some use cases, manually refreshing seems like the most suitable approach. Calling |
@nmengin Updating certificates, putting them in place and simply calling a
Looks like there is a need for an actual change in the definitions inside the toml file to trigger a reload, which is quite hard/disturbing to automate. Edit: looks like a known bug #3272 |
Hi, I have faced similar issue when trying to use traefik with dynamic tls configuration. But instead it ends up with traefik generated certs. Here is my configuration (using traefik version 1.7.12): configmap:apiVersion: v1
kind: ConfigMap
metadata:
name: traefik-configmap
namespace: traefik-ingress
data:
traefik.toml: |
defaultEntryPoints = ["http","https"]
insecureSkipVerify = true
[entryPoints]
[entryPoints.http]
address = ":80"
[entryPoints.https]
address = ":443"
[entryPoints.https.tls]
[entryPoints.traefik]
address = ":8080"
[kubernetes]
[kubernetes.ingressEndpoint]
publishedService = "traefik/traefik"
[ping]
entryPoint = "http"
[api]
entryPoint = "traefik"
[file]
[[tls]]
entryPoints = ["https"]
[tls.certificate]
certFile = "/ssl/tls.crt"
keyFile = "/ssl/tls.key" and traefik itself as DaemonSet:kind: DaemonSet
apiVersion: extensions/v1beta1
metadata:
name: traefik-ingress-controller
namespace: traefik-ingress
labels:
k8s-app: traefik-ingress-lb
spec:
template:
metadata:
labels:
k8s-app: traefik-ingress-lb
name: traefik-ingress-lb
spec:
updateStrategy:
type: RollingUpdate
serviceAccountName: traefik-ingress-controller
terminationGracePeriodSeconds: 60
volumes:
- name: traefik-tls-cert
secret:
secretName: traefik-tls-cert
- name: traefik-configmap
configMap:
name: traefik-configmap
containers:
- image: traefik
name: traefik-ingress-lb
volumeMounts:
- mountPath: "/ssl"
name: "traefik-tls-cert"
- mountPath: "/config"
name: "traefik-configmap"
ports:
- name: http
containerPort: 80
hostPort: 80
- name: https
containerPort: 443
hostPort: 443
- name: admin
containerPort: 8080
hostPort: 8080
securityContext:
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
args:
- --logLevel=INFO
- --configFile=/config/traefik.toml My cert is stored in k8s secret and as you can see it is attached to traefik pods. And in case it is changed traefik does not update. Seems like fix #3272 and #4022 does not fully work. |
Hi @miro-grapeup , thanks for your interest in the project. It looks like a question for the community support channel. The reason is that we keep the issue trackers for issues, and this one is already "triaged" (ref. https://docs.traefik.io/v2.0/contributing/maintainers/#labels). |
I'm just jumping in to comment :) (I have tried Traefik 1.7.12, witch watches my ingresses, and CertManager that creates/recreates missing/invalid certificates). I'm not using Traefik's ACME client. When any ingress or secret is updated, Traefik updates it's Certificate store immidiatly: But the Server pick any certificate with the correct domain name, and caches it for 1 hour: In other words, let it pass at least 1 hour before checking if Traefik have refreshed the certificate (also, Traefiks global default certificate is not catched, but the cert-managers temporary cert will be cached for 1 hour by Traefik. |
I agree with @spawnia. I would love it if traefik could watch for changes in volume for the certs it is consuming. There are already very good suggestions on how we can avoid the misconfiguration/wrong key-cert pair. This feature is very much required. |
This comment has been minimized.
This comment has been minimized.
@Richard87 's comment led me to the right track. For context, we're using Traefik 1.7 in Kubernetes with cert-manager to create the certificates. Earlier, the certificate was mounted in the traefik pod, and we used [
The expectation was that changes to The correct solution was what @Richard87 mentioned - use the Oddly, the logs indicate that the certificates were skipped:
But the updated certificate was indeed used:
(Note that the start date is intentionally 1 hour before the issue date for Let's Encrypt certificates, so the timestamps do match) |
I wonder if this check could be changed to 1 or 5 minutes instead if every 60 minutes without any notable perfomance change? |
Hello, I link this issue to the PR #9993 which is IMO a good enough workaround. |
Hello, Just to add precision to what has been said previously by @nmengin in his last comment. If any contributor finds a better solution, we would love community support to address it. |
Do you want to request a feature or report a bug?
This could be seen as both, dynamically updating certificates on change seems like it would surely make Traefik better.
What did you do?
I am dynamically providing certificates, which i generate by myself and put onto the server. Those should be hot-reloaded on change.
What did you expect to see?
When switching out a certificate on the disk, i would expect traefik to pick up on this change and start delivering the new certificate.
What did you see instead?
The new certificate only got applied after either restarting traefik or making a change in the dynamic config file, which causes traefik to update.
Output of
traefik version
: (What version of Traefik are you using?)What is your environment & configuration (arguments, toml, provider, platform, ...)?
CLI
Contents of the mounted folder:
Contents of rules.toml
If applicable, please paste the log output at DEBUG level (
--logLevel=DEBUG
switch)Nothing happens when changing the certificate files, the changes do get picked up though when i make a change in
rules.toml
The text was updated successfully, but these errors were encountered: