Repository navigation
Let a namespace owner generate cluster-scoped objects - #145
ps-pufferfish wants to merge 2 commits into
Conversation
Namespace mode refused cluster-scoped output, so a repository that owns one namespace could not ship the CustomResourceDefinition its own custom resources need: the CRD had to live in the system repository, splitting a version bump that has to be atomic across two repositories. Routing cluster-scoped objects to the owned root instead of cluster/ keeps the one-owner-per-directory invariant that makes namespace ownership safe, rather than granting an owner write access to a shared directory. A directory name has no bearing on an object's scope, so the manifests apply the same either way.
Routing cluster-scoped output into the owned root let an owner generate any cluster-scoped kind, so a repository confined to one namespace could mint itself a ClusterRoleBinding and ArgoCD would apply it. A CRD is the one cluster-scoped kind that grants nobody anything, and is all an owner needs to ship its own custom resources. The check reads what was written rather than filtering as it is written, because a config block may write its files itself and would then never reach it.
|
Recording why this was closed unmerged, since the reasoning is worth keeping if the case comes back. The Teleport work this was for now lives in portswigger-cloud/system, which generates in system mode and so was never subject to the namespace-owner restriction this relaxed. With no consumer, the net effect would be to permit a namespace owner to emit cluster-scoped objects and then constrain what it may emit. Two findings from it that still hold: Cluster-scoped output from a namespace owner belongs in the owner's own root, not a shared And such an owner should be able to emit a |
2 participants
Namespace mode rejected cluster-scoped output, so a repository owning one namespace could not ship the CRD its own custom resources need — the CRD had to live in the system repository, splitting a version bump that has to be atomic.
Cluster-scoped objects now land in the owned root rather than
cluster/, so the one-owner-per-directory invariant is unchanged and no owner gets write access to a shared directory. System mode is unaffected. Blocks that route output takecontext.cluster_rootinstead of assumingcluster/.