-
Notifications
You must be signed in to change notification settings - Fork 356
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
feat: enable token auth for Jupyter notebooks [MD-404] #9452
Conversation
✅ Deploy Preview for determined-ui canceled.
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9452 +/- ##
==========================================
- Coverage 49.90% 49.85% -0.06%
==========================================
Files 1245 1246 +1
Lines 161903 162007 +104
Branches 2887 2886 -1
==========================================
- Hits 80795 80763 -32
- Misses 80937 81073 +136
Partials 171 171
Flags with carried forward coverage won't be shown. Click here to find out more.
|
master/internal/command/command.go
Outdated
allo := c.refreshAllocationState() | ||
notebookAddress := fmt.Sprintf("%s?token=%s", c.serviceAddress(), c.Base.UserSessionToken) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little worried about returning user tokens in /api/v1/notebooks
for security reasons
is there a way around this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have to give the plain text link with the token to the user, so they could copy-paste it into their vscode, right? so probably no way to avoid sending these secrets over the wire.
we could maybe send the base URL and the token separately, so at least the automated URL scanners could not catch it. but that is security by obscurity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think my issue is we are exposing Determined users tokens to other users. An non admin could snag an admins token from the api and just start making calls as that user. Or you could impersonate another user.
I have mentioned at least part of this in a DM but an alternative that doesn't expose more access into the system is
-
Notebooks links in the API stay the same. When connecting from the CLI we add
?token=...
to the link we print. This token comes from being logged into the CLI or webui. -
The proxy authenticates the request based on
?token
if present. -
If vscode needs the notebook to be authenticated the proxy can add another layer of auth between itself and the notebook. This is optional to me since we don't assume this connection is authed today. But I don't think the notebook could use the CLI/webui
token?
as the token it expects because multiple tokens should be valid to access the notebook. Maybe you could rewritetoken
to a per Notebook credential.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, good point.
bbc95df
to
db62b72
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
|
||
if _, err := Bun().NewInsert().Model(notebookSession). | ||
Returning("id").Exec(ctx, ¬ebookSession.ID); err != nil { | ||
return err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: wrap these errors
@@ -131,6 +131,59 @@ func (cs *CommandService) LaunchGenericCommand( | |||
return cmd, nil | |||
} | |||
|
|||
// LaunchNotebookCommand creates notebook commands and persists them to the database. | |||
func (cs *CommandService) LaunchNotebookCommand( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little worried about this logic diverging from the generic one LaunchGenericCommand
can we instead have LaunchGenericCommand
check task type and only create a notebook session if task type is notebook?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, i didn't want this either, but it's hard to isolate, since the notebook launch takes in a session parameter and also sprinkles in additional calls throughout the method.
master/internal/api_auth.go
Outdated
// in two places: | ||
// 1. A token query parameter in the request URL. | ||
// 2. An HTTP Authorization header with a "token" type. | ||
func extractNotebookTokenFromRequest(r *http.Request) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this doesn't need to return an error?
7d1cedc
to
32d04ff
Compare
32d04ff
to
3adaed5
Compare
Ticket
Description
Enables access to a remote Jupyter server running as a Determined task outside Determined (use case here is to support VSCode integrations).
Jupyter in VSCode requires an access token, so this change modifies Determined auth logic to accept a token parameter in the proxy URLs.
Test Plan
Testing this requires VSCode with the Jupyter extension installed.
det notebook start
det notebook start
into the prompt, it should contain a?token=
parameter.Checklist
docs/release-notes/
.See Release Note for details.