support specifying (global) custom ca certificate for schema registry client

[BugenZhao]

Possibly be the X problem of #17173 and #17188.

Users can utilize a self-signed certificate for the schema registry server. In this case, they need to specify a custom certificate for RW to use it. We can add related configuration to the with-options for the connector.

---

However,

schema registry client is just a standard HTTP client with reqwest. Considering there are a lot of other usages of HTTP clients in our system (especially for sinks like Doris, Snowflake, and Clickhouse) and they could encounter exactly the same issue as well, I'm wondering if we really should address such issues through adding ad-hoc configurations one-by-one.

Can we directly leverage the system certificate store? Actually, users can workaround the issue today following the procedure here, which requires no changes on RW kernel itself.

The only shortcoming is that it requires users to build a new Docker image to persist the certificate configuration. Perhaps we can find a way to simplify this step.

[fuyufjh]

Can we directly leverage the system certificate store? Actually, users can workaround the issue today following the procedure here, which requires no changes on RW kernel itself.

If I understand correctly, this issue is proposing to make the root CA configuration globally, right? Or more specifically, packing the root CA into the container image.

Personally, I think this is a bit overkilled, considering the additional development work in our control plane. According to my experience, many users don't use certificates so "correctly", in some cases they may have different CAs for each service.

---

I tend to follow the original way as how we handle all non-root certs. Taking the Kafka sink as an example:

(assuming our secret management has completed)

create kafka_sink (...) WITH (
   properties.ssl.ca = secret 'kafka_ca' , // specify root cert here
   properties.ssl.certificate = secret 'client_risingwave_client.cert',
   properties.ssl.key = secret 'client_risingwave_client.key',
)

With the help of secret management, the users can simply share certificates among multiple source/sinks by specifying the same secret id.

This approach will indeed add some boilerplate code, but with the help of well-designed library e.g. reqwest::ClientBuilder::add_root_certificate(), the complexity should be not very high.

[BugenZhao]

This approach will indeed add some boilerplate code, but with the help of well-designed library e.g. reqwest::ClientBuilder::add_root_certificate(), the complexity should be not very high.

Agreed. Due to the fact that we have to develop the feature for connectors one by one, however, I'm just concerned that we may overlook some customer needs. Without any global workarounds (even not that secure), this blocks them from making further progress until the next release or patch version.

[tabVersion]

@yuhao-su I am afraid this can bring more complexity for secret because cert may be in different file formats and the kernel needs to know about it.
Proposing add a patch to the syntax: ref secret <secret-name> [as file [crt/pem/pkcs]] to indicate the file type.
Or do you think they need to specify the secret type when creating?

[fuyufjh]

@yuhao-su I am afraid this can bring more complexity for secret because cert may be in different file formats and the kernel needs to know about it. Proposing add a patch to the syntax: ref secret <secret-name> [as file [crt/pem/pkcs]] to indicate the file type. Or do you think they need to specify the secret type when creating?

Good point. as file [crt/pem/pkcs] seems too complicated to me. I tend to support only PEM format for now. Materialize also did this.

[yuhao-su]

We never verify file format in RW. That means we use whatever files user provide. So I guess should should not ask user to specify any file format information for now. We can do it later if we want to support JSON format secret.

[fuyufjh]

We may provide a document of mounting the certs in Docker container.