namespace transformation fails to update rolebinding subject

[richardmarshall]

Starting in v3.0.3 if a resource is included with the same namespace as the target for the namespace transformer the service account update for rolebindings will not set the namespace correctly.

For the following kustomization and resources:

cat kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: foo
resources:
- test.yaml

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: crb
subjects:
- kind: ServiceAccount
  name: sa
  namespace: bar
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa
  namespace: bar
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm
  namespace: foo # this configmap has the same namespace as the transformer target

Output from v3.0.2

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa
  namespace: foo
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: crb
subjects:
- kind: ServiceAccount
  name: sa
  namespace: foo
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm
  namespace: foo

Output from v3.0.3

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa
  namespace: foo
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: crb
subjects:
- kind: ServiceAccount
  name: sa
  namespace: null
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm
  namespace: foo

In v3.0.3 the subject of the ClusterRoleBinding has a null namespace instead of the expected value foo.

Without the explicit .metadata.namespace in the configmap the update of the role binding works as expected.

Discovered in this slack thread for more context:
https://kubernetes.slack.com/archives/C9A5ALABG/p1563542754114100

Will look into what is causing this when I have some available time.

[jbrette]

Fixed by Update Namespace and Name simultaneously

[jbrette]

@richardmarshall The #1379 has been merged. Can you check it and close the bug.

[richardmarshall]

@jbrette Looks good, closing.

[jannickfahlbusch]

It seems like #1379 (f649b62 to be precise) broke our setup with replacing the namespace. We are using kubebuilder and kustomize on top of it.

Here is a simplified example which reproduces the issue:

default/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: "foo"

bases:
 - ../manager

manager/kustomization.yaml:

resources:
  - clusterRoleBinding.yaml

manager/clusterRoleBinding.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: manager-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: manager-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: system

After running kustomize build we get the following YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: manager-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: manager-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: system

Expected was:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: manager-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: manager-role
subjects:
- kind: ServiceAccount
  name: default
  namespace: foo

So far I tried to find a workaround for this issue with no success? Did the syntax to replace the namespace changed or is this a new bug?

[Liujingfang1]

@jannickfahlbusch Thank you for reporting the issue. This is a new bug. The namespace transformation on default ServiceAccount was hard coded previously. This change removed it. We should fix that. @jbrette Can you take a a look? If solving it in the namereference is not feasible, we can reuse the previous logic.

[jannickfahlbusch]

Interesting, I just tried to change the name of the ServiceAccount to a value different than default. It's not working in the last versions if the name is not default (Tried all v3.0.x versions and v2.1.0)

[Liujingfang1]

@jannickfahlbusch This is fixed in 3.1.0.

[YiannisGkoufas]

Just to say that this is still not working in 3.8.2 as well. If you use any other name besides default the namespace won't be updated.

kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: my-namespace
resources:
  - role_binding.yaml

rolebinding.yaml:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dataset-operator
subjects:
- kind: ServiceAccount
  name: dataset-operator # Doesn't replace the namespace value
  namespace: foo
roleRef:
  kind: ClusterRole
  name: dataset-operator
  apiGroup: rbac.authorization.k8s.io

The above keeps the namespace as foo

However if I modify the subjects as:

rolebinding.yaml:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dataset-operator
subjects:
- kind: ServiceAccount
  name: default # Replaces the namespace value
  namespace: foo
roleRef:
  kind: ClusterRole
  name: dataset-operator
  apiGroup: rbac.authorization.k8s.io

Kustomize will work correctly and replace namespace with my-namespace

[YiannisGkoufas]

By the way also by using vars it won't work:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dataset-operator
subjects:
- kind: ServiceAccount
  name: default
  namespace: $(dataset-operator-namespace)
roleRef:
  kind: ClusterRole
  name: dataset-operator
  apiGroup: rbac.authorization.k8s.io

[Shell32-Natsu]

@YiannisGkoufas Could you provide the definition of your ServiceAccount?

[YiannisGkoufas]

I don't think it would make any difference, since I haven't even included it in the resources.
But here it is:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dataset-operator

[Shell32-Natsu]

@YiannisGkoufas Seems dup with #2906

[YiannisGkoufas]

Yep indeed! So the ServiceAccount and the reference on the ClusterRoleBinding need to have as namespace "default" for it to be replaced. Should be documented somewhere though :)
Thanks @Shell32-Natsu

[Shell32-Natsu]

Good to hear that solves your problem.

/close