-
Notifications
You must be signed in to change notification settings - Fork 0
Security and Hardening
Jul.IA sits between untrusted clients and operator-selected services.
- Client requests, headers, paths, bodies, tokens, and client certificates are untrusted.
- The configuration, binary, host filesystem, and private keys are trusted operator assets.
- Upstreams are selected by configuration and should be authenticated according to the deployment's risk.
The core security invariant is that request input must not widen configuration-controlled destinations or privileges.
- Terminate TLS at the edge and choose an appropriate minimum version.
- Set request body and timeout bounds for internet-facing listeners.
- Authenticate sensitive routes at the edge.
- Keep the admin listener on loopback or behind a strong protected boundary.
- Use a strong admin secret or the supported scoped access model.
- Prefer
${env:...},${file:...}, or${secret:...}references over inline credentials. - Run Jul.IA as an unprivileged account with narrowly scoped writable directories.
- Persist and protect certificate, configuration, and history state.
- Consider an egress allow-list for configuration-driven auxiliary fetches.
- Validate the exact binary/configuration pair with
jul checkbefore deployment.
Release verification, checksums, SBOMs, and provenance are documented in the release guide. Dependency and CI policy are maintained in the repository rather than repeated here.
Security behavior differs across TLS, authentication, mTLS, caching, WAF, plugins, discovery, gRPC, and the admin plane. Follow the threat-note index in SECURITY.md before enabling a security-sensitive capability.
Do not report vulnerabilities in a public issue. Use the repository Security tab and its private vulnerability-reporting flow. Include the affected version or commit, build profile/tags, a minimal reproducer, and observed impact.