-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Conversation
Fixes Redshift User Secret Multi-User Rotation for new Users by including `masterarn` in the Secret's Serialized JSON Object Text. Note: This doesn't affect existing users (nor fixes roation for them) since the secret string template is only used when the secret is first created. For those existing secrets, the secret text will need to be updated to include `masterarn` using the GetSecretValue and UpdateSecret SecretManager APIs. closes aws#28852 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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 👍
Looks good overall, I left a couple of comments on the implementation.
Also, can you please update the title to describe the bug (not the solution)?
|
||
beforeEach(() => { | ||
stack = new cdk.Stack(); | ||
vpc = new ec2.Vpc(stack, 'VPC'); | ||
cluster = new redshift.Cluster(stack, 'Cluster', { | ||
const clusterImpl = new redshift.Cluster(stack, 'Cluster', { |
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.
Why can't we use the global variable? 🤔
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.
cluster
is ICluster which does not have a .secret
property. I figured that the rest of the tests wanted to continue to use the ICluster interface so I have this awkward code that has both an ICluster global variable and a Cluster local variable pointing to the same object but different types.
https://docs.aws.amazon.com/cdk/api/v2/docs/@aws-cdk_aws-redshift-alpha.ICluster.html
https://github.com/aws/aws-cdk/blob/v2.122.0/packages/%40aws-cdk/aws-redshift-alpha/lib/cluster.ts
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.
Tests are running successfully if we change the type declaration:
let cluster: redshift.Cluster;
I think it should be safe to do so to avoid declaring the two variables on different scopes.
@@ -153,6 +153,7 @@ export class User extends UserBase { | |||
const secret = new DatabaseSecret(this, 'Secret', { | |||
username, | |||
encryptionKey: props.encryptionKey, | |||
masterSecret: props.adminUser, |
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
with masterSecret
set to the addRotationMultiUser
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 required masterSecret
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 in DatabaseSecret
and perform a type-check in addRotationMultiUser
for the secret
.
I think it might be worth adding to provide clearer feedback to users invoking the method without providing the necessary parameters.
Thank you and will do! |
|
||
beforeEach(() => { | ||
stack = new cdk.Stack(); | ||
vpc = new ec2.Vpc(stack, 'VPC'); | ||
cluster = new redshift.Cluster(stack, 'Cluster', { | ||
const clusterImpl = new redshift.Cluster(stack, 'Cluster', { |
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.
Tests are running successfully if we change the type declaration:
let cluster: redshift.Cluster;
I think it should be safe to do so to avoid declaring the two variables on different scopes.
@@ -153,6 +153,7 @@ export class User extends UserBase { | |||
const secret = new DatabaseSecret(this, 'Secret', { | |||
username, | |||
encryptionKey: props.encryptionKey, | |||
masterSecret: props.adminUser, |
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 in DatabaseSecret
and perform a type-check in addRotationMultiUser
for the secret
.
I think it might be worth adding to provide clearer feedback to users invoking the method without providing the necessary parameters.
@penniman26 This is a great change! Thank you for your patience as get to reviewing PRs. I'll merge this one once the changes from @lpizzinidev have been addressed. |
This PR has been in the MERGE CONFLICTS state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week. |
This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error. |
Comments on closed issues and PRs are hard for our team to see. |
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.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
The pull request linter fails with the following errors:
PRs must pass status checks before we can provide a meaningful review. If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing |
Fixes Redshift User Secret Multi-User Rotation for new Users by including
masterarn
in the Secret's Serialized JSON Object Text.Note: This doesn't affect existing users (nor fixes roation for them) since the secret string template is only used when the secret is first created. For those existing secrets, the secret text will need to be updated to include
masterarn
using the GetSecretValue and UpdateSecret SecretManager APIs.Closes #28852
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license