Overview: here's the proposal for onboarding, considering both in-cluster configurations, out-of-cluster configurations, and the hosted offering. The onboarding flow is primarily defined by the actions start
, which starts a Porter instance, auth register
/auth login
, which allows new users to login/create an account on an existing instance, project create
which creates a new project within the Porter instance, and connect
which allows the project to link or provision across clusters. All actions will have equivalent CLI commands/dashboard views except for start
.
Starting the server (porter start
)
The server should be started as a Docker container running either in-cluster or on a machine with the Docker engine running.
(1) Quick start: Run on host machine or via Docker engine
A user will be able to start the dashboard with a single command, porter server start
, that will either use a local driver or detect if a compatible Docker engine is running, and if it is, will start the dashboard as a Docker container bound to a specific port
on the host machine. The driver is selected via the --driver
flag. This command has the following signature:
Starts a Porter server instance on the host
Usage:
porter server start [flags]
Flags:
--db string the db to use, one of sqlite or postgres (default "sqlite")
--driver string the driver to use, one of "local" or "docker" (default "local")
-h, --help help for start
--image-tag string the Porter image tag to use (if using docker driver) (default "latest")
-p, --port int the host port to run the server on (default 8080)
Global Flags:
--host string host url of Porter instance
(2) Quick start: Helm chart
For in-cluster configurations, the only auth mechanism enabled by default is token-based authentication. The admin user will be identified via the service-account-token
associated with the deployed chart. Once the admin user logs in, they will be asked to name the project, and upon project creation they will be prompted to name the cluster that will be connected by default. The admin can add other users by generating in-cluster secrets (selected by default) or using Porter's JWT implementation. The following features will be disabled by default: creation of new projects, connecting to other clusters, cluster provisioning, basic authentication (email/password), oauth/oidc authentication.
Logging in (porter auth login
)
A user can log in as a local
or an external
user, partially modeled off of Rancher's external vs local authentication. A local user is identified via email, while an external user is identified via a token. While we may eventually support SSO, we will likely restrict external users to Github/Gitlab accounts. Note that external users are not supported by default in self-hosted configurations: setting up external users will require an advanced configuration.
It should be possible to prompt this login flow from the CLI, which will open the default browser and ask the user to log in. If the user specifies the --no-launch-browser
option, the user will be prompted for an email/password directly from the CLI. If the user specifies the --token
option, they can input the token given to them by the admin. In the case of Github/Gitlab login, they will have to authenticate via the browser.
(1) Email-based login:
A user should be able to create an account via an email/password. To make the onboarding flow easier, an admin user will be able to share a link to members that contains a token which identifies an email address and a project id. If the user is logged in, they will automatically join the project; if not, they will be prompted to create a password. In the hosted platform, we will send this email to the specified email address; in self-hosted versions without email configuration, the admin will have to share the tokens directly.
(2) External login:
A user should be able to log in using an external identity provider. To make the onboarding flow easier, an admin user will be able to grant access to members in the same Github/Gitlab organization. If the user is already logged in via an email/password, the user will be prompted to link their Github/Gitlab account to that account. If the user is not logged in, they will be automatically prompted to log in using their Github/Gitlab account.
(3) Token-based login
For certain in-cluster configurations, a user will be able to log in via a service account token that exists in the same namespace as the Porter pod.
Creating a project (porter project create
)
This is rather self-explanatory, but a user should be able to create a new project from the dashboard or the CLI. The user that creates the project will be an admin user by default, which allows them to add new members to the project.
Creating/linking a service account (porter connect
)
A service account is Porter's method for accessing and provisioning a cluster. Service accounts are identified via a (kind, auth-mechanism, project_id)
tuple. A kind
is defined as one of provisioner
, connector
: a provisioner
can only provision a new cluster and update cluster infrastructure, while a connector
can read cluster objects.
Note: a connector
service account is the equivalent of a native serviceAccount
object within Kubernetes, while a provisioner
service account is the equivalent of a native serviceAccount
in GCP/AWS.