security: require auth to create a tenant (POST /v1/tenants) - #33
Open
doctatortot wants to merge 1 commit into
Open
security: require auth to create a tenant (POST /v1/tenants)#33doctatortot wants to merge 1 commit into
doctatortot wants to merge 1 commit into
Conversation
`POST /v1/tenants` is mounted on `public_routes`, i.e. outside the `auth_middleware` route_layer. `create_tenant` creates a tenant and returns its id as a working API key, so any client that can reach the server can mint an active tenant + key with a single unauthenticated request. On a self-hosted LAN deployment that is every device on the network; the memory store's tenant isolation is only as strong as "who can obtain a key," and right now anyone can. Move the route onto `authed_routes` so a caller must present a valid `X-API-Key` to create another tenant. `/health` and the GitHub webhook (HMAC-verified in its own handler) stay public. Tradeoff: this yields an "any active tenant may mint another tenant" model rather than true admin-gating. For a single-operator instance that closes the real exposure (anonymous minting). If per-instance admin control is wanted, a follow-up could gate `create_tenant` behind a dedicated bootstrap/admin token from an env var instead of the shared auth layer. Bootstrap note: existing tenants are unaffected. After this change the first tenant on a fresh instance must be seeded out-of-band (admin token or a direct store insert), since there is no longer an anonymous creation path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
POST /v1/tenantsis mounted onpublic_routes— outside theauth_middlewareroute_layer.create_tenantcreates a tenant and returns its id as a working API key, so any client that can reach the server can mint an active tenant + key with a single unauthenticated request. On a self-hosted LAN deployment that is every device on the network; tenant isolation is only as strong as "who can obtain a key," and today anyone can.Change
Move the route onto
authed_routesso a caller must present a validX-API-Keyto create another tenant./healthand the GitHub webhook (HMAC-verified in its own handler) stay public. One-file change, +8/−1.Tradeoff
This yields an "any active tenant may mint another tenant" model rather than true admin-gating. For a single-operator instance that closes the real exposure (anonymous minting). A follow-up could gate
create_tenantbehind a dedicated bootstrap/admin token from an env var if per-instance admin control is wanted.Bootstrap note
Existing tenants are unaffected. After this change the first tenant on a fresh instance must be seeded out-of-band (admin token or direct store insert), since there is no longer an anonymous creation path.