pine-gate ships with secure defaults and is designed to sit behind your platform’s ingress and policy controls.

• Abuse and volumetric attacks: high request rates, long‑lived connections, oversized bodies.
• Credential risks: API key leakage, weak admin controls, secrets exposure.
• Lateral movement: exposing /metrics or admin endpoints to untrusted networks.
• Supply chain/runtime risks: image privileges, capabilities, dependency vulnerabilities.

• Least privilege container: distroless, non‑root user, read‑only filesystem, capabilities dropped, seccomp: RuntimeDefault.
• Sensible server timeouts: read, write, and idle timeouts configured in the server.
• Authentication: API key required for /v1/*; separate admin key for /v1/usage.

• Place the gateway behind an Ingress, API gateway, or service mesh that terminates TLS.
• Expose only the Service; do not publish the Pod directly.
• Restrict source networks with a NetworkPolicy. See deployments/k8s/networkpolicy.yaml for a starter policy.
• Keep /metrics internal (scraped by Prometheus). Avoid exposing /metrics publicly.

• Store API_KEY and admin key in Kubernetes Secrets (chart provides wiring). Rotate periodically.
• Avoid committing .env with secrets; keep examples in .env.example.
• Prefer per‑environment API keys over sharing a single global key.

• Enforce a maximum request body size for /v1/completions to avoid memory pressure (e.g., http.MaxBytesReader).
• Set ingress/LB limits for header size and body size; consider timeouts for slowloris protection.
• Limit streaming duration if necessary via ingress proxy settings (read timeout).

• Enable Redis‑backed limiting in production for consistent per‑key enforcement across replicas.
• Consider a light pre‑auth throttle at the edge (e.g., per‑source IP) to blunt credential‑guessing.
• Monitor 429 rates and adjust token bucket settings to match your capacity and business rules.

• Keep detailed logs internally; avoid logging secrets or full prompts when logs leave your trust boundary.
• Export traces over TLS when the collector is outside your cluster or trust domain.
• Tag traces/metrics with minimal necessary labels to avoid leaking sensitive model names if that’s a concern.

• Use the provided distroless image or rebuild with a trusted base; pin versions and digest where possible.
• Scan images for CVEs in CI; keep dependencies up to date.
• Run with a read‑only root FS and no privilege escalation (enabled by default in the chart/manifests).

• /v1/usage requires an admin key; keep it off public networks and protect with NetworkPolicy.
• If you introduce dynamic configuration in the future, validate backend base URLs to prevent SSRF and restrict to allowlists.