First sign-in
Why this page exists
Registration is invite-only, and invites can only be created by an existing member. A fresh install can be logged in by a pre-seeded admin account.
The seeded account
[email protected] | |
| Password | Gen0Sec!ChangeMe |
It is a constant in our migration file, so anyone who has read our documentation knows it.
The dashboard will not let you past it: the account is created with a must-change flag, so setting a new password is a step you cannot skip or postpone. What that does not do is protect the account between the moment you publish the address and the moment you first sign in. Whoever signs in first is who sets the new password.
Sign in before you give the address to anyone else. If you have already shared it, sign in now and treat the interval as exposed.
1. Sign in
Open your published address and sign in with the details above.
echo https://$ENTRYPOINT_HOST
If sign-in is rejected as an invalid origin, the published host or scheme does not match what you typed. See Sign-in and identity.
2. Complete first-run setup
The dashboard holds you at each of these in turn, and it will not let you skip ahead. A deep link to any other page returns you to the step you are on.
- Enroll multi-factor authentication. Nothing else opens until you confirm a six-digit code.
- Set a new password. Step 3 below.
- Create your organization.
- Finish the remaining onboarding steps. The wizard creates your first API key, then walks the WAF, access rule and monitoring surfaces.
Multi-factor comes first, so the published password stops being enough to sign in before you have even reached the password screen.
3. Mandatory password change
Because the password is preseeded, after setting up MFA, you'll be asked to change your password.
Every other session on the seeded account ends when the password changes. On a first install there are none, which is the point: if the address was reachable before you signed in, this is what closes that off.
The seed is also idempotent on the email address. Re-running the migration or the secret script neither duplicates the account nor re-flags it, and it does not reset a password you have already changed.
4. Invite the people who need access
Invite your operators rather than sharing the seeded account.
5. Mint an agent API key
Create an agent API key in the dashboard, then save it where the verification step reads it from:
mkdir -p ~/.gen0sec
printf '%s' 'yor-agent-key' > ~/.gen0sec/agent-key
If it fails
| Symptom | Cause |
|---|---|
| The seeded account does not exist | The migration ran without the on-prem marker. Secrets were provisioned without make-db-secrets.sh |
| Sign-in rejected as an invalid origin | The published host or scheme does not match the address you typed |
| The dashboard loads but onboarding will not advance | Check kubectl -n gen0sec logs deploy/g0s-ui |
| The password is rejected | It is case-sensitive and contains a !. Watch your shell if you pasted it |
| The new password is rejected as too weak | 12 characters, one symbol, and three of the four character classes. The server applies the same rules as the form |
| The password screen appears again on a later sign-in | The change did not complete. The flag clears only on success |