EDB Docs - EDB Postgres AI v1.4.0 (LTS) - Creating native users for testing

For testing or demo environments, you can simplify operations by adding native users. For production deployments, we strongly recommend configuring an external IdP.

HM stores native user credentials in the hm-portal-bootstrap Kubernetes secret. To add a new user, append their credentials to this secret.

Adding a native user

Generate a unique user ID and bcrypt-hashed password for the new user, where ${password} contains the password:

NEW_USER_ID=$(uuidgen | tr '[:upper:]' '[:lower:]')
NEW_HASH=$(echo -n "${password}" | htpasswd -BinC 10 admin | cut -d: -f2)
echo "User ID: $NEW_USER_ID"
echo "Password hash: $NEW_HASH"

Retrieve the current secret content:

kubectl get secret hm-portal-bootstrap -n default -o jsonpath='{.data.static-passwords\.yaml}' | base64 -d > static-passwords.yaml

Edit the static-passwords.yaml file and append the new user to the staticPasswords list:

staticPasswords:
  - email: "owner@mycompany.com"
    hash: "$2y$10$FWXeALAmT/axI/FIos/NtOVEldynfCx/bqDOAJ9EbiKeq5NuDR.XO"
    username: "Owner MyCompany"
    userID: "c234d951-dee1-4e3d-9f1d-108dabe339ce"
  - email: "newuser@example.com"
    hash: "$2y$10$FIvL7GWymJtGZo5uTMrWsOTuifUmwJQg8JtHJQxuLkT3os2Ozpo1C"
    username: "New User"
    userID: "60138e10-9552-4922-afe7-044c2250a23d"

Important

Do not change a user's userID after it's assigned. Changing it creates a new user identity, resulting in a duplicate user with the same email and name, and orphans any existing data associated with the original user.

Update the secret with the modified content:

kubectl patch secret hm-portal-bootstrap -n default \
  --type merge \
  -p "{\"data\":{\"static-passwords.yaml\":\"$(base64 < static-passwords.yaml | tr -d '\n')\"}}"

Kubernetes automatically replicates the secret to the upm-dex namespace, and the Dex deployment automatically restarts to apply the changes.
Verify the Dex pods have restarted and are running:
```
kubectl get pods -n upm-dex -l app.kubernetes.io/name=dex
```

The new user can sign in to the HM console with their email and password.

Parameters

These settings are for the user in the portal.authentication.staticPasswords entry. Each user needs values for email, hash, username, and userID.

Parameter	Description
`email`	Email address of the user. Also serves as the user's login identifier for accessing the HM console.
`hash`	Bcrypt-hashed user password for password store. To generate this value, use `echo ${password} \| htpasswd -BinC 10 userA \| cut -d: -f2`, where you store the actual password in the `${password}` variable. `userA` represents the username used during the password hashing process. It can be any arbitrary text, as HM doesn't use it elsewhere in the configuration. HM uses only the resulting hash.
`userID`	Each static-password user requires a unique `userID`. You can generate one with a UUID tool or assign a random string manually — but once set, never change it. Changing the `userID` creates a new identity, duplicating the user and orphaning their existing data.
`username`	Unique username for the user. This is the primary identifier for logging in to the HM console. It can be the same as `email`.

Creating native users for testing v1.4.0 (LTS)

Adding a native user

Important

Parameters

← Prev

↑ Up

Next →