-
Notifications
You must be signed in to change notification settings - Fork 4k
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
fix(redshift): Fix Redshift User Secret Multi-User Rotation #28856
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
Not sure about this.
Shouldn't we simply pass a
DatabaseSecret
withmasterSecret
set to theaddRotationMultiUser
method?It seems like we might be assigning unnecessary permissions to the user here.
Also, I think we should validate that the secret for
addRotationMultiUser
has the requiredmasterSecret
value set here.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.
Absolutely! I was having the same conversation with a teammate this morning about that. The secret itself shouldn't need to encode the masterSecret reference especially since there is nothing secret about that reference (nor anything bad that could happen if an incorrect or different arn was set - the rotation lambda would just fetch wrong cluster admin credentials and fail to make the update!). Unfortunately, I think we may be bound by the implementation of addRotationMultiUser and the redshift multi-user rotation lambda secrets manager provides which expects
masterarn
to be encoded in the secret.Re assigning unnecessary permissions, I see your point about sending
masterSecret
into DatabaseSecret but at impl time its just encoding the master secret ARN w/o additional permissions. Its the rotation lambda that has permission to the masterSecret and secret to perform the rotation.On the validation, I don't know if we can perform that validation at build time since
options.secret
is a reference to ISecret and not DatbaseSecret :/ - thoughts?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.
Makes sense and I agree with your analysis of the current implementation.
Thanks for the detailed follow-up 👍
On validation, we could expose the
masterSecret
property publicly inDatabaseSecret
and perform a type-check inaddRotationMultiUser
for thesecret
.I think it might be worth adding to provide clearer feedback to users invoking the method without providing the necessary parameters.