Skip to content
This repository has been archived by the owner on Sep 21, 2023. It is now read-only.

Standardize the shipper's gRPC TLS setup process #224

Open
Tracked by #226 ...
fearful-symmetry opened this issue Jan 19, 2023 · 0 comments
Open
Tracked by #226 ...

Standardize the shipper's gRPC TLS setup process #224

fearful-symmetry opened this issue Jan 19, 2023 · 0 comments
Assignees
Labels
enhancement New feature or request Team:Elastic-Agent Label for the Agent team

Comments

@fearful-symmetry
Copy link
Contributor

@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:

  1. 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.
  2. 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.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request Team:Elastic-Agent Label for the Agent team
Projects
None yet
Development

No branches or pull requests

2 participants