Add TLS settings to all connection settings

[michel-laterman]

Add new TLSConnectionSettings across all connection settings a server can offer.

• Relates Proxy & TLS settings in OpAMPConnectionSettings, TelemetryConnectionSettings, and OtherConnectionSettings #203

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: michel-laterman / name: Michel Laterman (41ad8fb, a174175, 15fdbc0, 7849fe0, 2b15b10, 05f2846)

[tigrannajaryan]

Thanks for the draft @michel-laterman

I left some comments, and I would like @andykellr to also review.

[tigrannajaryan]

I would advise to break this down into 2 PRs: one that adds TLSConnectionSettings, the other that adds ProxyConnectionSettings.

If there are known uses cases for other_settings that should likely be the 3rd PR where we can discuss it.

[michel-laterman]

I'll recreate the ProxySettings in another pr

[tigrannajaryan]

How do we expect this to work? Is OpAMP servers expected to know where on agent's disk these files are located? How would the server know?

This also potentially is an attack vector where malicious server can direct the agent to read an arbitrary file. On its own it may seem benign but if we end up having another weakness where the file that was read for some reasons gets reported to the server this will allow the server to remotely read arbitrary files from agent's machine. This goes against our zero trust recommendations in the Security section.

Should we instead send the content of CA certificate to the agent to use? The agent can save the content locally and use it in subsequent connections.

This can work particularly well for TelemetryConnectionSettings and OtherConnectionSettings, the idea being that OpAMP server has the knowledge about the CA used by telemetry and other connection destinations.

And even for OpAMPConnectionSettings this may make sense as a flow, where the agent first connects without the TLS certificate, in sort of a bootstraping mode, then accepts server offered CA certificate for future verifications. This is similar to Trust On First Use flow that we already have but in the opposite direction (trust of server, instead of trust of client).

If we think this is a valid usage of TLSConnectionSettings I think we should add a corresponding section in the spec and include a sequence diagram that explains it.

[michel-laterman]

When specifying the file path we assume it is present at that location across all agents. It can be provisioned by some other tool (baked into the image, or by a configuration management tool).

But I can see how having a filepath specification goes against our current recommendations. It's specified because it is a common approach to TLS configuration, however I can remove the it if we want to keep our security exposure low.

The content can instead be specified with the ca_pem attribute (I'll rename to ca_pem_content to make that clearer).

I like the idea of a TOFU like mechanism for accepting CAs from servers, I'll try to add the description for this in the spec.
At elastic we do something a little similar to that, we allow the specification of a CA by a fingerprint hash and add the matching CA to the cert pool when it is found in a connection (implementation here). This assumes that what ever is installing an agent has some additional information about the server and it prevents an agent from blindly trusting any CA. This may be worth breaking out into another issue/pr, what do you think?

[tigrannajaryan]

however I can remove the it if we want to keep our security exposure low.

Yes, I think we should remove it for now.

[tigrannajaryan]

What is the use case for this flag? Why would you want to remotely specify TLS connection settings and at the same time tell the agent to ignore them?

Generally speaking the use cases are not entirely clear. How are all these parameters supposed to be used? It seems like we borrowed the settings from the Collector which is probably a good starting point but we need to understand if they are applicable to OpAMP-managed configuration.

If we don't have a clear use case for a setting then we should not include it here.

[michel-laterman]

The best use case I can think of for this case is to ease development/testing (allow http connections)

[tigrannajaryan]

@michel-laterman we had a discussion with other OpAMP approvers/maintainers and decided to follow the Otel spec's requirements for making new proposals, namely to ask for prototypes that demonstrate the new capabilities. We will be formalizing the requirements in this PR: #207

I think it is important for this particular proposal to show how the TLS settings will be used. It is not a trivial change, so a working code would help understand it better.