Is your feature request related to a problem? Please describe.
Global pull secrets are leveraged by all workloads in the cluster and that is too permissive in cases where there are other products installed in the cluster.
Describe the solution you'd like
Have the Entitled Registry entitlement key be placed prerequired in the openshift-gitops namespace and have PreSync hooks that copy the key solely to the target namespace of the Cloud Paks.
Note that, as of release 4.0.6, Cloud Pak for Data still requires a global pull secret, so the documentation and implementation need to take that into account.
Describe alternatives you've considered
Use an external secret manager and pull the entitlement key from a key vault. This alternative was discarded for now because there is only one key being managed and we would still need to handle that key to the external secret manager. Once we start to have multiple keys, an external secret operator (like https://external-secrets.io) will make more sense.
Additional context
Add any other context or screenshots about the feature request here.
With CP4D still requiring a global pull secret and with CP4WAIOps already been added to this repo without a dependency on a global pull secret, this issue is effectively addressed.
Is your feature request related to a problem? Please describe. Global pull secrets are leveraged by all workloads in the cluster and that is too permissive in cases where there are other products installed in the cluster.
Describe the solution you'd like Have the Entitled Registry entitlement key be placed prerequired in the
openshift-gitops
namespace and have PreSync hooks that copy the key solely to the target namespace of the Cloud Paks.Note that, as of release 4.0.6, Cloud Pak for Data still requires a global pull secret, so the documentation and implementation need to take that into account.
Describe alternatives you've considered Use an external secret manager and pull the entitlement key from a key vault. This alternative was discarded for now because there is only one key being managed and we would still need to handle that key to the external secret manager. Once we start to have multiple keys, an external secret operator (like https://external-secrets.io) will make more sense.
Additional context Add any other context or screenshots about the feature request here.