Skip to content

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

Merged
merged 14 commits into from
Sep 25, 2018

Conversation

mneil
Copy link
Contributor

@mneil mneil commented Sep 25, 2018

No description provided.

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
@mneil mneil requested a review from cplee September 25, 2018 21:43
Copy link
Contributor

@cplee cplee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feedback inline...

return err
}
templateBody := aws.String(templateBodyBytes.String())
templateBody, err := templates.GetAsset(templateName, templates.AddData(templateData),
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@cplee cplee merged commit 2d1aa17 into develop Sep 25, 2018
@cplee cplee deleted the issue-273 branch September 25, 2018 23:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants