Feature request: Support configurable namespace prefix enforcement for tenant namespaces

[aslafy-z]

Describe the feature

Add a way to enforce a configurable namespace prefix (or prefix pattern) for Namespaces managed by Capsule, in addition to the current forceTenantPrefix behavior.

Today, forceTenantPrefix enforces that all Namespaces of a Tenant start with <tenantName>-....

In some environments we would like a stronger convention, for example:

• Namespaces for customer-facing tenants must start with cust-...
• Namespaces for internal/platform tenants must start with plat-...

Concretely, this could look like:

• A global option (in CapsuleConfiguration) to specify an allowed namespace prefix pattern, or
• A per-Tenant option (in Tenant.spec) like namespaceOptions.namespacePrefix or similar.

The goal is to have Capsule reject Namespaces that do not respect these prefixes when they are attached to a Tenant.

What would the new user story look like?

How would the new interaction with Capsule look like? E.g.

1. Cluster admin enables and configures prefix enforcement:
   • Globally (CapsuleConfiguration) and/or
   • Per Tenant (e.g. spec.namespaceOptions.namespacePrefix: "cust-" or "plat-").
2. A Tenant owner (or controller using Capsule) creates a new Namespace to attach to a Tenant.
3. Capsule admission checks:
   • The Namespace belongs to the Tenant.
   • The Namespace name starts with the configured prefix (for example cust-foo-... or plat-bar-...).
4. If the prefix is correct, Namespace creation succeeds and the Namespace is attached to the Tenant as usual.
5. If the prefix does not match, Capsule denies the request with a clear validation error explaining that the Namespace name does not match the required prefix.
6. All this works consistently regardless of whether the Namespace is created via:
   • kubectl create namespace ...
   • GitOps tools (Argo CD, Flux, etc.)
   • Other controllers that create Namespaces on behalf of the Tenant.

This could be combined with the existing forceTenantPrefix behavior or be an alternative mode, depending on how you see it fit in the design.

Expected behavior

• When prefix enforcement is configured:
  • Any attempt to create a Namespace attached to a Tenant that does not start with the required prefix is rejected.
  • The rejection message clearly explains which prefix is required.
• Namespaces that comply with the prefix rule are accepted and work as usual with Capsule.
• This makes Namespaces easier to visually group in:
  • kubectl get ns output
  • Cluster dashboards
  • Logs and audit trails
• The feature is opt-in:
  • If not configured, Capsule behaves exactly as today and there is no breaking change.
  • When enabled, it allows platform teams to standardize naming conventions across many Tenants and keep the global namespace list more organized.

[oliverbaehler]

Not sure how much of a fan I am of this proposal. The reason is that we can already control collisions based on the fact, that tenant names must be unique. The proposed approach would only reliably work if every namespace then has the tenant associated via label, which we could do. However why aren't you just naming the customer tenants eg cust-tenant-x, it would probably lead to the same result if i am not misunderstanding

[prometherion]

Or, it could be leveraged on a Validating Admission Policy according to the assigned labels we have in the mutating webhook: validation happens after mutations occurred.