Added proposal to Enable SSL for Metrics Reporter

[antonio-pedro99]

This proposal addresses 65: Add support for https:

[scholzj]

Thanks for the proposal.

Pro-tip: You should write proposals as one sentence per line. That makes it much easier for reviewers to comment on a selected sentence. And for you to actually much better understand which comment belonged to which sentence.

[scholzj]

That is not really how monitoring works. You usually collect the data locally and if needed, forward it remotely through central mechanisms. You do not scrape or expose them remotely. So in the rare cases where TLS is actually used, encrypting it somewhere in some gateway would be even much more rare.

[antonio-pedro99]

@ppatierno

I guess that given the usage of HTTP or HTTPS is done via the prometheus.metrics.reporter.listener (to be set as http:// or https://), it sounds to me that supporting both is impossible.

We do not support at the same time, it's "either or."

[im-konge]

Thanks for the proposal. As Jakub already mentioned, please have one sentence per line. It's better for giving some comments (I started with first paragraph, but it applies to all other paragraphs).

[ppatierno]

This is wrong. This is the path of the keystore storing the key.

[scholzj]

Ehh, no. It is key.location - so it would not be a keystore. That would be keystore.location.

[ppatierno]

I am lost here. The definition says "Inline PEM certificate or certificate chain as a string." which for me it means that I am putting the PEM "string" into this parameter, while the name is a "location" which is a path to a file. So what is this parameter really?

[scholzj]

The Inline part is wrong ... so is certificate or certificate chain ... and the as a string as well. But it is not a path to a keystore but a path to the key. That is what I was trying to add to your comment. Sorry.

[ppatierno]

it is not a path to a keystore but a path to the key

That's not what we had on the bridge. Taking the HTTP bridge proposal it says:

the HTTP Bridge server starts with SSL enabled and the new configurations will allow users to define locations of the keystore files via http.ssl.keystore.certificate.location and http.ssl.keystore.key.location or certificate chain and key via http.ssl.keystore.certificate.chain and http.ssl.keystore.key in PEM format

so the ssl.keystore.key.location is representative of "location of the keystore file" storing the key, as well as ssl.keystore.certificate.location is the "location of the keystore file" storing the certificate.

While ssl.keystore.certificate.chain and ssl.keystore.key are the inline PEM representation as strings of cert and key. Of course, even in this case I see the "keystore" part in the name being misleading :-(

[antonio-pedro99]

it is not a path to a keystore but a path to the key

That's not what we had on the bridge. Taking the HTTP bridge proposal it says:

the HTTP Bridge server starts with SSL enabled and the new configurations will allow users to define locations of the keystore files via http.ssl.keystore.certificate.location and http.ssl.keystore.key.location or certificate chain and key via http.ssl.keystore.certificate.chain and http.ssl.keystore.key in PEM format

so the ssl.keystore.key.location is representative of "location of the keystore file" storing the key, as well as ssl.keystore.certificate.location is the "location of the keystore file" storing the certificate.

While ssl.keystore.certificate.chain and ssl.keystore.key are the inline PEM representation as strings of cert and key. Of course, even in this case I see the "keystore" part in the name being misleading :-(

I think we have decided to keep the HTTP Bridge out of this proposal.
It's starting to get a bit confusing me as well.
I will take a careful look at the comments and the proposal after the working hours

[scholzj]

so the ssl.keystore.key.location is representative of "location of the keystore file" storing the key, as well as ssl.keystore.certificate.location is the "location of the keystore file" storing the certificate.

Keystore holds one or more certificate bundles - i.e. it has both the certificate/chain and key. So for keystore location, you need just one option logically names keystore.location. It you have key location and certificate location, that suggests it should not be a keystore with a bundle but a single item.

So if it was supposed to be keystore, it should be a single option.

---

Looking at what the Bridge options say in the main branch docs, it is messed up as well, but in a slightly different way. But that is a different story. We should take it somewhere else as we could still fix things.

[antonio-pedro99]

My overall understanding of the settings(as I was initially planning):

keystore.location: path to the keystore(containing the key and certificate)
keystore.password: password of the keystore

This is the base settings to the KeyStoreManagerFactory would need.

If we just bother about identifying the HTTPserver to the clients, the first config would look like:

• prometheus.metrics.reporter.listener.ssl.keystore.location: The path of the keystore file(containing both the key and the certificate)
• prometheus.metrics.reporter.listener.ssl.keystore.password: Password of the specified keystore.

If we bother to trust who is trying to connect a truststore and its password would be needed.

Keeping the trustore out for now, if we are interested in set the above configs directly in server/client.properties` in PEM formats(because we do not want to pass files path), the final config would look like

• prometheus.metrics.reporter.listener.ssl.keystore.key: Inline keystore key in PEM format.
• prometheus.metrics.reporter.listener.ssl.keystore.certificate or prometheus.metrics.reporter.listener.ssl.keystore.certificate.chain: Inline keystore certificate, or a set of certificate. Since PEM are usually stored as mult-line base 64 string, the value of this option can be passed as multiple line starting with " and end with ".

the keystore.certificate.chain name makes more sense to me though.

[scholzj]

My overall understanding of the settings(as I was initially planning):

keystore.location: path to the keystore(containing the key and certificate)
keystore.password: password of the keystore

This is the base settings to the KeyStoreManagerFactory would need.

If we just bother about identifying the HTTPserver to the clients, the first config would look like:

• prometheus.metrics.reporter.listener.ssl.keystore.location: The path of the keystore file(containing both the key and the certificate)
• prometheus.metrics.reporter.listener.ssl.keystore.password: Password of the specified keystore.

If we bother to trust who is trying to connect a truststore and its password would be needed.

Don't get me wrong. This is not a bad assumption. And actually, these might be the options to ask for by many users as using keystores such as JKS or PKCS12 is pretty common in Java land. I do not have a problem if you want to keep it.

---

But at the same time, using keystores is pretty uncommon in the cloud-native land. That is where you use PEM files. And that is where Strimzi and Prometheus live. So, for the integration into the rest of Strimzi, I think we definitely want PEM files support.

If we one day integrate it directly into the Strimzi API (I have some doubts about it, but not 100% sure), we will likely do it through the inline options as that is what we use everywhere else. If the integration is done by some opaque user configuration (i.e. some configuration map), it is IMHO more likely to use paths to PEM files.

So, we possibly might need/want all three ways?

• Keystore
• PEM files through location
• PEM files inlined

But that is what this proposal needs to decide. I guess the first thing we need is that we all understand the differences and then as maintainers + Mickael we need to decide what is the right direction.

[ppatierno]

It's not a path to a PEM file. It's a path to a keystore including certificates in PEM format.

[scholzj]

Same as above. Also, if you would have a keystore, you would have just one location as it would have the certificate and public key in one file (e.g. PKCS12 or JKS store).

[antonio-pedro99]

Same as above. Also, if you would have a keystore, you would have just one location as it would have the certificate and public key in one file (e.g. PKCS12 or JKS store).

I do not think a keystore holds any public key, right?
A keystore primarly holds private key, secret key and trusted certificate

[scholzj]

It does. Keystores either hold the private-public-key bundle ... or multiple public keys.

[ppatierno]

I would mention "inline" as for the key below.