feat: Add additionalMetadataList Support for Conditional Metadata Assignment

[Deofex]

Summary
This PR introduces support for additionalMetadataList, allowing cluster admins to define conditional labels and annotations for namespaces within a tenant. This enhancement builds upon the existing additionalMetadata functionality, providing more granular control through namespaceSelector expressions.

Changes Introduced

• Added support for additionalMetadataList in namespaceOptions, enabling selective metadata assignment based on namespace labels.
• Maintains existing additionalMetadata behavior, ensuring all namespaces receive global metadata if specified.
• Introduced namespaceSelector-based rules, allowing metadata to be applied only to namespaces that match specific conditions.
• Updated documentation to clarify the new functionality
• If multiple additionalMetadataList entries match a namespace, all applicable labels and annotations are assigned.

Example Configuration
Defining both global and conditional metadata in a tenant:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: oil
spec:
  owners:
    - name: alice
       kind: User
  namespaceOptions:
    additionalMetadata:
      labels:
        capsule.clastix.io/still-working: "true"
    additionalMetadataList:
      - labels:
          capsule.clastix.io/backup: "true"
      - namespaceSelector:
          matchExpressions:
            - key: capsule.clastix.io/low_security_profile
              operator: NotIn
              values: ["true"]
         labels:
           pod-security.kubernetes.io/enforce: baseline
      - namespaceSelector:
          matchExpressions:
            - key: capsule.clastix.io/low_security_profile
              operator: In
              values: ["true"]
         labels:
           pod-security.kubernetes.io/enforce: privileged

Impact & Compatibility
Fully backward compatible: Existing additionalMetadata configurations will continue to work as before.
New functionality is opt-in, meaning it does not affect existing tenants unless additionalMetadataList is explicitly configured.

[netlify]

✅ Deploy Preview for capsule-documentation canceled.

Name	Link
🔨 Latest commit	e5de5b8
🔍 Latest deploy log	https://app.netlify.com/sites/capsule-documentation/deploys/679c8ba21f12d500082f7a87

[oliverbaehler]

We'll have to do some discussions around this. I am currently refactoring to a generic CEL based approach which would also solve this case. But thanks for the commit for now, I will get back to it

[peterbosalliandercom]

@oliverbaehler Any news on the discussion? Our usecase for this is that we want to implement pod security baseline and restricted policies on specific namespaces (https://kubernetes.io/docs/concepts/security/pod-security-standards/). Is there any way we can speedup this feature request?

[oliverbaehler]

@peterbosalliandercom yes i get your use-case and it does make sense. However we want to move away from such specific implementations and refactor into more generic solutions, since they are technical dept. Such that we could eg. deprecated the additionalMetadata for pod, services etc. as well. A generic approach to having patches for any kind of manifests on tenant basis with given selector options. That's what i would aim for.

I will have to create a poc on the weekend and see how difficult that is to implement. Based on these findings we will either merge this as is and keep the prospect, that it will be deprecated in the v1 api bump or i will port the same functionality to that generic feature.

Make sense?

[prometherion]

Is there any way we can speedup this feature request?

Generally speaking, we're always happy to receive newer contributions: we have limited resources to allocate to the project, especially considering the efforts in reviewing code from non-maintainers.

Remember that Capsule is backed by two vendors (CLASTIX and PeakScale) which offer features prioritisations as well as other professional services, and addons.

I am currently refactoring to a generic CEL based approach which would also solve this case.

We should go toward CEL and drop support of custom handlers where it is possible: @maxgio92 started a PoC with VAP/CEL while working at CLASTIX.