Helm: for email auth the initial user should be seeded with random credentials and invite-only set

[iainsproat]

What package are you referring to?
Helm, Server

Is your feature request related to a problem? Please describe.
Currently, when deploying Speckle on Kubernetes with Email Auth there is a period of time between the Server being available on the internet and the operator registering as the administrator of the server, and then being able to prevent additional registrations.

Describe the solution you'd like
The server should create an initial user and prevent additional registrations. The credentials for the initial user should be auto-generated and available to only the operator.

Suggest a similar solution to Bitnami's helm charts, which generate a secret containing the administrator's initial password. The first user is created with these credentials, and they can be accessed only by the operator with kubernetes read access. This prevents third parties from accessing the admin UI in the meantime.

Describe alternatives you've considered

Additional context

[iainsproat]

Option

New Configurations for:

• server.auth.local.initialAdminUser.Email
  • initialAdminUser.Email is recommended to be set, otherwise defaults to admin@localhost
• server.auth.local.initialAdminUser.Secret
  • initialAdminUser.Secret is optional. Default is empty.
• server.auth.local.initialAdminUser.SecretKey.
  • server.auth.local.initialAdminUser.SecretKey is optional. It is ignored if initialAdminUserSecret is not set.

1. If initialAdminUser is set, Helm does the following:

• if .Email & .SecretKey is not set, throws an error.
• mounts .SecretKey to speckle-backend pod

2. If initialAdminUser is not enabled, Helm does the following:

• ignores initialAdminUser
• using the default value for .Secret, it checks for the existence of an existing secret
• if the secret does not already exist, it creates it (note: refer to how Bitnami helm charts do this)
  • if .SecretKey is not set, the default value for .SecretKey is used
  • populates the secret with a key using the default value for initialAdminUser.SecretKey with a value being a randomly generated password complying to Speckle's user password policy.
• if the secret already exists, helm does nothing

3. On startup of speckle-server, the server does the following:

• checks the number of existing admin users (countAdminUsers)
• if there are no admin users, we assume this is a brand new server ✨
  • reads the mounted secret from file (populated from initialAdminUser.Secret)
  • creates a new user (createUser) with the data from initialAdminUser.Email and the secret. As this is the first user, it will be admin by default.
• if there are existing admin users, it does nothing

A new configuration server.auth.inviteOnly is provided, this is is enabled by default. This is of lower precedence than the toggle in the admin dashboard UI.

1. Helm populates this value as an Environment Variable in speckle-backend
2. When the speckle-backend server starts up, prior to the serverInfo being populated/updated, it checks for the existence of this value. If it already exists in the database, it ignores the ENV var.
   (question: should this behaviour be the same for other auth strategies? - we may want helm to only apply this when auth.local is enabled)

[iainsproat]

closing as won't do, for now.