Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deployment auth SIP #795

Merged
merged 1 commit into from
Oct 11, 2022
Merged

Deployment auth SIP #795

merged 1 commit into from
Oct 11, 2022

Conversation

itowlson
Copy link
Contributor

@itowlson itowlson commented Sep 30, 2022

WIP but getting discussion under way!

Rendered

Copy link
Member

@bacongobbler bacongobbler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking great! Thanks for taking the time to write this up.

docs/content/sips/007-deployment-auth.md Outdated Show resolved Hide resolved

A user may log into multiple Hippo servers. The (URL, token) pairs for each will be stored. That is, logging into one server does not log you out of others.

> QUESTION: Or should you only be logged into one at a time?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To simplify the spin deploy experience, being logged into one system at a time may be best for now. Especially because this proposed idea raises a bunch of follow-up questions listed further below.

Once we design a system where we can support multiple "login profiles" (spin configure has been thrown around as an idea), then we should revisit this idea.

docs/content/sips/007-deployment-auth.md Outdated Show resolved Hide resolved
docs/content/sips/007-deployment-auth.md Outdated Show resolved Hide resolved
docs/content/sips/007-deployment-auth.md Outdated Show resolved Hide resolved
docs/content/sips/007-deployment-auth.md Outdated Show resolved Hide resolved
docs/content/sips/007-deployment-auth.md Outdated Show resolved Hide resolved
> * Con: the user may already have stuff on their clipboard
> * Con: again, documentation needs to consider differences across OSes

(For both of these questions, is there prior art to which we can refer?)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commands like az login and gh auth login would be good places to reference.

https://cli.github.com/manual/gh_auth_login

https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli

docs/content/sips/007-deployment-auth.md Outdated Show resolved Hide resolved
docs/content/sips/007-deployment-auth.md Outdated Show resolved Hide resolved
@radu-matei radu-matei added this to the Spin v0.6.0 milestone Oct 3, 2022

We propose to poll for two minutes. If the user has not entered the code by then, `spin login` fails and exits.

Errors do _not_ cause polling to terminate. We do not want a transient network error or server hiccup to block login. That said, if we can identify server responses that are necessarily fatal, we can in future terminate early on those.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They should at least print warning(s) or the user may be left wondering.

@itowlson
Copy link
Contributor Author

itowlson commented Oct 3, 2022

Thanks folks for all the feedback. It sounds like the model we want to espouse is:

  • spin login both selects the deployment server and records credentials for it.
    • Even for username-password servers.
    • You can only be logged into one server at a time - logging out, or logging into another server, not only deselects it but erases the stored credentials.
    • We need a solution for folks who often switch between multiple deployment servers - one possibility is to have them manage file locations.
  • spin deploy always deploys to the target specified in the last login (and we remove all deployment server options).
    • Possible exception for CI environments?
    • If you're not logged in then it either fails entirely, or hands you off to the login flow (from Fisher's example it looks like if you're not logged in it just fails, but if your credentials fail it hands you off to the login flow?). But in either case there is a clear handoff - we do not entangle auth and deployment.
    • We are willing to add an extra step to the spin new -> spin build -> spin deploy pipeline because it allows us to vastly simplify deploy.

Is that correct?

@bacongobbler
Copy link
Member

bacongobbler commented Oct 3, 2022

Is that correct?

Yes. Your assessment matches my own mental model.

The last step seems like it is the most impactful to the UX.

You can only be logged into one server at a time - logging out, or logging into another server, not only deselects it but erases the stored credentials.

In order to minimize impact to the spin CLI, this makes sense for now. But we should circle back on this one ASAP to see if we can add multiple login profile support as this will be a big QoL improvement to the UX.

@mikkelhegn
Copy link
Member

spin deploy always deploys to the target specified in the last login (and we remove all deployment server options)
Without a --target (or similar) option, I would probably at any given time deploy to the wrong target, so is the endpoint you are signed in to stored somewhere? I'm asking as a prompt (e.g. Starship) could show that info if that's the case.

@itowlson
Copy link
Contributor Author

itowlson commented Oct 4, 2022

@bacongobbler Hope this now accurately reflects our discussions!

@itowlson
Copy link
Contributor Author

itowlson commented Oct 5, 2022

@bacongobbler one thing not covered here... there probably needs to be a way to tell what you're logged into... I'm reluctant to have a top level command for that though... would something like spin login --status make sense?

@bacongobbler
Copy link
Member

Yeah that makes sense to me!

@bacongobbler
Copy link
Member

@itowlson see #794 (comment) - spin login --status has now been implemented.

At the moment, Spin doesn't know whether a URL uses device flow or username-password, so `spin login` will prompt. If we can identify particular URLs or families of URLs whose auth mode is known, those can skip this step.

```
How would you like to authenticate Spin? [Username and password|Log in with a web browser]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good way to handle this issue for the time being.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how it looks as written in #794:

Suggested change
How would you like to authenticate Spin? [Username and password|Log in with a web browser]
What authentication method does this server support?
1. Sign in with GitHub
2. Sign in with a username and password
Enter a number:

At the moment, Spin doesn't know whether a URL uses device flow or username-password, so `spin login` will prompt. If we can identify particular URLs or families of URLs whose auth mode is known, those can skip this step.

```
How would you like to authenticate Spin? [Username and password|Log in with a web browser]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how it looks as written in #794:

Suggested change
How would you like to authenticate Spin? [Username and password|Log in with a web browser]
What authentication method does this server support?
1. Sign in with GitHub
2. Sign in with a username and password
Enter a number:

@itowlson
Copy link
Contributor Author

@bacongobbler thanks! Updated the sign-in method prompt; I also added a note about needing a flag to suppress it (which can be hidden).

Enter a number:
```

Programmatic consumers need a way to override this prompt, e.g. `--method=[username|github]`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would be a good option. We can also check for the presence of --check-device-code to determine the auth mode, since the presence of that flag automatically short-circuits it to be Github auth.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, and --get-device-code too of course. I'll add this note and merge. Thanks!

Signed-off-by: itowlson <ivan.towlson@fermyon.com>
@itowlson itowlson merged commit b6cc918 into fermyon:main Oct 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants