Use label-prefix-file

[DockToFuture]

How to categorize this PR?

/area networking
/kind enhancement

What this PR does / why we need it:
By default, Cilium considers all labels to be relevant for identities, with the following exceptions, see:
https://docs.cilium.io/en/stable/operations/performance/scalability/identity-relevant-labels/#limiting-identity-relevant-labels
As the statefulset label were also included into this list the preceding behaviour was changed which could potentially break running kubernetes cluster and its workload once for statefulset is matched in the networkpolicies as shown below.

  podSelector:
    matchLabels:
      statefulset.kubernetes.io/pod-name: vpn-seed-server-1

To circumvent this issue thelabel-prefix-file with the excluded identities from: https://docs.cilium.io/en/stable/operations/performance/scalability/identity-relevant-labels/#identity-relevant-labels except the statefulset is used.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Release note:

Cilium uses the `label-prefix-file` with the excluded identities from: https://docs.cilium.io/en/stable/operations/performance/scalability/identity-relevant-labels/#identity-relevant-labels except the statefulset.

[ScheererJ]

Thanks a lot for this fix.

What do you think about making the configmap immutable and adding a hash so that we ensure that changes make it into the cilium agent pod? Is this not required as the configmap will not be changed often?

WDYT?

[DockToFuture]

What do you think about making the configmap immutable and adding a hash so that we ensure that changes make it into the cilium agent pod? Is this not required as the configmap will not be changed often?

If the configmap is immutable changes would only happen if we build a new release and then the pods would already be restarted. Do you think a checksum is really necessary here?

[ScheererJ]

If the configmap is immutable changes would only happen if we build a new release and then the pods would already be restarted. Do you think a checksum is really necessary here?

It depends on how cilium agent reads the configmap. If it only reads the configmap during startup a checksum annotation ensures that it gets restarted if the configmap changes. However, if cilium agent watches the files of the configmap and reacts to changes at runtime there is no need for a checksum.

Does the documentation of this option give any indication how it works?

[ScheererJ]

/lgtm