Configuration of trust stores for Prometheus and Apicurio clients

[MikeEdgar]

Closes #1277

---

Approach

This change allows for a trust store to be configured for metrics source (Prometheus) and schema registry (Apicurio) clients. The trust store may be set in the Console CR along with the URLs for each connection type.

For example:

...
spec:
  metricsSources:
    - name: ocp-prometheus
      type: openshift-monitoring
      url: https://thanos-querier.mycluster.example.com
      truststore:
        type: PEM  # also supports JKS or PKCS12
        alias: "" # optional, only for JKS or PKCS12
        password: {} # optional, only for JKS or PKCS12. Same structure as `content` below
        content:
          # only one of `value` or `valueFrom` is used
          value: |
            -----BEGIN CERTIFICATE-----
            MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
            ...
            emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
            -----END CERTIFICATE-----
          # May use a ConfigMap or Secret key when no literal value is given
          valueFrom:
            configMapKeyRef: {}
            secretKeyRef: {}
...

The operator will then read the trust store content either directly from the CR for literal values or from the ConfigMap or Secret, copy to the Console secret being reconciled, and create a volume/mount and appropriate Quarkus environment vars for a TLS configuration bucket [1] specific to the connection.

The clients in the API server will then obtain the trust store/SSL context from the TLS bucket named by convention and use for the connection to the remote service.

[1] https://quarkus.io/guides/tls-registry-reference#using-the-tls-registry

[MikeEdgar]

@katheris , @k-wall this PR still needs some unit/integration tests, but I am curious to get your thoughts on the general approach/pattern to implement this.

[k-wall]

    alias: "" # optional, only for JKS or PKCS12

what's the idea here? I'm familiar with alias on the keystore side - to select a single key from potentially many in the store, but in the truststore side you normally trust all the certificates in the truststore. In Java TrustManagerFactory accepts a truststore and gives you a TrustManager which trusts them all. So, what's the role of the alias?

[k-wall]

    password: {} # optional, only for JKS or PKCS12. Same structure as `content` below

is this a ref to a secret? you would normally try to avoid an inline secret.

EDIT: answered my own question.

[MikeEdgar]

    alias: "" # optional, only for JKS or PKCS12

what's the idea here? I'm familiar with alias on the keystore side - to select a single key from potentially many in the store, but in the truststore side you normally trust all the certificates in the truststore. In Java TrustManagerFactory accepts a truststore and gives you a TrustManager which trusts them all. So, what's the role of the alias?

That's what I've typically seen also, but the TLS registry supports configuration of an alias for JKS and P12 [1]. I figured better to align to the target on it.

[1] https://quarkus.io/guides/tls-registry-reference#trust-stores

[MikeEdgar]

    password: {} # optional, only for JKS or PKCS12. Same structure as `content` below

is this a ref to a secret? you would normally try to avoid an inline secret.

Yes, it can be. The field allows for value or valueFrom like the truststore content. I kept the structure the same to allow security, but also convenience for development and testing, etc.

[k-wall]

On the whole, the approach looks good. I'm concerned about some of the coding in the ApicurioClient but will be content to overlook providing there's a plan to address the debt.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
89.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[MikeEdgar]

@k-wall I'll go ahead and merge this if no objections. The config option in the CR will be used also for #1248 to support a TLS truststore for the OIDC provider (building on #1126 once that's merged)