Use certificate namagement from OpenShift Elasticserch operator

[pavolloffay]

Requirement - what kind of business use case are you trying to solve?

I want to use certificate provisioning and management from the OpenShift Elasticsearch operator. This feature reduces code in Jaeger operator and allows using a single ES cluster with multiple jaeger collectors.

An explicit installation at the moment could look like this. First provision ES and then Jaeger:

apiVersion: logging.openshift.io/v1
kind: Elasticsearch
metadata:
  annotations:
    logging.openshift.io/elasticsearch-cert-management: "true"
    logging.openshift.io/elasticsearch-cert.jaeger-elasticsearch: user.jaeger # this jaeger-elasticsearch secret with ca-bundle.crt, tls.crt, tls.key
  name: elasticsearch
spec:
  managementState: Managed
  nodeSpec:
    resources:
      limits:
        memory: 1Gi
      requests:
        cpu: 200m
        memory: 1Gi
  nodes:
    - nodeCount: 1
      proxyResources: {}
      resources: {}
      roles:
        - master
        - client
        - data
      storage: {}
  redundancyPolicy: ZeroRedundancy

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: tenant1
spec:
  strategy: production
  ingress:
    openshift:
      sar: "" # allow login for all OCP users for testing
  volumeMounts:
    - name: elastic-certs
      mountPath: /certs
  volumes:
    - name: elastic-certs
      secret:
        secretName: jaeger-elasticsearch
  storage:
    type: elasticsearch
    options:
      es:
        server-urls: https://elasticsearch:9200
        index-prefix: tenant1
        num-shards: 1
        num-replicas: 0
        timeout: 15s
        tls:
          enabled: true
          ca: /certs/ca-bundle.crt
          cert: /certs/tls.crt
          key: /certs/tls.key

The certs are provisioned by ES operator and Jaeger operator just injects them. However, this should be fully automated so let's have a look how it could look like.

Proposal - what do you suggest to solve the problem or improve the existing situation?

Action items:

• remove cert_generation script
• add spec.storage.elasticsearch.name which points to the ES instance. The default name is elasticsearch
• add spec.storage.elasticsearch.provision - decides whether ES instance should be provisioned or not. Defaults to true

The ES is provisioned if spec.storage.elasticsearch.provision=true and options.es.server-urls is not defined. The ES CR name is used from spec.storage.elasticsearch.name. It will use logging.openshift.io/elasticsearch-cert.jaeger-<elasticsearch-name>: user.jaeger to create Jaeger ES certificate.

If options.es.server-urls is missing and spec.storage.elasticsearch.provision=false Jaeger operator uses ES instance from spec.storage.elasticsearch.name to connect to the ES. In this case Jaeger operator will have to watch changes on ES Kind to adjust shards and replicas in Jaeger. It will use logging.openshift.io/elasticsearch-cert.jaeger-<elasticsearch-name>: user.jaeger for Jaeger ES certificate.

Upgrade

The existing Jaeger instances with self-provisioned ES will have to keep working.
Jaeger operator right now creates <instance-name>-jaeger-elasticsearch secret with user.jaeger.key, user.jaeger.crt and ca.crt. which differs from EO created secret (name is configurable via annotation logging.openshift.io/elasticsearch-cert.<name>: user.jaeger) tls.key, tls.crt and ca-bundle.crt.

The upgrade procedure will have to upgrade storage TLS config es.tls.* to point to the new files.