Sign-in and identity

What is available

Method	Status	Where credentials live
Email and password	Available	Your Postgres
Passkeys	Available	Your Postgres holds the public key. The private key never leaves the user's device
Multi-factor authentication	Available, and required during onboarding	Your Postgres
Password reset by email	Available when SMTP is configured	Your mail server sends the link
Microsoft Entra ID	**In development, not supported at the moment **

Nothing outside your cluster is involved in sign-in. Accounts, password hashes, passkeys and sessions are all in your own database. If you configure SMTP, invitation and password-reset emails go out through your mail server.

Single sign-on is not available yet

Microsoft Entra ID is in development. No generic OIDC provider, no SAML and no LDAP integration exists either.

If single sign-on is a requirement for you, tell us which provider, because that shapes what ships first.

The first account

Registration is invite-only and invites need an existing member, so a fresh install seeds one account with a published password. Signing in, completing onboarding and changing that password is a required install step, not an optional one.

See First sign-in.

The published address decides whether sign-in works

The dashboard derives its sign-in base URL from the host you publish it on. If that does not match the address people actually type in the browser, every sign-in is rejected as an invalid origin.

Two rules:

1. Use the address people type. Not an internal service name, not a load balancer's own hostname.
2. If TLS terminates upstream of the ingress, set the scheme explicitly, because the chart cannot infer it and guesses http while the browser is on https.

--set externalScheme=https

Leave that unset when TLS terminates at the ingress. See Publish the endpoints.

Passkeys

Users can register with a passkey instead of a password, and add, rename or remove passkeys under Profile. Signing in with a passkey does not ask for the authenticator-app code: the passkey's own PIN or biometric check stands in for it. Enrolling multi-factor is still required during onboarding.

A passkey is bound to the host name the dashboard is published on, taken from its sign-in URL. So:

• They need HTTPS and a DNS name. A plain-HTTP address or a bare IP cannot register one.
• Changing entrypointHost makes every registered passkey stop working. Users then sign in with a password, or register a new passkey on the new address.
• A user who registered with a passkey only has no password to fall back on. Ask them to set one under Profile, especially when SMTP is not configured and nobody can reset it by email.

Invitations and email

Invitations grant one or more workspaces, each with a role no higher than the inviter's own. Pending invitations are listed on the Team tab, where they can be revoked. A link expires after seven days, and inviting the same address again replaces the previous link.

With SMTP configured, the invitation is emailed and users can reset a forgotten password. Without it, the dashboard shows the invitation link for you to copy and send yourself, and the sign-in page offers no password reset.

SMTP is configured through the dashboard's environment. The chart has no dedicated keys for it, so set them under services.ui in your overrides file, with the credentials in a Secret you create:

kubectl -n gen0sec create secret generic g0s-ui-smtp \
  --from-literal=user='<smtp-user>' --from-literal=password='<smtp-password>'

my-overrides.yaml

services:
  ui:
    env:
      HOST_EMAIL: smtp.example.com
      HOST_PORT: "587"
      HOST_ALIAS_EMAIL: no-[email protected]
      HOST_APP_URL: https://cerebellum.example.com
    envSecrets:
      HOST_AUTH_USER: { name: g0s-ui-smtp, key: user }
      HOST_AUTH_PASS: { name: g0s-ui-smtp, key: password }

Variable	Notes
HOST_EMAIL	The SMTP server's host name
HOST_PORT	587 by default, with STARTTLS. 465 switches to implicit TLS
HOST_AUTH_USER, HOST_AUTH_PASS	Required. SMTP is only used when the host and both credentials are set. A relay without authentication is not supported
HOST_ALIAS_EMAIL	Required. The sender address
HOST_APP_URL	Required. The address people type, with its scheme. Links in emails are built from it, and it is not derived from entrypointHost

Pass the file to every later helm upgrade as well. The dashboard's outbound connection to your mail server is listed on Ports and egress.

Sessions

The signing secret lives in g0s-db-ui, created with all the other database secrets in Install step 6.

Action	Effect on sessions
Re-running make-db-secrets.sh	None. The existing signing secret is preserved deliberately
Rotating the signing secret	Every session ends and every outstanding invite link stops working. Passwords and passkeys are unaffected
Changing entrypointHost	Registered passkeys stop working
Upgrading	None. Upgrading from v0.1.x to v0.2.0 invalidates invite links issued before the upgrade

Turning the dashboard off entirely

If your operators use the API only:

--set services.ui.enabled=false

The agent-facing APIs are unaffected. Note that agent API keys are issued through the dashboard, so turn it off only once you have the keys you need.

If it fails

Symptom	Cause
Sign-in rejected as an invalid origin	The published host does not match the address typed, or the scheme is wrong. See above
Sessions drop after a re-run of the secret script	The signing secret changed. It should not; check whether the secret was deleted first
Every sign-in fails after an upgrade	Check that externalScheme and the host survived the upgrade. helm get values g0s -n gen0sec
The passkey prompt fails or offers no passkey	The address typed differs from entrypointHost, the page is plain HTTP, or the host changed after the passkey was registered
Emailed links start with undefined/	HOST_APP_URL is not set
Invitations show a link instead of being emailed	SMTP is not configured, or sending failed. Check kubectl -n gen0sec logs deploy/g0s-ui