search

wasmCloud / wasmcloud-operator

Kubernetes operator for declaratively deploying wasmCloud applications (via wadm) and hosts on Kubernetes.
Apache License 2.0
26 stars 9 forks source link

Support loading additional CA certificates from ConfigMaps in WasmCloudHostConfig #69

Closed joonas closed 1 month ago

joonas commented 1 month ago

Once https://github.com/wasmCloud/wasmCloud/issues/2460 is implemented, we need to add support for configuring the new option with certificates provided as ConfigMaps (for an example of what the ConfigMap might look like, see the OpenShift documentation) and mounted into the host as volumes.

LuukSt commented 1 month ago

Mounting a volume in the example given will require a mount for each file if you need to provide muliple CA bundle file (or an item/key specification for each file). It could be considered to mount the configmap without key specification, in which case all files in the configmap will be mounted without further specification required. I guess this also relates to the comments regarding "Single Flag for Certificate Loading" by liamwh in issue https://github.com/wasmCloud/wasmCloud/issues/2460

joonas commented 1 month ago

Hi @LuukSt, appreciate the feedback!

Just a couple of notes to clarify how we were imagining this could work in terms of your feedback:

Mounting a volume in the example given will require a mount for each file if you need to provide muliple CA bundle file (or an item/key specification for each file).

So the idea is that you should be able to pass in a ConfigMap with one or more files inside of it (stored as .crt in PEM format) that would then all be projected to a directory as a Volume Mount by the operator.

The operator would then pass this directory (or in the case of an individual file, perhaps just the individual file) as an argument to the --tls-ca-path flag described in https://github.com/wasmCloud/wasmCloud/issues/2460, which will support loading the CAs from either an individual file (as in --tls-ca-path /data/certs/my-ca.crt) or a directory of files (as in --tls-ca-path /data/certs).

Furthermore, it will support the ability to also parse "certificate bundles" where you might have an entire chain stored together into a single file rather than as multiple files.

On top of that, the operator will also support the option of providing more than one ConfigMap in case you had a use case that requires it (as opposed to including all of the necessary certs in a single ConfigMap).

An example where the ability to provide multiple ConfigMaps could be helpful is if you had a case where you're perhaps using an in-cluster CA for the OpenTelemetry collector, so that's provided as one ConfigMap, and then for your organization's OCI registry you may have a different CA that needs to be loaded, so that could be provided as a second/separate ConfigMap.

It could be considered to mount the configmap without key specification, in which case all files in the configmap will be mounted without further specification required.

I didn't describe it originally in the issue here, but the idea for how we'd likely want to provide the configuration for which ConfigMaps need to be loaded might end up looking something like what the Gateway API does for it's BackendRef resources (see also the BackendRef API definition). So rather than depending on a specific key within the ConfigMap, we'll take an object reference and then iterate over keys of the referenced object.

This has a couple of benefits that I see:

  1. While we may only support ConfigMaps to start, it is possible to extend this to also support Secrets, for example (though there are some implications on that).
  2. While we may only support ConfigMaps from the same namespace as the WasmCloudHostConfig initially, we could in theory, support referencing them cross-namespace.
  3. Assuming we expose this as a repeatable option (i.e. a list of references as in the Gateway API examples), we'll have the ability to support the aforementioned use case of having multiple CA bundles to pull in for different purposes / clients.
LuukSt commented 1 month ago

Thanks for the extensive answer @joonas. This approach seems to have sufficient flexibility in it as far as I can see now. The support for bundles is indeed useful as we by default use a standard provided CA bundle file that contains multiple full chains. Furthermore; the support for secrets might also be very useful. I guess this could be the way to for instance serve cert-manager generated cert secrets to applications in the wasmcloud host?

joonas commented 1 month ago

@lxfontes is working on this.