Pre-registering a pod shape in the manifest to admit dynamically created pods without a manifest update

[strieflin]

Background

We are building a Kubernetes operator that provisions workloads on a Contrast-enabled cluster. The number of workload instances changes dynamically (addition and removel) over time as new tenants are onboarded.

We are using --disable-updates (immutable deployments). After the initial contrast set, the manifest is frozen: neither WorkloadOwnerPubKeys nor SeedshareOwnerPubKeys are retained. Calling contrast set again is not an option in our threat model.

The Problem

We need to launch new pod instances after the initial contrast set, without triggering a manifest update.

Question

Does Contrast's policy model support pre-registering a pod shape in the manifest at contrast generate / contrast set time, such that any pod created later is admitted if it matches that pre-registered shape?

Concretely: if we include a representative pod spec in the resources/ directory at generate time, will the Coordinator admit a pod that matches that spec's policy hash, even if the pod was created from a different Kubernetes object applied after contrast set, whose pod template is identical to the pre-registered one?

Or is the policy binding tied to the specific workload object identity (name, namespace, owner reference), not just the pod spec shape?

If shape-based admission is scoped to the originating workload object: is there an existing or planned mechanism in Contrast for registering a pod shape as a reusable policy entry, independent of any specific workload object?

Any pointers to the relevant documentation / source paths, or a clear statement of what the Coordinator checks at admission time, would be very helpful.

[burgerdev]

Hey @strieflin,

Thanks for the question! It's indeed been on my mind recently, and we're starting discussions upstream about how to accommodate third party pod-generating controllers in genpolicy. I assume there will be major changes to the policy mechanism in the long term, but the policy is a delicate component of the overall security story and thus hard to evolve.

Concretely: if we include a representative pod spec in the resources/ directory at generate time, will the Coordinator admit a pod that matches that spec's policy hash, even if the pod was created from a different Kubernetes object applied after contrast set, whose pod template is identical to the pre-registered one?

Your intuition is correct and this should work in theory, but there are some subtle bugs I just found when trying it out. Let me see whether I can make some low-hanging fruit work in Contrast v1.21!

Cheers, Markus

[burgerdev]

Ok, this is more complicated to support than I originally assumed, due to the several annotations that need to be transferred to the CRD and the modifications done to the podSpec itself (initializer and service mesh, for example). We will need to properly design this first, I'm afraid.

In the meantime, you could generate a simple, built-in resource (like ReplicaSet) and then transfer the modified podSpec to the CRD.