Accounts and access

The first installer claims the administrator account using the private setup proof. Public registration never creates another installation administrator. Hakopod's current self-hosted trust model is one operator organization with trusted developers.

Human sign-in#

Email/password, GitHub, GitLab.com and Google sign-in are available when their integrations are configured. Passkeys require HTTPS or a loopback development origin. You can enroll authenticator-based TOTP, use recovery codes and revoke sessions in account settings.

OAuth providers need their own operator-owned client configuration and exact callback URL. A provider login does not grant repository access or an installation role. TOTP keys are encrypted separately; preserve the authentication encryption key as part of recovery.

Public signup is disabled by default. An operator can enable it through HAKOPOD_SIGNUP_ENABLED=true or operator TOML. Email registration verifies the address before creating the account. A valid paid invitation can allow registration while public signup is closed.

Password recovery requires configured SMTP. A reset revokes browser and CLI sessions while retaining enrolled second factors and passkeys. API keys are separate credentials. Missing external email configuration cannot be replaced by retrieving a temporary password from the API.

Personal workspaces and teams#

A verified account can create one private personal workspace in Free. It has a private project and development environment; it cannot be shared through team assignments or member invitations.

Team creation, invitations and shared project roles require signed Pro entitlements. Project roles are administrator, developer and viewer. Team membership and project grants are separate: membership alone is not a blanket installation role.

Role changes, disabled accounts and revoked sessions are checked on new requests and before subsequent deployment effects. If a license expires, paid permissions stop authorizing new work. Running workloads and stored data are not deleted, and installation administrators retain Free recovery operations.

CLI sessions and CI keys#

Human CLI login uses browser consent for an explicit project and environment:

hakopod login --api-url https://control.example.com --project demo --environment development

Use your actual API origin. Credentials are stored in a restricted mode-0600 file. For unattended deployments, create a named expiring key with only the required scope and permissions, then store HAKOPOD_API_URL and HAKOPOD_API_KEY in the CI provider's secret store.

Do not place credentials in TOML, image URLs or plain environment variables that appear in history. Machine keys cannot open container terminals. A deployer can run application code that reads its injected secrets, so deployment permission is a meaningful trust decision.

Separate management from applications#

Keep the dashboard on a distinct trusted origin. The API and dashboard share one configured API path; application containers receive no cluster credentials. Default workloads drop capabilities, run without privilege escalation and do not get service-account token mounts, host networking or host-directory mounts.

Private service networking restricts declared peers and ports, and ordinary workload egress excludes management and metadata ranges. These controls do not turn shared kernels into a hostile-tenant sandbox. Administrators can also change Kubernetes policies outside Hakopod, so the operator remains part of the trust boundary.

The planned managed Cloud service has additional admission, abuse and account-budget work before it can host unrelated untrusted customers. Selecting managed-cloud disables public TCP; it does not establish all of those guarantees.

See the threat model, account behavior and paid-feature reference for the underlying boundaries.