Hydra can auto detect TLS certificate expiry and auto restart with new certicates

[doyyan]

Preflight checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions.
• [X] I agree to follow this project's Code of Conduct.
• [X] I have read and am following this repository's Contribution Guidelines.
• [X] This issue affects my Ory Cloud project.
• [X] I have joined the Ory Community Slack.
• [X] I am signed up to the Ory Security Patch Newsletter.

Describe your problem

Hydra's documentation to start with TLS suggests they need to be uploaded as environment variables https://www.ory.sh/docs/hydra/guides/ssl-https-tls If the TLS certificate expires, this could be a costly manual process, say if Hydra was hosted on k8s cluster.

To start with the Hydra clients may fail complaining the certificate is expired. Then the sysadmin will have to manually upload the certs and manually restart Hydra. With Hydra being an Oauth server, this could be a single point of failure for a client.

Describe your ideal solution

For instance, Hydra is connected source of TLS certificates, say a Vault instance. Hydra can detect the certificate expiry before it happens. And then attempt to retrieve it from Vault automatically. If that fails then Log it with a clear message. The Sysadmin might then try to create a new certificate in Vault. Hydra can retry it and the whole process would take little or no manual intervention.

Workarounds or alternatives

A Hydra client fails and the certificate had to be uploaded manually. OR Hydra can be run as an HTTP server behind an HTTPS reverse proxy. It will be the role of the Reverse Proxy to refresh certificates.

Version

v1.11.7

Additional Context

No response

[Demonsthere]

Hello there, I think I understand what you are getting at, but in the context of k8s there already are community approved standards for handling certificates. One of them would be Cert-manager which would auto-update the certificates within the secrets, which then would be propagated to hydra without requiring a restart. I don't think that it should by Hydras' job to be responsible for the certificates

[doyyan]

Hi there, https://www.ory.sh/docs/hydra/guides/ssl-https-tls Appears to suggest its a Hydra start up parameter. So, if this variable reads a k8s secret, it will still need Hydra to restart right as Hydra can only read it at start up?

[Demonsthere]

Let me rephrase that :)

SERVE_TLS_KEY_PATH=/path/to/key.pem
SERVE_TLS_CERT_PATH=/path/to/cert.crt

You would set those envs (or configs in the config file) to a path on the container filesystem, and then mount the k8s secrets in that paths. Now the path to the file is static, but it content can change, and the watcher in hydra should be able to react on a change inside the file

[doyyan]

Hi, Wow, didn't know there is a watcher in Hydra for this, does the watcher track these environment variables as well? SERVE_TLS_CERT_BASE64 SERVE_TLS_KEY_BASE64

[Demonsthere]

The watcher is a dedicated deployment that watches over mounted files, it does not know the envs used by hydra, but mounts all volumes that hydra would. Please take a look at our example with values here Here we mount some sample cm into both hydra and the watcher, and tell the watcher to react on it. Any change in the cm will result in a rollout of the hydra deployment :)

Currently the behaviour is limited to a single file, but that could be easily expanded 😉

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️