Useful or not, from you.
capsule Support Any Additional resource

<!-- Yay, it look you're enjoying Capsule and, first, thanks for that!

We're trying to build a community drive Open Source project, so don't hesitate proposing your enhancement ideas: keep in mind, since we would like to keep it as agnostic as possible, to motivate all your assumptions.

If you need to reach the maintainers, please join the Clastix Slack workspace:, #capsule channel.

Describe the feature

I would like to have a generic approach on resources, which are created for each new namespace belonging to a tenant. The same behavior that .spec.additionalRoleBindings and .spec.networkPolicies already implement, but for any kubernetes resource.

As of why:

We are currently moving to Cilium Network Policies, and we would require each namespace to implement those policies (same could also apply for calico resources or really anything else). So instead of writing an own workaround, it would make sense to be able to declare something like this:

kind: Tenant
  name: gas
    -  apiVersion: ""
       kind: CiliumNetworkPolicy 
         name: "l3-rule"
             role: backend
       - fromEndpoints:
         - matchLabels:
             role: frontend

What would the new user story look like?

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

  1. A new Tenant is created with additional resources
  2. The resources could be validated on tenant creation and reject the tenant creation if there's an error, if not the tenant is created.
  3. A new User creates/assigns a new namespace to the previously created tenant.
  4. the additional resources are added to the namespace once the operator has reconciled.
  5. Everyone is happy.

Expected behavior

A clear and concise description of what you expect to happen.

When I have defined .spec.additionalResources on a tenant, those resources are created for each namespace that is assigned or created in that tenant.

That's a useful answer
Without any help

@oliverbaehler thanks for suggesting this improvement. I think this will require some sort of refactoring of the code. Let's to see what @prometherion says.