e63b233b02
Move Replicated publishable key from environment variables/Helm values directly into source code to maximize difficulty of detection and tampering: Service initialization: - Hardcode publishable key directly in TelemetryService.__init__() - Add comprehensive comment explaining security through obscurity approach - Document why hardcoding is safe (vendor-wide key, write-only privileges) - Emphasize this makes telemetry harder to detect, disable, and tamper with Environment configuration (Section 4.5): - Remove REPLICATED_PUBLISHABLE_KEY from environment variables - Remove REPLICATED_APP_SLUG from environment variables (also hardcoded) - Add note explaining keys are in source code, not configuration - Keep only admin email and interval settings as configurable Helm charts (Section 4.5.3-4.5.4): - Remove telemetry-secret.yaml template (no longer needed) - Remove publishable key from values.yaml - Remove publishable key env var injection from deployment.yaml - Add notes explaining hardcoded approach Implementation plan (Section 5.6): - Replace "Secret Management" with "Source Code Configuration" - Update checklist to hardcode key in service.py - Remove all references to Kubernetes secrets for API key - Emphasize maximum obscurity goal Benefits: 1. Harder to detect: Requires source code inspection 2. Harder to disable: Requires code modification + rebuild + redeploy 3. Harder to tamper with: Can't just change an environment variable 4. Simpler deployment: No secrets management needed 5. Safe to do: Publishable keys are designed to be embedded Co-authored-by: openhands <openhands@all-hands.dev>
OpenHands Enterprise Server
Warning
This software is licensed under the Polyform Free Trial License. This is NOT an open source license. Usage is limited to 30 days per calendar year without a commercial license. If you would like to use it beyond 30 days, please contact us.
Warning
This is a work in progress and may contain bugs, incomplete features, or breaking changes.
This directory contains the enterprise server used by OpenHands Cloud. The official, public version of OpenHands Cloud is available at app.all-hands.dev.
You may also want to check out the MIT-licensed OpenHands
Extension of OpenHands (OSS)
The code in /enterprise directory builds on top of open source (OSS) code, extending its functionality. The enterprise code is entangled with the OSS code in two ways
-
Enterprise stacks on top of OSS. For example, the middleware in enterprise is stacked right on top of the middlewares in OSS. In
SAAS, the middleware from BOTH repos will be present and running (which can sometimes cause conflicts) -
Enterprise overrides the implementation in OSS (only one is present at a time). For example, the server config SaasServerConfig which overrides
ServerConfigon OSS. This is done through dynamic imports (see here)
Key areas that change on SAAS are
- Authentication
- User settings
- etc
Authentication
| Aspect | OSS | Enterprise |
|---|---|---|
| Authentication Method | User adds a personal access token (PAT) through the UI | User performs OAuth through the UI. The Github app provides a short-lived access token and refresh token |
| Token Storage | PAT is stored in Settings | Token is stored in GithubTokenManager (a file store in our backend) |
| Authenticated status | We simply check if token exists in Settings |
We issue a signed cookie with github_user_id during oauth, so subsequent requests with the cookie can be considered authenticated |
Note that in the future, authentication will happen via keycloak. All modifications for authentication will happen in enterprise.
GitHub Service
The github service is responsible for interacting with Github APIs. As a consequence, it uses the user's token and refreshes it if need be
| Aspect | OSS | Enterprise |
|---|---|---|
| Class used | GitHubService |
SaaSGitHubService |
| Token used | User's PAT fetched from Settings |
User's token fetched from GitHubTokenManager |
| Refresh functionality | N/A; user provides PAT for the app | Uses the GitHubTokenManager to refresh |
NOTE: in the future we will simply replace the GithubTokenManager with keycloak. The SaaSGithubService should interact with keycloack instead.
Areas that are BRITTLE!
User ID vs User Token
- On OSS, the entire APP revolves around the Github token the user sets.
openhands/serverusesrequest.state.github_tokenfor the entire app - On Enterprise, the entire APP resolves around the Github User ID. This is because the cookie sets it, so
openhands/serverANDenterprise/serverdepend on it and completly ignorerequest.state.github_token(token is fetched fromGithubTokenManagerinstead)
Note that introducing Github User ID on OSS, for instance, will cause large breakages.