You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 21, 2023. It is now read-only.
@leehinman might be able to explain this a little better, since he understands PKI better than I do.
Right now, the anticipated behavior for the shipper, based on how we get config from elastic-agent, is that when we get a connection handshake from an input, we'll use a GetCertificate callback function to lookup the certificate needed for the connection, based on the fact that we get copies of all inputs' TLS settings from elastic-agent. This has a few problems:
As @leehinman has pointed out, this rather non-standard and requires extra work on behalf of all components, as opposed to just relying on CA to verify connections for us.
This is particularly problematic for beats, as in order for the shipper to look up the cert, we need to send it a unit ID (or something else that the shipper can map to a unit) as part of the TLS handshake, which we can't easily do, as the beat's output is global, and the beat will receive multiple units.
The text was updated successfully, but these errors were encountered:
@leehinman might be able to explain this a little better, since he understands PKI better than I do.
Right now, the anticipated behavior for the shipper, based on how we get config from elastic-agent, is that when we get a connection handshake from an input, we'll use a
GetCertificate
callback function to lookup the certificate needed for the connection, based on the fact that we get copies of all inputs' TLS settings from elastic-agent. This has a few problems:The text was updated successfully, but these errors were encountered: