SecretClass access control

We should have a way to control who's allowed to mount which SecretClass.

It's not really practical to control based on the deploying user, because the idea of a "source user" in the first place is about as clear as mud in K8s (the end user creating the StatefulSet? The controller creating the Pod from that? The controller creating the PersistentVolumeClaim from that? The controller creating the PersistentVolume from that?).

The best we could do would probably be to allowlist individual target Namespaces.

This is theoretically already possible via a K8s admission hook like OPA; we should either implement something native or document how to accomplish it using one of those.

Inizia dai punti di estensione di Kubernetes per il controllo di ammissione e dalla documentazione collegata di OPA per Kubernetes. Chiarisci se il progetto debba fornire un controllo degli accessi nativo per SecretClass o documentare un approccio basato su admission-hook, e definisci come funzionerebbe una allowlist dei Namespaces di destinazione. Il lavoro è completato quando l’approccio scelto e il relativo ambito sono specificati esplicitamente.