Skip to content

Add denylist for system namespaces in targetNamespace validation #3248

@vdemeester

Description

@vdemeester

Description

The targetNamespace field on TektonConfig (and other Tekton component CRDs via CommonSpec) currently lacks validation against well-known system namespaces. While existing controls (read-only shipped RBAC, singleton enforcement, immutability after creation, auto-creation defaults) make misuse unlikely, adding a denylist is a sensible defense-in-depth measure.

Current Behavior

In pkg/apis/operator/v1alpha1/common_validation.go, the only validations on targetNamespace are:

  • Must be non-empty
  • On OpenShift only: openshift-operators is blocked

On Kubernetes, any non-empty namespace is accepted.

Proposed Change

Add a denylist in CommonSpec.validate() that rejects the following namespaces on both platforms:

  • kube-system
  • kube-public
  • kube-node-lease
  • default

On OpenShift, additionally keep the existing openshift-operators check and consider also blocking openshift-* prefixed namespaces (aligning with the existing NamespaceIgnorePattern regex used in the RBAC reconciler).

This should apply to all components using CommonSpec (TektonConfig, TektonPipeline, TektonTrigger, TektonChain, TektonResult, TektonHub, etc.).

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategorizes issue or PR as related to a new feature.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions