-
Notifications
You must be signed in to change notification settings - Fork 132
Add default stack policy to prevent replace and delete on KMS and RDS #341
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
Conversation
A stack policy exists in the assets and is currently added to all stacks. The policy does not allow replace or delete actions on RDS or KMS resources. I plan to pass the policy in as a string to upsert stack as a way to set the policy later through extensions or cli flags.
Switching to packr removed the need to have lint workarounds
- Define constants for policies - Update references to use GetAsset - Update tests Tests still failing. Looks like tests are just bad and need to be updated.
- Fixed issue where template processing was still required - Added tests to template methods - Add template processing on templates where needed
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.
feedback inline...
provider/aws/cloudformation.go
Outdated
return err | ||
} | ||
templateBody := aws.String(templateBodyBytes.String()) | ||
templateBody, err := templates.GetAsset(templateName, templates.AddData(templateData), |
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 like what you have going here, but i think it'd be even cleaner to use a fluent api so that you get:
.AddData(templateData)
.DecorateTemplate(cfnMgr.extensionsManager, stackName)
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.
Yeah I'd considered it. As a heavy user of nodejs though I've ran into so many issues with fluent api's in native Promise chaining that turn code into huge try/catch blocks with poor error propagation and 100 line stack traces. It also means I need a struct to reference so I can return it from each of these funcs. In general I think it just adds unnecessary complexity.
No description provided.