A good starting point is Ahmet Alp Balkan's resource "kubernetes-network-policy-recipes".

You can see examples of labels like one allowing traffic only to a port of an application:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-allow-5000
spec:
  podSelector:
    matchLabels:
      app: apiserver
  ingress:
  - ports:
    - port: 5000
    from:
    - podSelector:
        matchLabels:
          role: monitoring

That helps illustrating a good label policy, ie one which helps your use case (that is: what you are trying to do as a network policy)

Namespaces:

• I recommend grouping resources by namespaces for "resources you can just delete altogether".

• Most notably, Kubernetes Policy objects (like RBAC, PodSecurityPolicy, NetworkPolicy, ResourceQuota) are per-namespace. So "namespaces" are often for organizational/team boundary.

Labels:

• These can be applied to any kind of object (incl. namespaces)
• Think of labels that indicate logical grouping of objects.
• For example you can have an app=paymentservice label for everything that empowers this app (Pods, Service, Secret)
• You can also use labels to indicate:
  • version/commit numbers: gitcommit=235ab3f
  • purpose (especially useful while testing namespaces etc) purpose=testing
  • organizational boundary (again, for namespaces) team=payments