We should watch SSL certificates on disk and reload them (and recreate SSL_CTX) when they change.
It's unclear whether this is the perfect solution (vs LDS with encrypted private keys).
Needed by Istio.
cc @kyessenov @louiscryan
We also need to support the appropriate draining behaviors as certificates approach their expirations. This is true for both the client and server certificates in mTLS.
There is also some need for coordination between impending LDS and kube volume mounter. Or add some way to fetch the actual certs from the discovery service rather than expecting it to be on a local file system.
IMO it would be much better to just do this via LDS, which will natively support draining of the old listener. If we have LDS, do we need explicit support for cert reloading?
Are certs going to be inlined in the LDS response?
Yes, that will be one of the options (unclear if the only one, though).
Are certs going to be inlined in the LDS response?
@htuch is working on API specification now. If we need that we should have that option. We will also obviously have the option to read from disk.
Will need to assess the security properties of key distribution vs common
best practices. Kubernetes has 'secrets' which it makes some assertions
about that we are currently leveraging in Istio when we ship certificates
as files. We'll need to have some authentication mechanism in place to be
able to rely on an API for fetching certs. Perhaps we use the filesystem as
a bootstrap for the API?
On Wed, May 3, 2017 at 3:50 PM, Matt Klein notifications@github.com wrote:
Are certs going to be inlined in the LDS response?
@htuch https://github.com/htuch is working on API specification now. If
we need that we should have that option. We will also obviously have the
option to read from disk.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lyft/envoy/issues/891#issuecomment-299057434, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIoKPCeYT84zb-Zj_dT7C89Ah_s7qh-Mks5r2QS9gaJpZM4NQAIc
.
Yup will need thinking. Obviously, we will discover LDS typically via DNS, and could do mTLS to config servers via on disk cert.
@kyessenov @louiscryan @PiotrSikora would like to won't fix this in favor of forthcoming LDS API. Do we need independent support for this? cc @htuch
I'm closing this for now in favor of LDS and OOB conversations. We can reopen if this is needed.
I'm still not sure how to automatically reload certificates, so I posted the question to:
https://stackoverflow.com/q/54031488/23059
Most helpful comment
I'm still not sure how to automatically reload certificates, so I posted the question to:
https://stackoverflow.com/q/54031488/23059