-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add support for templated values in SSH CA DefaultExtensions. #11495
Add support for templated values in SSH CA DefaultExtensions. #11495
Conversation
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.
Thanks for submitting this enhancement!
builtin/logical/ssh/path_sign.go
Outdated
return nil, fmt.Errorf("extensions %v are not on allowed list", notAllowed) | ||
if role.DefaultExtensionsTemplate { | ||
templatedExtensions := make(map[string]string) | ||
for extensionKey, extensionValue := range extensions { |
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.
At this point in time the extensions
map could contain user provided extensions (from the data.Get("extensions")
call above). The boolean you added only (by name) covers the DefaultExtensions. It may be safer to only allow default extensions to be templated so users cannot query unintended identity data. We could return early above if user provided extensions are passed.
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.
Ah, excllent point. Let me re-think this portion; originally I had struggled a bit with working out all of the possible unintended consequences (like 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.
So, I'm going to send an additional commit here, to demonstrate my thought process. Ideally, I think we'd want to have Default Extensions that are configured by the role (and templated, if the flag is enabled), but also if there are Allowed Extensions configured, then take user input and override the Default Extensions (sans templating). Is that a more reasonable approach?
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 that sounds right. The existing logic prioritizes user input and does not try to merge it with the default extensions. I think we should continue to have the same semantics. So if user supplied extensions exist process those (without templating), else use the defaults with optional templating.
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.
Thanks for the feedback - I've sent a commit to rework the logic, and also add a basic test - can extend this test structure, if it looks acceptable.
3e86485
to
80133b8
Compare
80133b8
to
9733066
Compare
@briankassouf Is there anything else I can do on this PR? |
bd85e05
to
b3958b3
Compare
b3958b3
to
54b6591
Compare
54b6591
to
3d72d77
Compare
3d72d77
to
b3cccd7
Compare
builtin/logical/ssh/path_sign.go
Outdated
extensions := make(map[string]string) | ||
|
||
if len(unparsedExtensions) > 0 { | ||
parsedExtensions := convertMapToStringValue(unparsedExtensions) |
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 believe there is a behavior change here. If the role has no AllowedExtensions the below branch will be skipped and nothing will be added to the extensions map. Should we assign extensions
here like we were previously?
The docs for AllowedExtensions state:
Specifies a comma-separated list of extensions that certificates can have when signed. To allow any extensions, set this to an empty string. Will default to allowing any extensions.
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.
Got it - added a commit to fix up this inadvertent change in behavior, and added a test case to cover it.
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.
Thanks for adding the test and Changelog entry! Everything is looking great except for this one comment
b3cccd7
to
61dff11
Compare
As an aside: any thoughts/preferences on cleaning up the tests I've introduced here? I think they've gotten to the point of needing to be broken out into separate cases, but also don't want to start crowding |
61dff11
to
80ffa2d
Compare
Thank you for the latest commit. My only feedback on the test would be the user supplied tests could be broken into a separate test from the templating tests |
I'll do that right now, and send an additional commit shortly. |
… default when user-provided extensions are present.
80ffa2d
to
1d37190
Compare
1d37190
to
f112d34
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.
Looks great! Thanks for submitting this enhancement
This PR adds support for using identity templates in values used in Default Extensions. The primary focus here is to allow the Vault SSH CA backend to function as a point of identity/authentication for GitHub Enterprise (and Github.com) users, by supporting their identity semantics, as documented here.
I've based a large chunk of this on #7548 - happy to make changes as requested/needed to get this into the tree.