network policy rules are incorrectly updated with kustomization labels

[sdickhoven]

What happened?

kustomize incorrectly updates network policy rules (rather than just the podSelector) when using labels with includeSelectors: true or commonLabels in the kustomization.

What did you expect to happen?

i expect the network policy rules to remain unaltered.

How can we reproduce it (as minimally and precisely as possible)?

kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: foo
labels:
- includeSelectors: true
  pairs:
    key1: val1
    key2: val2
- includeTemplates: true
  pairs:
    key3: val3
resources:
- netpol.yaml

netpol.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-app
spec:
  podSelector:
    matchLabels: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx
      podSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx
          app.kubernetes.io/component: controller
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          app.kubernetes.io/name: prometheus
    ports:
    - protocol: TCP
      port: 8080

Expected output

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  labels:
    key1: val1
    key2: val2
    key3: val3
  name: my-app
  namespace: foo
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx
      podSelector:
        matchLabels:
          app.kubernetes.io/component: controller
          app.kubernetes.io/name: ingress-nginx
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          app.kubernetes.io/name: prometheus
    ports:
    - port: 8080
      protocol: TCP
  podSelector:
    matchLabels:
      key1: val1
      key2: val2

Actual output

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  labels:
    key1: val1
    key2: val2
    key3: val3
  name: my-app
  namespace: foo
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx
      podSelector:
        matchLabels:
          app.kubernetes.io/component: controller
          app.kubernetes.io/name: ingress-nginx
          key1: val1    # <<<<<<<< incorrect!!!
          key2: val2    # <<<<<<<< incorrect!!!
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          app.kubernetes.io/name: prometheus
          key1: val1    # <<<<<<<< incorrect!!!
          key2: val2    # <<<<<<<< incorrect!!!
    ports:
    - port: 8080
      protocol: TCP
  podSelector:
    matchLabels:
      key1: val1
      key2: val2

Kustomize version

v5.6.0

Operating system

None

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[sda399]

the default list includes those paths to podselectors. I guess you can overcome that with some reorganization of your netpol files.

edit:
labelTransformer might be a solution for you:

kustomize/plugin/builtin/labeltransformer/LabelTransformer_test.go

Lines 19 to 37 in 616c084

	kind: LabelTransformer
	metadata:
	name: notImportantHere
	labels:
	app: myApp
	quotedBoolean: "true"
	quotedFruit: "peach"
	unquotedBoolean: true
	env: production
	fieldSpecs:
	- path: spec/selector
	create: true
	version: v1
	kind: Service
	- path: metadata/labels
	create: true
	- path: spec/selector/matchLabels
	create: true
	kind: Deployment

[sdickhoven]

sure... i'm aware that this is an option.

but if i have a kustomization with 50 different resources (Deployments, ServiceAccounts, NetworkPolicys, PodDisruptionBudgets, Ingresses, Services, ServiceMonitors, ...) it becomes a bit tedious to spec out all label fields that i want modified.

plus, every time i add a new resource or remove a resource i have to remember to update the label transformer... not a great ux.

kustomize modifying a NetworkPolicy's ingress and egress rules is simply nonsensical since those typically have nothing to do with the resources being kustomize'd at all... except in rare edge cases when i need a network policy that allows traffic from all pods of a StatefulSet to themselves for some kind of cluster sync traffic.

it would make much more sense if i had to do something out of the ordinary for such a rare setup vs for something that is the norm: allow traffic from/to different workloads to/from the workload i'm kustomize'ing.

...just my opinion. 🤷

but i realize that there's probably no way to do this in a way that won't break existing kustomizations that rely on this odd behavior. 😞

so feel free to close this issue. i just wanted to point out that this behavior is a bit... suboptimal. 🤷

[sdickhoven]

but i realize that there's probably no way to do this in a way that won't break existing kustomizations that rely on this odd behavior. 😞

actually, come to think of it... i guess the following could be done to make this change backward compatible:

just like includeSelectors and includeTemplates, a new behavior modifier could be introduced. e.g.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: foo
labels:
- includeSelectors: true
  includeNetworkPolicyIngressRules: false # default to `true`
  includeNetworkPolicyEgressRules: false # default to `true
  pairs:
    key1: val1
    key2: val2
- includeTemplates: true
  pairs:
    key3: val3
resources:
- netpol.yaml

it's kinda kludgy but it's the only thing i can think of to disable the less-than-perfect existing behavior in a backward-compatible way. 🤷