Allow annotations and labels to be specified in KubernetesResourceRequirements IF they have been allow-listed using a server config. The reason we need to have an allow-list is that allowing the user to arbitrarily specify annotations and labels can contain foot-guns (ex: a user specifying a label of sematic.ai/component: api might wind up having their pod be considered part of the Sematic k8s service object). In the worst case, they can contain security holes (ex: an annotation of kubernetes.io/psp: eks.privileged).
Testing
Deployed a server with this code to staging. Then:
re-ran an old pipeline execution from the UI to confirm it still worked.
Ran the testing pipeline with custom runner resources and confirmed that the specified annotations and labels appeared (except for the ones that were not allow-listed).
Modified the testing pipeline to launch a worker pod with resources specifying custom annotations and labels. Confirmed the approved ones appeared on the resulting pod.
Allow annotations and labels to be specified in
KubernetesResourceRequirementsIF they have been allow-listed using a server config. The reason we need to have an allow-list is that allowing the user to arbitrarily specify annotations and labels can contain foot-guns (ex: a user specifying a label ofsematic.ai/component: apimight wind up having their pod be considered part of the Sematic k8s service object). In the worst case, they can contain security holes (ex: an annotation ofkubernetes.io/psp: eks.privileged).Testing
Deployed a server with this code to staging. Then: