-
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
Allow specifying multiple allowed SSH key lengths #13991
Allow specifying multiple allowed SSH key lengths #13991
Conversation
bbb3951
to
7e7e3da
Compare
I've proposed the parsing in |
7e7e3da
to
c5d7bbf
Compare
c5d7bbf
to
59970c5
Compare
In the ssh secrets engine, only a single allowed key length was allowed for each algorithm type. However, many algorithms have multiple safe values (such as RSA and ECDSA); allowing a single role to have multiple values for a single algorithm is thus helpful. On creation or update, roles can now specify multiple types using a list or comma separated string of allowed values: allowed_user_key_lengths: map[string][]int{"rsa": []int{2048, 4096}} Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
go get -u github.com/hashicorp/go-secure-stdlib/parseutil go mod tidy Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
59970c5
to
d42d72a
Compare
The newly introduced parseutil.ParseIntSlice handles the more complicated optional int-like slice logic for us. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
d42d72a
to
93de2c6
Compare
if kbits == value { | ||
for _, value := range allowed_values { | ||
switch kstr { | ||
case "rsa": |
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.
Technically correct, but we are now incongruent on the key names we accept for "key types" from PR#14008 and what the names/values we allow for this key. Not the end of the world just pointing it out.
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'll be addressing that in a follow-up PR, its a bit more subtle than I was hoping to do in this PR.
Thanks all! |
In the ssh secrets engine, only a single allowed key length was allowed
for each algorithm type. However, many algorithms have multiple safe
values (such as RSA and ECDSA); allowing a single role to have multiple
values for a single algorithm is thus helpful.
On creation or update, roles can now specify multiple types using a list
or comma separated string of allowed values:
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
As mentioned by @stevendpclark, there was some discussion of
map[string][]string
to support named curves, but with the exception ofx448
(which behaves likex25519
and takes no length), support in cryptography libraries for other named curves besides the 4 we support (+ P-224 which we don't) isn't broad. There's little value in adding them and most all should be happy with the three NIST P-curves and x25519 (+/- x448 if/when we add it).Since the PKI engine already takes curves-as-bits, I'm fine using this behavior. My 2c.