Secure configs across environments

When making security-related changes, ensure the configuration is (1) least-privilege/scoped, (2) actually enforced by the platform, and (3) consistent across code/docs.

Apply this standard:

• Scope secrets/tokens narrowly: don’t add sensitive tokens to release/runtime job env unless the release jobs truly need them. Prefer using them only in dedicated test/integration jobs.
• Make non-root enforcement verifiable: if you set runAsNonRoot: true, the kubelet must be able to verify the container’s non-root user. Avoid cases where the image uses a non-numeric/named USER.
• Use numeric UIDs for USER when runAsNonRoot is enabled (or ensure the platform can otherwise verify). If you need deterministic behavior across k8s distros, set a numeric UID in the Dockerfile, and align podSecurityContext with your storage-class behavior.
• Validate Helm rendering/merge behavior: changes like switching podSecurityContext to {} can behave unexpectedly due to Helm map merges—always confirm the rendered securityContext with helm template.
• Keep security defaults in schema/docs aligned with code: don’t adjust documented defaults without updating the code default, especially for auth/security parameters.

Example (numeric UID to satisfy kubelet verification):

# Ensure kubelet can verify non-root when runAsNonRoot: true
USER 1000:0

Example (scope secrets to test jobs):

# Only provide sensitive tokens where they are required (e.g., PR test jobs)
# Avoid injecting tokens into broad release job env blocks.
env:
  # GITHUB_COPILOT_TOKEN: ${{ secrets.GITHUB_COPILOT_TOKEN }}  # keep out of release jobs