Validate security context

Define and enforce security-context behavior as a clear contract, then implement CI/runtime logic to match it without brittle assumptions.

Apply this in two places:

1) Helm/manifest security-context checks (CI)

• Assert the contract (e.g., “default render does not pin runAsUser”), not a magic UID number.
• Prevent substring false positives by using anchored match patterns.
• Scope checks to the exact template(s) whose output you intend to validate, and repeat the same assertions for every render mode (sqlite/deployment/postgres/etc.).

Example pattern:

# contract: default render must not set runAsUser
helm template bifrost ./helm-charts/bifrost \
  --set image.tag=v1.0.0 \
  > /tmp/out.yaml

if grep -Eq '^[[:space:]]+runAsUser:[[:space:]]*' /tmp/out.yaml; then
  echo "Fail: runAsUser must not be pinned in default render"
  exit 1
fi

2) Startup permissions (runtime)

• Don’t assume the container has privilege to chown/fix ownership (avoid CAP_CHOWN-dependent correctness).
• Use an actual writability probe for the target data dir, create it when possible, and if it’s not writable, fail early with actionable, platform-aware guidance.
• Avoid advising securityContext values that may be rejected by the target platform’s admission controller (e.g., OpenShift fsGroup constraints).

Net effect: fewer admission/runtime surprises and fewer CI “green but wrong” security-context failures.