SecurityContext missing from dynamically created pods in v0.6.15

[vijaykumar-vakkalagadda]

What you would like to be added?

Summary:
Even after defining valid pod-level security contexts in the binder deployment, the resource-reservation controller attempts to create new pods without inheriting the defined security context, resulting in admission failures in EKS with restrictive PSP policies.

Version:

• KAI-Scheduler: v0.6.15
• Environment: AWS EKS 1.29
• Binder Deployment configured with:

  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    runAsGroup: 1001
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
    capabilities:
      drop: ["ALL"]
    seccompProfile:
      type: RuntimeDefault
  

Why is this needed?

In tightly secured Kubernetes environments such as Amazon EKS, all pods must explicitly define a compliant securityContext.
Currently, the KAI Binder’s resource-reservation component dynamically creates pods without inheriting the security context defined in the binder deployment.
This causes admission webhook failures from Gatekeeper/OPA policies, preventing GPU-sharing workloads from being scheduled successfully

[enoodle]

To implement it one should pass this securityContext to the binder pod somehow, and then to the resource reservation service which will add it to the reservation pods. Similar to this PR: #569
The challenge here is how to pass the securityContext in a compact manner.