Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add additionalMetadataList Support for Conditional Metadata Assignment #1339

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Deofex
Copy link

@Deofex Deofex commented Jan 31, 2025

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.

Copy link

netlify bot commented Jan 31, 2025

Deploy Preview for capsule-documentation canceled.

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

@Deofex Deofex force-pushed the additional_metadata_list_support branch from 821eb00 to a9a7b02 Compare January 31, 2025 08:25
@Deofex Deofex changed the title Add additionalMetadataList Support for Conditional Metadata Assignment feat: Add additionalMetadataList Support for Conditional Metadata Assignment Jan 31, 2025
Signed-off-by: Deofex <28751252+Deofex@users.noreply.github.com>
@Deofex Deofex force-pushed the additional_metadata_list_support branch from a9a7b02 to e0d1bae Compare January 31, 2025 08:31
@Deofex Deofex changed the title feat: Add additionalMetadataList Support for Conditional Metadata Assignment feat: Add additionalMetadataList Support for Conditional Metadata Assignment Jan 31, 2025
Signed-off-by: Deofex <28751252+Deofex@users.noreply.github.com>
@oliverbaehler oliverbaehler self-requested a review January 31, 2025 09:09
@oliverbaehler
Copy link
Collaborator

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
Copy link

@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
Copy link
Collaborator

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants