-
Notifications
You must be signed in to change notification settings - Fork 83
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
RFC 66: Self Managed Stack Set Support #357
Conversation
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.
This is a great first attempt @linsona!
Some comments from me, but the general direction looks really promising!
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.
This is shaping up very nicely!
A few comments still.
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.
Next round of comments. We definitely need to iron out the Roles that were surfaced in this iteration - that seems to be a huge thing that's completely omitted from the current RFC. Also, let's expand the current "working backwards" section to include actually creating StackSet instances (as that's the final purpose of SackSets after all). That should illuminate what is the experience we want for the Roles here.
Also, make sure the linting pases on your document (you can run it locally to make sure it doesn't fail).
RFC Bar Raiser: @eladb |
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.
We're getting there! These are basically cosmetic issues, I think we've pretty much settled on the customer experience.
Also, the linter is still failing 😉. |
|
||
### README | ||
|
||
The `cdk.StackSet` construct in CDK defines AWS resources in a stack set and stack set |
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.
Please replace "stack sets" (or any variation thereof) with "StackSets" (one word) across this doc. I believe this is the how it is used by the service documentation.
This is different from the `cdk.CfnStackSet` construct, which requires a CloudFormation stack that then deploys a CloudFormation stack set. | ||
The `cdk.StackSet` construct creates the stack set directly if it does not exist, | ||
or updates a stack set and existing stack set instances while monitoring the stack set operation. | ||
|
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.
Add some information about what StackSets are (from the official CFN docs) and a reference to the official docs entry point
* **Stack Set Administration Role:** Role in the parent account, which is used by CloudFormation to assume the stack set execution role in the child account. | ||
* **Stack Set Execution Role:** Role in the child accounts, which allows the stack set administration role in parent account to assume, | ||
and perform the stack set instance deployment. |
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.
These roles sounds very much like the ones we use for CDK pipelines. Can't we reuse them?
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.
+1. I'm thinking the same.
If all we need is some slight adjustment to the existing role, then we don't need to change the cdk bootstrap
command.
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, so after discussing with Adam, we decided to go the route of introducing new roles:
- The
Stack Set Execution Role
names should be identical in all accounts, which is a requirement for how stack sets operate. The current roles in the bootstrap template are suffixed with specific account ids - The
Stack Set Execution Role
also must trust theStack Set Administration Role
, to assume and provision the stack set instance.- In the current bootstrap, the trust flag would give any IAM entity in the account permissions to assume the execution role, which may have a large scope of permission.
- This is different from trust given to the
DeploymentActionRole
, where it only has permissions to to create stack/changeset, and the actual role with large scope of permissions isCloudFormationExecutionRole
which is not assumable to by the trusted account
import * as cdk from '@aws-cdk/core'; | ||
import * as iam from '@aws-cdk/aws-iam'; | ||
|
||
class PocStackSet extends cdk.StackSet { |
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.
Our convention is not to use namespaced imports for core types:
class PocStackSet extends cdk.StackSet { | |
class MyStackSet extends StackSet { |
|
||
new iam.Role(this, 'ExampleRole', { | ||
assumedBy: new iam.ServicePrincipal('s3.amazonaws.com') | ||
}); |
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.
Change to 2 space indentation please
|
||
The handling of CDK assets is more complex than a normal stack CDK app. | ||
Stack set instances are deployed independently from CDK context, and exist in different accounts/regions. | ||
This is dicussed more in the design details. |
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.
This is dicussed more in the design details. | |
This is discussed more in the design details. |
|
||
### What alternative solutions did you consider? | ||
|
||
An alternative is the usage of `cdk.CfnStackSet`, which is not ideal for customers with existing stack sets since there is significant migration effort. |
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 have to say that this does not sound like a good enough reason not to implement this. Migrating from existing infrastructure (either CFN-based or not) is hard in most cases...
What are other reasons for us to support this?
|
||
### CDK Bootstrap CLI Changes | ||
|
||
To support stack sets, |
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.
Repeat from above: can we use/expand the CDK pipelines roles we already have in the bootstrap stack? Intuitively these should suffice since CDK Pipelines is basically doing the same thing as stack sets.
|
||
**CLI Changes:** | ||
|
||
* Update bootstrap CLI to include new flag `--stack-set` |
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.
* Update bootstrap CLI to include new flag `--stack-set` | |
* Update bootstrap CLI to include new flag `--stackset` |
|
||
**CLI Changes:** | ||
|
||
* Update bootstrap CLI to include new flag `--stack-set` |
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.
If possible, it would be nice if we didn't need any of this
* **Stack Set Administration Role:** Role in the parent account, which is used by CloudFormation to assume the stack set execution role in the child account. | ||
* **Stack Set Execution Role:** Role in the child accounts, which allows the stack set administration role in parent account to assume, | ||
and perform the stack set instance deployment. |
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.
+1. I'm thinking the same.
If all we need is some slight adjustment to the existing role, then we don't need to change the cdk bootstrap
command.
The `cdk.StackSet` construct creates the stack set directly if it does not exist, | ||
or updates a stack set and existing stack set instances while monitoring the stack set operation. | ||
|
||
#### Prerequisites |
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.
minor:
#### Prerequisites | |
#### Bootstrapping |
This is different from the `cdk.CfnStackSet` construct, which requires a CloudFormation stack that then deploys a CloudFormation stack set. | ||
The `cdk.StackSet` construct creates the stack set directly if it does not exist, | ||
or updates a stack set and existing stack set instances while monitoring the stack set operation. |
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 is this better than what CfnStackSet
does?
and the Stack Set Execution roles for the child accounts. | ||
* The administration role and execution role name should be specified as part of the StackSet properties. | ||
|
||
#### Usage |
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 main value of a stack set is to deploy a template to different accounts (and regions).
The usage should talk about this primary use case - how to specify the list of target accounts and regions for this stack set.
And also cover, how to configure parameters that will have different values in the target accounts/regions.
administrationRoleName: 'AWSCloudFormationStackSetAdministrationRole', | ||
executionRoleName: 'AWSCloudFormationStackSetExecutionRole', |
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.
Isn't this assuming that the execution role will be the same in all accounts? Should it be more flexible than that?
### What are we launching today? | ||
|
||
The core construct StackSet, which will enable users to define stack sets directly from CDK. | ||
A new Cloud Assembly artifact type for stack sets. CLI changes to enable deploying stack sets through CDK. |
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 CDK's cloud assembly is a public API. If we're making changes there (to the schema), the working backwards section should include the API changes there.
### Why should I use this feature? | ||
|
||
This core constuct directly creates a CloudFormation stack set vs. provisioning a single stack that deploys a stack set. | ||
The deployment also updates the stack set, updates existing stack set instances, and monitors the stack set operation. |
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.
This is not answering the question. What is the benefit of this change? "Why should I use it?"
### What is not supported? | ||
|
||
* Service Managed Stack Sets | ||
* Stack Set Instance Add/Remove through CDK |
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.
From what I understand, 'remove instance from stack set' is a very important use case for stack sets.
Without this, we will corner users into a situation where a production stack is bound to a stack set and they lose flexibility.
Will users be able to do this outside of the cdk? If so, we should have a section in the README to talk about this and the impact of an 'out of band' action.
**Creating Stack Set Instances:** | ||
|
||
Before creating stack set instances, child accounts should be bootstrapped (or custom stack set roles created) and the initial stack set deployed. | ||
Stack set instances can be added to the stack set by console/cli/api by specifying the child account id and region. |
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.
How exactly? Why not via the cdk?
### Why are we doing this? | ||
|
||
Today, CDK does not support the creation and updating of CloudFormation stack sets directly. | ||
This solution would also enable deploying to existing stack sets with low effort. | ||
|
||
CDK does provide the `cdk.CfnStackSet` construct, which could accomplish similar behavior. | ||
The difference is that the `cdk.CfnStackSet` construct is a resource in a single CloudFormation stack with the resource type `AWS::CloudFormation::StackSet`, | ||
where stack provisions the actual stack set. | ||
This requires a 1:1 mapping of parameters and tags that need to be passed from the stack to the stack set. | ||
Customer can deploy to existing stack sets, but requires some migration steps. | ||
The customer would need to create a new stack, | ||
and import the stack set into the resource `AWS::CloudFormation::StackSet`. |
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'm mostly repeating myself here, but this doesn't cover why this approach is better than using CfnStackSet
.
We should be talking about this in terms of what we are enabling for users here that didn't previously exist.
Sadly this has been abandoned for now. Reopen if you wish to continue to work on this. |
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license