Cleanup: Add new imagePullSecret field to CRD

[tcrawley-xilinx]

Users may want to pull from a private registry (such as ghcr) but without adding a global secret, this change allows users to specify a secret for the Onload CR which is then passed to the device plugin and the module(s).

I decided to only add a single value since I assumed that if a user is using a private registry then they will require the same credentials for all of the onload images and the device plugin. And since the Module CRD only exposes a single pull secret for pulling images I kept it to a single value.

Testing done

If omitted the operands are the same as before.
If present the value is present for each operand.

• Test that the secrets actually work as intended - Tested externally in cluster

[pcolledg-amd]

As with the insecure registry config, I'm more in favour of keeping Onload CRD clean and using built-in support. If a user wants to scope the token narrower than global cluster config, could they not configure in the ServiceAccount instead?

If we're going to deviate from KMM's unusual ImageRepoSecret, we should standarise on the Kubernetes plural property, ImagePullSecrets.

[tcrawley-xilinx]

As with the insecure registry config, I'm more in favour of keeping Onload CRD clean and using built-in support. If a user wants to scope the token narrower than global cluster config, could they not configure in the ServiceAccount instead?

Potentially, I hadn't really thought about that approach. My (slight) concern with that approach is that both the Module CRD and PodTemplateSpec provide options for both ServiceAccountName and imagePullSecrets (or equivalent). I think service account permissions could work as a short term option while we decide what to do with the CRD.

If we're going to deviate from KMM's unusual ImageRepoSecret, we should standarise on the Kubernetes plural property, ImagePullSecrets.

I wanted to use the same data for both the device plugin (which uses ImagePullSecrets) and the modules (which uses ImageRepoSecret), so I don't think a plural solution would work. Regarding the name I don't have a strong opinion, I think I wanted to go for something more k8s-y since it isn't just used for the Module.