Kustomize patches overwritten by namespace

[AchimGrolimund]

What happened?

We would like to patch a rolebinding.yaml with kustomize. The namespace must be set in the meta information and the namespace must be patched in the subjcts area, as the service account can be in a different namespace.

With the old patchesJson6902 it works.

What did you expect to happen?

cI expect the namespace to be in the meta information and the namespace we want to batch in the subject.

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

patches fails

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: ch-future-world-test

resources:
  - rolebinding_image-puller.yaml

patches:
  - target:
      kind: RoleBinding
      name: image-puller
      version: v1
    patch: |-
      - op: replace
        path: /subjects/0/namespace
        value: ch-future-world-prod

# rolebinding_image-puller.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1

metadata:
  name: image-puller
  namespace: ch-future-world-123
subjects:
  - kind: ServiceAccount
    name: default
    namespace: ch-future-world-intg
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:image-puller

patchesJson6902 works

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: ch-future-world-test

resources:
  - rolebinding_image-puller.yaml

patchesJson6902:
  - patch: |-
      - op: replace
        path: /subjects/0/namespace
        value: ch-future-world-prod
    target:
      kind: RoleBinding
      name: image-puller
      version: v1

# rolebinding_image-puller.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1

metadata:
  name: image-puller
  namespace: ch-future-world-123
subjects:
  - kind: ServiceAccount
    name: default
    namespace: ch-future-world-intg
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:image-puller

Expected output

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: image-puller
  namespace: ch-future-world-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:image-puller
subjects:
- kind: ServiceAccount
  name: default
  namespace: ch-future-world-prod # <<== Here is the PROD Namespace from the patches part

Actual output

patches fails

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: image-puller
  namespace: ch-future-world-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:image-puller
subjects:
- kind: ServiceAccount
  name: default
  namespace: ch-future-world-test # <<== Here is the wrong namespace coming from `namespace`

patchesJson6902 works

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: image-puller
  namespace: ch-future-world-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:image-puller
subjects:
- kind: ServiceAccount
  name: default
  namespace: ch-future-world-prod # <<== Here is the right namespace coming from `patchesJson6902`

Kustomize version

4.5.4 & 5.3.0

Operating system

Linux

[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/test-infra repository.

[matthewhughes934]

Replacing the namespace on the subject of a RoleBinding where the subject name is "default" appears to be the expected behaviour (from here):

// In DefaultSubjectsOnly mode (default mode), RoleBinding and ClusterRoleBinding have namespace set on // elements of the "subjects" field if and only if the subject elements // "name" is "default". Otherwise the namespace is not set.

You may be able to configure a namespace transformer to use some other behaviour here (some details/discussion in this issue: https://github.com/kubernetes-sigs/kustomize/issues/629)

As for why it works with a patchesJson6902 I believe that's because of the ordering of the slice here: builtinhelpers.PatchTransformer is before builtinhelpers.NamespaceTransformer so the patch is applied, then the namespace transformer updates the namespace, but builtinhelpers.PatchJson6902Transformer is after the namespace transformer so it applies the patch after the namespace transformer does its update (I am not sure if this is the desired/expected behaviour)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[stormqueen1990]

/lifecycle frozen