Multi-namespace transformer

[TheSpiritXIII]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

The current namespace transformer replaces and unifies all namespaces to a single one. I would love the ability to specify namespace mappings, e.g. rename namespace x to namespace a.

Why is this needed?

Some manifests may have multiple namespaces, e.g. a workload may have different RBAC permissions for different namespaces.

Can you accomplish the motivating task without this feature, and if so, how?

No. The replacements feature comes close but it doesn't replace namespace selectors like the current namespace transformer does -- you would need many replacements, e.g. one each for subjects, role bindings, etc.

What other solutions have you considered?

N/A

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉

[koba1t]

Hi @TheSpiritXIII

You can do what you want with current kustomize!
Please use two directory that contains kustomization.yaml that defined one namespace each others.
And each kustomization.yaml read with resources another kustomization.yaml that contains rbac resource.

├── a-ns
│   └── kustomization.yaml
├── b-ns
│   └── kustomization.yaml
├── base
│   ├── kustomization.yaml
│   └── rbac.yaml
└── kustomization.yaml

# a-ns/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: a-ns

resources:
- ../base
---
# b-ns/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: b-ns

resources:
- ../base
---
# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- rbac.yaml
---
# base/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
#kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- a-ns
- b-ns

I'll close this issue. But if you have any problem related this, Please feel free to reopen and add comments!

/triage need-informations
/close

[k8s-ci-robot]

@koba1t: The label(s) triage/need-informations cannot be applied, because the repository doesn't have them.

Details

In response to this:

Hi @TheSpiritXIII

You can do what you want with current kustomize!
Please use two directory that contains kustomization.yaml that defined one namespace each others.
And each kustomization.yaml read with resources another kustomization.yaml that contains rbac resource.

├── a-ns
│   └── kustomization.yaml
├── b-ns
│   └── kustomization.yaml
├── base
│   ├── kustomization.yaml
│   └── rbac.yaml
└── kustomization.yaml

# a-ns/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: a-ns

resources:
- ../base
---
# b-ns/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: b-ns

resources:
- ../base
---
# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- rbac.yaml
---
# base/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: default
 name: pod-reader
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "watch", "list"]
---
#kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- a-ns
- b-ns

I'll close this issue. But if you have any problem related this, Please feel free to reopen and add comments!

/triage need-informations
/close

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.

[k8s-ci-robot]

@koba1t: Closing this issue.

Details

In response to this:

Hi @TheSpiritXIII

You can do what you want with current kustomize!
Please use two directory that contains kustomization.yaml that defined one namespace each others.
And each kustomization.yaml read with resources another kustomization.yaml that contains rbac resource.

├── a-ns
│   └── kustomization.yaml
├── b-ns
│   └── kustomization.yaml
├── base
│   ├── kustomization.yaml
│   └── rbac.yaml
└── kustomization.yaml

# a-ns/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: a-ns

resources:
- ../base
---
# b-ns/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: b-ns

resources:
- ../base
---
# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- rbac.yaml
---
# base/rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: default
 name: pod-reader
rules:
- apiGroups: [""]
 resources: ["pods"]
 verbs: ["get", "watch", "list"]
---
#kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- a-ns
- b-ns

I'll close this issue. But if you have any problem related this, Please feel free to reopen and add comments!

/triage need-informations
/close

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.

[TheSpiritXIII]

@koba1t thanks for the quick reply!

Consider this example where there are two namespaces within a single resource:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: operator
  namespace: namespace2
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: operator
  namespace: namespace1
roleRef:
  name: operator
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: operator
  namespace: namespace2
  kind: ServiceAccount

With Kustomization:

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

How can I tell Kustomize to update only namespace2 to foo? Both namespace1 and namespace2 were changed to the same namespace foo.

I can use replacements to fix it but:

1. Replacements do not scale well when you have many resources with the same problem, making this solution error-prone. If the source manifest changes, I must also edit the replacement.
2. There are other resources besides RoleBinding where you may have multiple namespaces in a single resource. For example, anyone could create a custom resource and add it to the namespace transformer configuration.

I personally think it's silly that the namespace transformer can lookup and edit namespace references but you can't control how this behavior works.

I'd love to hear your thoughts. It's certainly an edge case so I understand if this can't be prioritized. Thanks!

[TheSpiritXIII]

/reopen

[k8s-ci-robot]

@TheSpiritXIII: Reopened this issue.

Details

In response to this:

/reopen

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.

[koba1t]

Hi @TheSpiritXIII

Sorry, I'm not sure I understand.
The RoleBinding resource that references other namespace resources is valid, and what does it mean?
I have concerns that the resource is not working correctly, and I can't find any documents on the k8s.io page....

[koba1t]

/triage needs-information

[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