Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

feat(coderd): add endpoint to fetch provisioner key details#15505

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
defelmnq merged 13 commits intomainfromapi-endpoint-provisioners-info
Nov 20, 2024

Conversation

defelmnq
Copy link
Contributor

@defelmnqdefelmnq commentedNov 14, 2024•
edited
Loading

This PR is the first step aiming toresolve#15126 -

Creating a new endpoint to return the details associated to a provisioner key.

This is an authenticated endpoints aiming to be used by the provisioner daemons - using the provisioner key as authentication method.

This endpoint is not ment to be used with PSK or User Sessions.

…sing its idfix: change from database.StringMap to codersdk.ProvisionerKeyTags in endpoint responseimprove annotations for endpointmove logic to enterprise partgenerate new docmove logic to enterprise partgenerate doc
@defelmnqdefelmnqforce-pushed theapi-endpoint-provisioners-info branch from3db02d2 to995a046CompareNovember 14, 2024 08:02
Copy link
Contributor

@dannykoppingdannykopping left a comment

Choose a reason for hiding this comment

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

Looks good, but I think we've gone too narrow with this endpoint. I don't have the full context though so I might be mistaken, but based on what@johnstcn said in#15126 (comment) I don't think we need an endpointjust for tags

@johnstcn
Copy link
Member

Looks good, but I think we've gone too narrow with this endpoint. I don't have the full context though so I might be mistaken, but based on what@johnstcn said in#15126 (comment) I don't think we need an endpointjust for tags

I'd agree, it would make sense to return an endpoint that shows all the details of the provisioner key used to authenticate (except hashed secret obvs)

@defelmnqdefelmnqforce-pushed theapi-endpoint-provisioners-info branch fromaca52f4 to54437f2CompareNovember 18, 2024 15:13
Copy link
Contributor

@dannykoppingdannykopping left a comment

Choose a reason for hiding this comment

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

LGTM 👍

Left a few minor thoughts; deferring to@johnstcn for final review since he has more context.

require.Equal(t, fetchedKey.Name, "my-test-key")
require.Equal(t, fetchedKey.Tags, codersdk.ProvisionerKeyTags{"key1": "value1", "key2": "value2"})

erroneousPK, err := client.GetProvisionerKey(ctx, "abcdefghijklmnopqrstuvwxyz01234567890123456")
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: you're testing multiple scenarios in one test; it's closer to our style to use table tests in this case.
I also think you should add a test to validate the middleware/auth setup.

Copy link
Member

Choose a reason for hiding this comment

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

Suggest testing following scenarios:

  • No auth (403)
  • API key auth (403 with message indicating required header)
  • PSK auth (403 with message indicating required header)
  • Provisioner key auth (200)

dannykopping reacted with thumbs up emoji
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

I added some tests as discussed and changed to table tests - should give more coverage on the different cases.

@dannykopping
Copy link
Contributor

@defelmnq can you also update the PR title & description to reflect the wider scope pls?

defelmnq reacted with thumbs up emoji

@defelmnqdefelmnq changed the titlefeat(coderd): add endpoint to fetch tags associated with a provisioner key by its idfeat(coderd): add endpoint to fetch provisioner key detailsNov 19, 2024
@defelmnqdefelmnqforce-pushed theapi-endpoint-provisioners-info branch from7880e9c to4a38977CompareNovember 19, 2024 16:22
@dannykopping
Copy link
Contributor

@defelmnq can you also update the PR title & description to reflect the wider scope pls?

The description looks half-completed, btw:

This endpoint is not ment to be used wit

@defelmnq
Copy link
ContributorAuthor

@johnstcn sorry for all the pings, yesterday evening I rebased which seemed to have impacted the PR but I pushed back the missing tests - we should now be good to go ! 🙏

@dannykopping
Copy link
Contributor

@johnstcn sorry for all the pings, yesterday evening I rebased which seemed to have impacted the PR but I pushed back the missing tests - we should now be good to go ! 🙏

@defelmnq yet another reason why rebase is evil 🥲
Rebasing is not necessary in coder/coder since we squash-merge anyway, so history is always "clean".

@@ -200,17 +200,44 @@ func (api *API) deleteProvisionerKey(rw http.ResponseWriter, r *http.Request) {
httpapi.Write(ctx, rw, http.StatusNoContent, nil)
}

// @Summary Fetch provisioner key details
// @ID fetch-provisioner-key-details
// @Security CoderSessionToken
Copy link
Member

Choose a reason for hiding this comment

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

This comment should actually be updated as a session token here isn't sufficient auth. Sorry I didn't catch this sooner!

Copy link
Member

Choose a reason for hiding this comment

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

I checked the definition of the/provisionerdaemons/serve endpoint and it looks like it also specifies@Security CoderSessionToken. It looks like that's the only value we allow there currently --swaggerparser.go enforces this with some special cases for certain endpoints.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

As discussed , there's currently some extra logic to change inswaggerparser.go ->https://github.com/coder/coder/blob/main/coderd/coderdtest/swaggerparser.go#L302

I can either keep it like that and create the follow-up issue / PR quickly or add this endpoint to the ignore list for now - as you prefer.

Copy link
Member

Choose a reason for hiding this comment

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

Let's keep it as-is for the moment and create a follow-up PR to address this.

@johnstcn
Copy link
Member

@defelmnq yet another reason why rebase is evil 🥲

I like to think of it as a knife with no handle, just all blade. It'll do the job, but it just has lots of sharp edges!

defelmnq reacted with laugh emoji

require.NoError(t, err)

fetchedKey, err := client.GetProvisionerKey(ctx, "psk-testing-purpose")
require.Error(t, err)
Copy link
Contributor

Choose a reason for hiding this comment

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

Please be quite specific in the error you're checking for. The intent is not expressed clearly enough here.
This test should effectively be saying "Provisioner PSKs are similar to provisioner keys, but they cannot be used to retrieve information about a provisioner, so we get this very specific error message".

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

TBH I feel like i'm maybe missing something or we're over testing the same thing here. as the code is always coding the same method and filling the same header - we will always fall into the same test case in the middleware.

Not that I want to minimise the tests - but at the end :
https://github.com/coder/coder/pull/15505/files#diff-2eae6501c14fe87b5578bcd6fda3588cffb28d437c61765e3829ff530906927cR376 -> here we set the same header hardcoded.
https://github.com/coder/coder/blob/main/coderd/httpmw/provisionerdaemon.go#L28 -> This middleware will never really go into the PSK / CoderSession logic as they're never set on the other side.

I would rather add tests into the middleware if we want to increase coverage.

require.NoError(t, err)

fetchedKey, err := client.GetProvisionerKey(ctx, client.SessionToken())
require.Error(t, err)
Copy link
Contributor

Choose a reason for hiding this comment

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

Ditto.

})
require.NoError(t, err)

fetchedKey, err := client.GetProvisionerKey(ctx, "psk-testing-purpose")
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: use a const here

Copy link
Contributor

@dannykoppingdannykopping left a comment

Choose a reason for hiding this comment

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

LGTM

@defelmnq
Copy link
ContributorAuthor

Small update -

I'll create two follow-up issues (will link) after merging this PR :

  • One to improve the testing coverage on the middlewareExtractProvisionerDaemonAuthenticated - should be able to test the different cases.
  • One to have more permissive@Security tag on the swaggerparser.

@defelmnqdefelmnq merged commita518017 intomainNov 20, 2024
28 checks passed
@defelmnqdefelmnq deleted the api-endpoint-provisioners-info branchNovember 20, 2024 17:04
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@dannykoppingdannykoppingdannykopping approved these changes

@johnstcnjohnstcnjohnstcn approved these changes

Assignees

@defelmnqdefelmnq

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Correct log line when using tagged --key provisioner
3 participants
@defelmnq@johnstcn@dannykopping
[8]ページ先頭
©2009-2025 Movatter.jp