add functionality to re-read config file, certificate

[andras-babos]

Preflight Checklist

• [X] I agree to follow the Code of Conduct that this project adheres to.
• [X] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

We use dex with tls certificates which needs to be expired and rotated every 60 days. After we replace the tls certificates on disk (in kubernetes secret), the dex still presenting the old cert and eventually will present the service with expired cert. Our current method is to manually restart the application before the 60 days expiration time. As we use cert-manager.io to automatically renew the tls certificates it would be great if dex itself can detect the changed config files and use the new certs without full application restart.

Proposed Solution

Please include a feature in dex to detect changes in certificates or config files in general and apply the related changes without manual restart.

Alternatives Considered

Currently we restart the application with external methods (script, cronjob, modify kubernetes deployment, etc.) so we have workaround but it's not ideal.

Additional Information

No response

[rdpa]

just came across this, if you're still having this issue i'd recommend https://github.com/stakater/Reloader

[andras-babos]

just came across this, if you're still having this issue i'd recommend https://github.com/stakater/Reloader

Thanks! I will check it, it looks a viable workaround also.

[hawksight]

Does https://github.com/dexidp/dex/pull/2964 mean that certificates mounted as a volume will be reloadedm from that latest release v2.37.0 onwards?

So this issue is half solved? e.g.

• Certificates reload
• Config file does not

[jrhunger]

I think #2964 didn't fully fix the cert issue, at least in Kubernetes. We had a cert renewed by cert-manager, and confirmed that the updated cert is available in the container filesystem, however Dex did not pick it up.

This article probably explains why. Excerpt:

This is where the Kubernetes AtomicWriter implementation comes into the picture: If there’s an update to the Secret/ConfigMap, kubelet will create a new timestamped directory, write files to it, update ..data symlink to the new timestamped directory (remember, it’s something you can do atomically, and finally “delete” the old timestamped directory. It’s how the files from a Secret/ConfigMap volume are always complete and consistent with one another.

In this case the watch was applied to the directory, which is good, but this line ..

if _, ok := watchFiles[evt.Name]; !ok || !evt.Has(fsnotify.Create) {
	continue loop
}

... is continuing the loop if the event does not apply to a secret file being watched. However, due to the way kubernetes handles secret changes (per linked article), the event in question would actually apply to the ..data intermediate link, not the secret file itself.