Specialise Bundle for X.509 Certificates

[SgtCoDFish]

(This is a follow up from discussions which took place in the cert-manager biweekly meeting on 2022-07-27)

Currently Bundle is essentially a Kubernetes implementation of the Unix cat command - it takes several text inputs and concatenates them into an output. This allows it to be agnostic to the type of thing it's concatenating, but it has a few shortcomings:

• It's not possible to concatenate binary data in a correct and meaningful way
• It's not possible for us to vary input/output types
• It's easy to misuse one type of output for a purpose it wasn't intended

For example, it's currently essentially impossible to create a TLS trust Bundle which includes as inputs a list of PEM certificates and separately a DER-encoded certificate, and produce an output in any meaningful format. Without context, we can't decode the base64-encoded binary data for the DER certificate or convert it to PEM, and we can't concatenate a PEM input certificate with a DER certificate without doing some conversion beforehand.

It would also be desirable to support outputting in PEM or JKS or other keystore types.

Proposal

What was discussed in the biweekly meeting was the following:

1. Bundle as it exists today becomes specialised for X.509 certificates (specifically for the purposes of creating TLS trust bundles, but we can support X.509 more widely)
2. We'd like to support other keystore formats, but might need a new CRD to be able to do so. Examples mentioned included Wireguard keys or keys for code signing verification
3. The default output type is assumed to be a concatenated list of PEM encoded certificates; that'll be the default. We don't necessarily need to support more formats at first.
4. The default input type is assumed to be a list of PEM encoded certificates. We should at least support DER encoded certs for input as well.
5. All input certificates are should be convertible to some intermediate representation, and that intermediate representation should be convertible to all output formats. We propose the intermediate format be a list of PEM encoded certificates.

Example

This would produce an output containing all the certs in "my-pem-certs" with the cert in "my-der-cert" appended to the end. The output would be in PEM format.

apiVersion: trust.cert-manager.io/v1alpha2
kind: Bundle
metadata:
  name: my-bundle
spec:
  sources:
  - secret: # defaults to PEM because the type isn't specified
      name: "my-pem-certs"
      key: "ca.pem"
  - configMap:
      name: "my-der-cert"
      key: "root-certs.crt"
      type: "der" # "der" assumes that the value is base64 encoded binary, which is the k8s convention
#  - inLine: |  # would error out because this isn't a valid cert
#      abc123 not a cert
  target:
    configMap:
      key: "output-certs.pem" # defaults to PEM because format not specified
    namespaceSelector:
      matchLabels:
        mylabel: "true"

[erikgb]

@SgtCoDFish Would it make sense to consider this issue in relation to #243 and the new API version planned, ref. #242?

I think it's a fair assumption to consider all bundle sources as PEM-encoded certificates now. If this breaks for users, we could just say that we're fixing a bug. 😉

[SgtCoDFish]

I'd forgotten about this!

I actually made the (then-breaking) change to force all inputs to be valid PEM already: #75 - that means this issue is partially done.

The other part of this issue was to add the ability to specify sources of a different type, e.g. JKS, PKCS#12 or DER. I guess that makes this issue a bit redundant.

I agree this is kinda related to the issues you raised. Maybe this issue could be simplified now that #75 does part of it?

[cert-manager-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale