Eventing TLS: Support exposing cluster-local CA Certs for addressables resources

[pierDipi]

Describe the feature

As the Eventing TLS proposal describes we should expose CA certs for Serving's addressables resources in the resource status when using HTTPS

status:
  address:
    url: https://service.default.svc.cluster.local
    CACerts: <PEM formatted CA cert>
  addresses:
    - name: https
      url: https://service.default.svc.cluster.local
      CACerts: <PEM formatted CA cert>

[dprotaso]

Few questions:

1. nit: Is it too late to change CACerts to caBundle ? - the casing looks really weird when looking at the yaml.

2. Secondly, from our recent serving internal TLS discussion it became clear that since the activator can be in and out of the data path we required our Ingresses to support multiple subject alternate names. In this scenario Serving would be programming the ingress resources so we know the activator hostname/path. But how is Eventing supposed to know about this alternate name?

[pierDipi]

Few questions:

1. nit: Is it too late to change CACerts to caBundle ? - the casing looks really weird when looking at the yaml.

We just made a release, so technically yes ... renaming a field seems painful

2. Secondly, from our recent serving internal TLS discussion it became clear that since the activator can be in and out of the data path we required our Ingresses to support multiple subject alternate names. In this scenario Serving would be programming the ingress resources so we know the activator hostname/path. But how is Eventing supposed to know about this alternate name?

I thought that Serving internal TLS will remove this limitation eventually (cc @ReToCode), I don't think even in non-eventing case you want clients to do any complex SAN logic to call a service

[dprotaso]

Actually I was wrong - the service.default.svc.cluster.local domain would hit the internal ingress so this wouldn't be an issue for clients.

[ReToCode]

I thought that Serving internal TLS will remove this limitation eventually (cc @ReToCode), I don't think even in non-eventing case you want clients to do any complex SAN logic to call a service
Actually I was wrong - the service.default.svc.cluster.local domain would hit the internal ingress so this wouldn't be an issue for clients.

Exactly. This should not be an issue and we (will) know what CA signed the certificate for service.default.svc.cluster.local so we can put it in the adressable.

[dprotaso]

/triage accepted

[pierDipi]

As discussed earlier, we will integrate Eventing and Serving TLS using ConfigMaps with trust bundles (indirectly integrating Knative with trust-manager: https://cert-manager.io/docs/trust/trust-manager/) (see #14717 and knative/eventing#7532).

I think CA certs field in the status is still handy for quick experiments/development in the self-signed issuer case but it's optional.

So closing this issue for now