mirror of
https://github.com/rancher/dynamiclistener.git
synced 2025-06-24 05:47:03 +00:00
When using a chained store of Kubernetes -> Memory -> File, a file-backed cert with a valid ResourceVersion could not be updated when the Kubernetes store was offline, as the Memory store was skipping the update if the ResourceVersion was not changed. The Kubernetes store passes through the secret update without a modified ResourceVersion if the Secret controller is not yet available to round-trip the secret through the apiserver, as the apiserver is what handles updating the ResourceVersion when the Secret changes. In RKE2, this caused a deadlock on startup when the certificate is expired, as the apiserver cannot be started until the cert is updated, but the cert cannot be updated until the apiserver is up. Fix this by also considering the certificate hash annotation when deciding if the update can be skipped. Signed-off-by: Brad Davidson <brad.davidson@rancher.com> |
||
---|---|---|
.github | ||
cert | ||
factory | ||
server | ||
storage | ||
filter.go | ||
go.mod | ||
go.sum | ||
LICENSE | ||
listener_test.go | ||
listener.go | ||
README.md | ||
redirect.go | ||
tcp.go | ||
VERSION.md |
dynamiclistener
DynamicListener allows you to setup a server with automatically generated (and re-generated) TLS certs with kubernetes secrets integration.
This README
is a work in progress; aimed towards providing information for navigating the contents of this repository.
Changing the Expiration Days for Newly Signed Certificates
By default, a newly signed certificate is set to expire 365 days (1 year) after its creation time and date.
You can use the CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS
environment variable to change this value.
Please note: the value for the aforementioned variable must be a string representing an unsigned integer corresponding to the number of days until expiration (i.e. X509 "NotAfter" value).
Versioning
See VERSION.md.