Context

The component currently uses resource-locker.libjsonnet in

We should verify whether this patch is still required, and update it to use patch-operator.libsonnet directly if it is still needed.

Context

In order to enable HTTP/2 on an Ingress Controller, an annotation has to be added to it [1]. This should be supported by the component.

[1] https://docs.openshift.com/container-platform/4.6/networking/ingress-operator.html#nw-http2-haproxy_configuring-ingress

Alternatives

Manually managing an HTTP/2 Ingress Controller or manually enabling HTTP/2 cluster-wide:

oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true

If the certificate chain openshift4-ingress/wildcard-certificate/cert does not contain a newline, the deployment on the OpenShift 4 cluster fails, because chain and key are concatenated -----END CERTIFICATE----------BEGIN PRIVATE KEY-----,.

Steps to Reproduce the Problem

1. Inject a certificate chain WITHOUT a newline at the end -----END CERTIFICATE-----

    secrets:
      customer-apps-tls:
        stringData:
          tls.crt: ?{vaultkv:${cluster:tenant}/${cluster:name}/openshift4-ingress/wildcard-certificate/cert}

1. Check the OpenShift cluster router secrets

oc -n openshift-ingress get secret router-apps-tls -o jsonpath="{.data.tls\.crt}" | base64 -d
oc -n openshift-authentication get secret v4-0-config-system-router-certs -o jsonpath="{.data.apps\.cluster\.domain\.ch}" | base64 -d | grep "BEGIN PRIVATE KEY"

Actual Behavior

Without a newline this result in -----END CERTIFICATE----------BEGIN PRIVATE KEY-----, which causes several base components not starting or even crashing.

Expected Behavior

The component must either check for a newline at the end of the injected certificate chain and add one if not there.
Or potentially just add always a newline to the chain (untested).

Test the certificate chain ahead could be an other solution to it, but would potentially cause downtime.

It's not acceptable that the user has to check for a newline, because it is high likely this is happening very often and we can't ensure component users read the documentation at such low level.

In projectsyn/commodore#192, some parameter values were deprecated. This component is affected by this change and needs to adapt. See the commodore change log for the details.

This issue provides visibility into Renovate updates and their statuses. Learn more

This repository currently has no open or pending branches.

• Check this box to trigger a request for Renovate to run again on this repository

Context

The property defaultCertificate of an ingress takes the name of a Secret containing the certificate can key to be used by default. As of now, the component does not allow to manage those secretes. The component should allow to configure those secrets. It should also support to use cert-manager to create those secrets.

  openshift4_ingress:
    ingressControllers:
      default:
        defaultCertificate:
          name: ingress-default-cert
      example.com:
        defaultCertificate:
          name: ingress-example-com-cert

    secrets:
      ingress-example-com-cert:
        stringData:
          tls.crt: ?{vaultkv:${cluster:tenant}/${cluster:name}/whildcard-example-com/cert}
          tls.key: ?{vaultkv:${cluster:tenant}/${cluster:name}/whildcard-example-com/key}

    cert_manager_certs:
      ingress-default-cert:
        … # Spec of cert-manager.io/v1/Certificate

Reuse keys in cert_manager_certs as values for spec.secretName of the created Certificate resource by default, but allow users to override that field from the hierarchy, if they really want.

Alternatives

🤷🏼