# Security boundary and migration

## Console

WHMCS verifies the current selected account, service owner/server, active status, delegated permissions, product setting, POST nonce and VM mapping. Non-owner delegates need `manageproducts` and `productsso` for console. A service lock serializes launch authorization with lifecycle actions.

The signed grant selects exactly one server/node/VM and expires after 60 seconds. The gateway consumes it once and limits each connection to 15 minutes, including active traffic. The browser receives only a transient VNC challenge password and its console-scoped gateway cookie, never a Proxmox account password, API token or `PVEAuthCookie`.

The technical broker token remains server-side and has only `VM.Console` on the intended pool/VMs. Its compromise exposes those consoles; a stolen WHMCS signing key permits forged grants within the configured server/node allowlist. Secure both hosts and keep the provisioning credential separate.

Ephemeral access uses expiring capabilities, not creation/deletion of a PVE user per click. Avoiding account churn prevents the old shared-user ACL-loss problem. The persistent technical broker identity is never a customer identity.

Suspend/terminate/reinstall revoke active sessions first; if configured revocation is unavailable, the action fails explicitly before VM mutation. Pre/post service-edit hooks revoke the old server/service tuple around ownership/server edits. Reassignment outside supported hooks needs explicit revocation. Logout/removing delegated rights alone does not terminate an already-open console; the hard session deadline remains 15 minutes.

Run one gateway process only: replay/revocation state is local and bounded. Restart closes sessions and rejects grants issued at/before its startup second. Synchronize clocks. Expose the dedicated console origin to customers and allow gateway-to-PVE HTTPS privately. These files do not change firewall, DNS or endpoint exposure.

## Legacy PVE users

The candidate stops creating/disclosing customer passwords but **does not invalidate already-known passwords or general PVE tickets**.

1. Inventory service/VM mappings and existing `client<ID>@pve` ACLs, including multiple services, inherited/group permissions and unrelated uses. Never bulk-delete users by name prefix.
2. Prove new console access with the broker and migrate only verified VPSs into its pool.
3. Remove reviewed legacy permissions to these VMs and disable dedicated legacy users without other intended uses. Reconcile inherited permissions and existing tickets. Never delete/recreate a shared user to change its password.
4. Restrict direct PVE management access from customers/public networks once the gateway is ready. Changing a displayed password alone is insufficient for old authentication tickets.
5. Then clear stale PVE passwords from fields/email templates. Keep needed evidence private. Remove web-served `.bak`, ZIP, logs and old helper files; add server deny rules and verify 403/404 while normal module assets continue working.

No migration action is automatically performed on installation. `FixPermissions`/direct panel login no longer grant customer access. The normal VPS guest password remains available to its owner; it is separate from PVE management credentials.

## Provisioning and infrastructure

Only WHMCS-resolved paid resource options may override resources/OS. Customer custom fields cannot override security policy. VM routing fields must be administrator-only and unambiguous. New clones have random durable ownership markers; unknown VMs are never adopted or deleted as automatic rollback. Required firewall/API failures block startup and retain recovery data.

API success verifies intended firewall configuration, not actual packet isolation. Cluster firewall enablement/backend, DHCP, bridges/VLANs, templates and guest updates need their own operational checks. Provisioning requires broader rights than the console broker and complete relevant cluster inventory; PVE may return a filtered successful inventory to underprivileged tokens. The module never logs API bodies/credentials or exception traces; also disable PHP exception argument logging and protect host/WHMCS logs.

## Platform updates

Keep WHMCS, PHP, Proxmox and payment integrations on supported, patched versions.
Review vendor security advisories as part of installation and maintenance. This
module cannot repair vulnerabilities in WHMCS core or unrelated integrations;
plan and test their updates separately.