Conversation
…bs has the kueue label
| operator: AnyNotIn | ||
| value: | ||
| - default-queue | ||
|
|
There was a problem hiding this comment.
Just confirming that I understand correctly:
The problem is that it is possible for MPIJob to start pods without kyverno policies being applied.
This PR fixes the problem caused by the set-default-queuename rule not being applied. We force the label to be explicitly set in MPIJob and that gets propagated down to the pods that it creates.
That's OK since we expect MPIJob to only be used by "experts" so we don't mind if they need to add a little extra boiler plate.
What about other kyverno policies? Can they being skipped as well by MPIJob pods?
In particular, I'm concerned about any security related policies (eg pod-securitycontext, apply-posix-uid-label etc).
There was a problem hiding this comment.
Other Kyverno pod policies still apply to MPIJob created pods (I've included mpijob pods in my previous PR's). The only issue was with the set-default-queuename rule is if the queue label was not applied, the pods could start but would bypass Kueue.
This fixes that by requiring the label to be explicitly set on the MPIJob so it propagates to the pods.
All other policies pod security context are still applied, and pods will not start if those policies fail.
Adding default mutation policy only patches the mpijob resource, labels were not getting propogated to its pods. ( Kueue creates the pods before kyverno could patch it )
So this validates if the queue-label is manually added to the mpijob manifest