Eden VPN

Eden VPN exposes Eden Gateway interlays over standard WireGuard clients. It is a private transport for existing Eden-governed endpoint access, not a general-purpose replacement for a corporate VPN.

Use it when a human, agent, or workload needs private network reachability to Eve native gateway listeners while Eden still owns endpoint identity, RBAC, endpoint-level security, masking, audit, and route policy.

What It Enables

CapabilityBehavior
Native client accessDBeaver, psql, mysql, Redis clients, application workers, and scripts keep using native protocols.
Private reachabilityDatabases can stay private to the Eden node while users connect to an Eden-owned tunnel IP.
Per-user governanceEach WireGuard peer maps to a concrete Eden user or agent subject.
Existing authorizationEndpoint RBAC or ELS remains the final permission decision. VPN routes do not grant access.
Scoped maskingAuth-group and user-scoped masking can apply to native client traffic after the peer identity is resolved.
Safe client configRendered WireGuard configs include only routes the peer subject can use. Eden never stores client private keys.

Operator Flow

  1. Create a VPN network owned by one Eden node.
  2. Register a peer with a WireGuard public key and Eden user or agent subject.
  3. Create or select an interlay listener bound to a VPN tunnel IP.
  4. Register the owning Eden node in the endpoint node pool.
  5. Create a VPN route for the listener with an optional maximum data-permission ceiling.
  6. Render a WireGuard client config for the peer.

API Surface

text
POST   /api/v1/vpn/networks
GET    /api/v1/vpn/networks
DELETE /api/v1/vpn/networks/{network_uuid}
POST   /api/v1/vpn/networks/{network_uuid}/peers
GET    /api/v1/vpn/networks/{network_uuid}/peers
PATCH  /api/v1/vpn/peers/{peer_uuid}
DELETE /api/v1/vpn/peers/{peer_uuid}
GET    /api/v1/vpn/peers/{peer_uuid}/config
POST   /api/v1/vpn/networks/{network_uuid}/routes
GET    /api/v1/vpn/networks/{network_uuid}/routes
DELETE /api/v1/vpn/routes/{route_uuid}

Endpoint placement APIs support multi-node route validation:

text
GET /api/v1/endpoints/{endpoint}/nodes
PUT /api/v1/endpoints/{endpoint}/nodes/{eden_node_uuid}

Safety Model

  • Server private keys are referenced by server_private_key_ref; private key bytes are not submitted to the API.
  • Clients generate and keep their own WireGuard private keys.
  • Route max_data_perms can only lower effective permissions.
  • Peer revocation removes the peer from future reconciliation and invalidates the VPN identity cache.
  • Existing TCP sessions keep the subject resolved at connection acceptance; endpoint RBAC changes still flow through normal cache checks.

Route Authorization

VPN routes expose only selected Eve listeners to selected peers. A route can cap effective data-plane permissions through max_data_perms, but it cannot grant permissions the subject does not already have through endpoint RBAC or endpoint-level security.

Rendered client configs include allowed routes for the peer subject. If a peer loses endpoint access, future route reconciliation and normal authorization checks prevent continued access even if the client still has an old tunnel configuration.

Operating Guidance

Keep one VPN network scoped to an Eden node and use endpoint node placement to make route ownership explicit. Treat peer registration like any other credential issuance workflow: verify the subject, require client-owned private keys, rotate routes deliberately, and revoke peers when user or agent access changes.

Related Docs

Last updated: July 10, 2026