Security boundaries
Understand Lifecycle authentication, network, Kubernetes, secret, and Agent boundaries before other networks can reach a deployment.
The default chart configuration is not a production security profile. Complete the following inspection before users or shared networks can reach Lifecycle.
Authentication boundary
Use ENABLE_AUTH=false only for an isolated local evaluation. With this
value, requests get administrator permissions, and API-key bearer tokens do
not work. Do not make this configuration reachable from a shared network.
The stock installation is not a complete authentication-on profile for shared-network exposure. Before exposure, use a versioned authentication procedure for the installed release. The procedure must protect the API, UI, and identity provider together. If the release does not supply this procedure, keep the deployment isolated.
After configuration, test browser sessions, API bearer tokens, API keys, roles, and user synchronization.
Predeployment inspection
| Boundary | Check |
|---|---|
| Kubernetes RBAC | The chart’s default ClusterRole uses wildcard permissions. |
| Network | Web and worker NetworkPolicies default off. |
| Pod security | Default container settings are not a hardened restricted profile. |
| Ingress and TLS | Core API, UI, auth, wildcard Environment, and optional Site hosts have different exposure needs. |
| Secrets | Helm values/history and broad diagnostic commands can leak credentials. |
| Encryption key | A Secret contains the generated 64-hex-character key. Lifecycle needs the key to decrypt stored ciphertext. |
| GitHub App | Requested write permissions and webhook events must agree with enabled capabilities. |
| API | Use authenticated v2. Reachable v1 endpoints are not a supported automation interface. |
| Agents and MCP | Tool permissions, approvals, external connections, workspace egress, and session review expand the trust boundary. |
| Backups | Recovery must include database, key material, and object storage together. |
Private Sites
Sites management requires authentication even on an authentication-disabled deployment. Disabling authentication does not expose private site content. Public site content remains readable without signing in.
Content domain
Use HTTPS for both the Lifecycle UI and Sites content.
A separate registrable content domain gives stronger isolation from the UI.
For example, ui.example.com and report.example.net use separate domains.
Internal deployments can use sibling hosts by setting SITES_ALLOW_SHARED_APEX=true on both web and gateway.
This opt-in keeps the two hosts on the same browser site and does not provide separate-domain isolation.
Storage and routing
Keep object storage private and inaccessible through public bucket URLs. Route every content request through the authorization-capable gateway. Do not cache private content or serve it through an older gateway. A private site’s content requires its owner and a valid browser session.
None of these grant access on their own:
- A copied URL
- An administrator role
- An unrelated API key
How access grants work
Core verifies the user’s JWT, identity status, and Site ownership before issuing browser access. The browser receives Site-only access that expires within five minutes and no later than the authorizing JWT. Each private content request checks that grant and the current Site owner, access state, and availability. Content cookies contain no reusable OAuth access token or refresh token. Private asset requests do not contact Keycloak for each file.
Protect Redis access. Missing authorization records prevent private access. See Sites configuration for dependency requirements.
Browser compatibility
Private content blocks the following:
- Web Workers
- SharedWorkers
- New service workers
- Display inside an iframe
Applications that require these features need a compatible site build. An existing service worker from a public version of the same site can remain in a visitor’s browser. For sensitive content, create a new private site instead of making that public site private.
Vulnerability reporting
No private vulnerability-reporting channel is published. Do not post suspected vulnerabilities, tokens, private logs, or exploit details in a public issue. Contact your deployment owner through an approved private channel.