Allow providers to restrict accepted namespace mapping strategies #3307

Describe the problem you are having (if any)

Namespace mapping strategies are currently selected by the consumer through NamespaceOffloading.spec.namespaceMappingStrategy.

On the provider side, this choice is not easy to enforce as a policy. The provider mainly receives the resulting NamespaceMap entries, and rejecting NamespaceMap updates as a whole would be too coarse-grained: one update may contain both acceptable and unacceptable mappings, so valid mappings could be blocked as collateral damage.

Describe the solution you would like

I would like providers to be able to configure which namespace mapping strategies are accepted for a tenant, for example allowing only DefaultName while rejecting EnforceSameName or SelectedName.

The rejection should happen per namespace mapping entry, not per whole NamespaceMap object.

Describe the user value of this feature

This would give provider administrators better control over namespace creation on their clusters.

For example, a provider may want to allow namespace offloading only when remote namespace names are generated by Liqo using DefaultName, avoiding same-name conflicts or arbitrary namespace names chosen by consumers.

It would also make failures clearer for consumers, because rejected mappings could be reported explicitly in NamespaceMap or NamespaceOffloading status instead of appearing as generic namespace creation failures.

Describe your proposed solution

Introduce a provider-owned policy API, scoped to a tenant namespace, to define the accepted namespace mapping strategies. For example:

apiVersion: offloading.liqo.io/v1beta1
kind: TenantOffloadingPolicy
metadata:
  name: default
  namespace: <tenant-namespace>
spec:
  namespaceMapping:
    allowedStrategies:
    - DefaultName

Then propagate the requested mapping strategy through NamespaceMap, while keeping the current desiredMapping field for compatibility. One possible additive field is:

spec:
  desiredMapping:
    demo: demo-consumer-a
  desiredMappingStrategies:
    demo: DefaultName

The provider-side NamespaceMap controller would enforce the policy per entry:

1. Read the tenant offloading policy.
2. For each requested namespace mapping:
   • verify that the requested strategy is allowed
   • verify that the requested remote namespace name matches the declared strategy
   • create the namespace only if the mapping is accepted
   • otherwise mark only that mapping as refused in status

It may also be useful to add a dedicated status phase such as Refused, distinct from transient creation failures:

status:
  currentMapping:
    demo:
      remoteNamespace: demo
      phase: Refused
      reason: NamespaceMappingStrategyNotAllowed
      message: "Provider accepts only DefaultName namespace mappings"

I would avoid putting this policy directly in Tenant.spec. Although the proposed policy(TenantOffloadingPolicy) is tenant-specific, it is provider-owned offloading policy, while Tenant is primarily part of the authentication and peering flow and may be created or updated by consumer-driven workflows. Keeping this in a separate provider-owned resource would make ownership clearer and reduce the risk of provider policy being overwritten accidentally.

Do you volunteer to implement this feature?

• I want to implement this feature

Code of Conduct

• I agree to follow this project's Code of Conduct