James/security enhancements CEL policy update

[JPurcell-Braintrust]

Adding in the previous security enhancements to fix CEL based policy breaches, previously based on 1.1.32 to the latest helm updates. The security enhancements were:

• add securityContext and podSecurityContext to all 3 pod types
• readOnlyRootFilesystem
• emptyDir size limits for Brainstore volumes

An example/google-autopilot-cel/ has been created to help the known customers currently needing these CEL enhancements in their production environment.

[Alexey Soldatchenko (soldatchenko)]

Overall this looks good to me. My only asks are around runtime validation rather than the Helm config itself

• confirm the read-only root filesystem with representative API/scorer + Brainstore trace paths
• make sure the Brainstore emptyDir.sizeLimit leaves enough headroom above the configured cache size in the example

[Alexey Soldatchenko (soldatchenko)]

I spent some time comparing this against the current AKS/GKE behavior. AKS uses Azure Container Storage via ephemeral PVCs, and GKE Autopilot uses pod-local emptyDir with ephemeral-storage requests and local-SSD placement. In both cases, Brainstore’s local cache is expressed as k8s-managed pod-local storage.

The new brainstore.storage.hostPath path is different: if the EKS module sets it, brainstore depends on a raw node filesystem path prepared outside the chart. I think the EKS path should match the AKS/GKE model if technically feasible, likely via EKS Auto Mode with a brainstore-specific NodePool/NodeClass, Brainstore emptyDir, and explicit ephemeral-storage requests.

I think we should remove the hostPath path if EKS Auto Mode is viable. The EKS direction should match AKS/GKE: Brainstore emptyDir, explicit ephemeral-storage requests, and a brainstore-specific EKS Auto Mode NodePool/NodeClass for NVMe-backed capacity.

[Alexey Soldatchenko (soldatchenko)]

Same comment for readers/writers