TLS trust store for kafka/storage and oauth

[chlunde]

The OpenShift API server, kafka and elasticsearch TLS certificates can be issued by other CA (public or private company CA) in some deployments. This is currently not supported.

In OpenShift, it is possible to request a TLS trust bundle injected into a configMap, see https://docs.openshift.com/container-platform/4.3/networking/configuring-a-custom-pki.html

kind: ConfigMap
apiVersion: v1
metadata:
  labels:
    config.openshift.io/inject-trusted-cabundle: "true"
  name: trust

Possible fix

Producer/consumer config

        - --kafka.producer.tls.ca=/etc/trust/tls-ca-bundle.pem
[...]
        - --kafka.consumer.tls.ca=/etc/trust/tls-ca-bundle.pem

        - mountPath: /etc/trust
          name: trust-volume
          readOnly: true
[...]
      - configMap:
          name: trust
        name: trust-volume

It might be possible to mount it over the existing TLS trust bundle to avoid custom paths like /etc/trust in this example. I did this for the oauth2-sidecar:

Oauth config/query

        - mountPath: /etc/pki/ca-trust/extracted/pem
          name: trust-volume
          readOnly: true

      - configMap:
          name: trust
          items:
            - key: ca-bundle.crt
              path: tls-ca-bundle.pem
        name: trust-volume

[chlunde]

I think there are parts to this issue:

• overriding kafka.consumer.tls.ca - can options from the user override generated options (I think I tried
• documenting adding a configMap with like in the second example

[objectiser]

@jpkrohling Would you be able to comment on this one?

[jpkrohling]

I'm probably missing something really obvious, but:

1. Kafka - I need to check the code, but I think we only generate options when we are using Strimzi, and we get the cert data from the KafkaUser resource. This is generated by Strimzi, and we have no influence on it. For existing Kafka instances, the operator shouldn't be generating an option like kafka.consumer.tls.ca, IIRC. Whatever is specified in the Options node should be passed down.
2. Elasticsearch - I'll let @pavolloffay answer that, but I believe it's not possible to use OpenShift's auto-generated certs, as the operator generates the client and server certs, used for TLS authorization. Given that OpenShift's mechanism can't generate client certs for authz purposes, we have to generate the whole chain ourselves when doing self-provisioning. Again, for instances provisioned outside of the operator, it should be possible to specify a bundle via Options.

[jpkrohling]

@chlunde could you check whether #1079 would cover your use case? Or do you still need something else?

[chlunde]

Looks good, I think so. I don't have time to verify now, but I think this issue can be closed.

[jpkrohling]

Alright, feel free to reopen if there's something missing.