k8sSearch with a fixed searchNamespace doesn't separate services and pods by namespace

Affected version

23.7

Current and expected behavior

When using a SecretClass with a fixed searchNamespace, such as the following:

apiVersion: secrets.stackable.tech/v1alpha1
kind: SecretClass
metadata:
  name: tls-manual
spec:
  backend:
    k8sSearch:
      searchNamespace:
        name: foo

then the service=bar scope will always search for a secret with the label secrets.stackable.tech/service=bar, with no way for the user to separate which namespace the secret should apply to.

This technically applies to all scopes, but node doesn't imply any namespaced behaviour.

Possible solution

1. Change the format of namespace-specific labels to <name>.<namespace>.
2. Add a new label secrets.stackable.tech/namespace=<namespace>.

Either change would be breaking. We could mitigate this by adding an opt-in property to SecretClass that enables the namespace. It could be made opt-out in v1alpha2.

Alternatively, we could declare that fixed searchNs was always unusably broken, and that it isn't worth maintaining the old behaviour at all.

Additional context

No response

Environment

No response

Would you like to work on fixing this bug?

None

Inizia tracciando il comportamento di k8sSearch di SecretClass per fixed searchNamespace e gli scope service e pod. Confronta i due formati proposti per le label dei namespace e determina come funzionerebbero la compatibilità o la migrazione di SecretClass. Il lavoro è completato quando i namespace sono separati in modo affidabile senza lasciare irrisolto il comportamento incompatibile.