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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new allowed_user_key_config field #1413
Add new allowed_user_key_config field #1413
Conversation
This fix introduces a new configuration block for the ssh_secret_backend_role resource, which supports the new vault-1.10 updates to the allowed_user_key_lengths parameter. The new config block is meant to supersede the current allowed_user_key_lengths provider field. Example role config: resource "vault_ssh_secret_backend_role" "demo" { name = "role1" backend = vault_mount.demo.path allowed_user_key_config { type = "rsa" lengths = [2048, 4096] } allowed_user_key_config { type = "dss" lengths = [2048, 4096] } }
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.
Looking great! A few comments/questions
log.Printf("[DEBUG] Writing role %q on SSH backend %q", name, backend) | ||
_, err := client.Logical().Write(path, data) | ||
if err != nil { | ||
return fmt.Errorf("error writing role %q for backend %q: %s", name, backend, err) | ||
// in the case where vault does not support a list of key lengths, |
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.
Nice catch! This error case had completely slipped my mind 馃槄
return err | ||
} | ||
|
||
newField := "allowed_user_key_lengths" |
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.
Should this be allowed_user_key_config
instead?
v[keyType] = l | ||
} | ||
|
||
return d.Set(newField, v) |
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.
Since this is in the case the user set the legacyField
in the TF config, should we be setting legacyField
to v
in the TF state instead?
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.
good catch, will update per your other comment.
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.
Fixed in f724d6a
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.
Fixed in affd6a1
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!
This fix introduces a new configuration block for the ssh_secret_backend_role resource, which supports the new vault-1.10 updates to the allowed_user_key_lengths parameter. The new config block is meant to supersede the current allowed_user_key_lengths provider field. Example role config: resource "vault_ssh_secret_backend_role" "demo" { name = "role1" backend = vault_mount.demo.path allowed_user_key_config { type = "rsa" lengths = [2048, 4096] } allowed_user_key_config { type = "dss" lengths = [2048, 4096] } } * Update docs * Complete the field name refactoring * Set the correct field in the legacy case * Add changelog entry
This fix introduces a new configuration block for the
ssh_secret_backend_role resource, which supports the new vault-1.10
updates to the allowed_user_key_lengths parameter. The new config block
is meant to supersede the current allowed_user_key_lengths provider
field.
Example role config:
Community Note
Relates OR Closes #0000
Release note for CHANGELOG:
Output from acceptance testing: