sceptre
sceptre copied to clipboard
Sceptre
Add support for Stack Sets.
Allowing Sceptre to create CloudFormation StackSets. This is a feature whereby CloudFomation will create, update, or delete stacks across multiple accounts and regions. See here for docs
Is anyone working on this? Do we have any ideas of exactly what the interface would be?
Nobody is working on this, I'm considering spiking this as a hook post v2.
There is a serious limitations that would make it inappropriate for a lot of usecases though, namely that the stacksets don't work with OUs, if the OU gets updated, so it would need to be re-run on OU changes.
It is down on the Roadmap for 2.1 - so if there is any effort put toward this please do it off master rather than v1.
it will be great to see this feature implemented. as the whole AWS multi account structure and Control Tower introduced. Having easy access/usage of stackset can provide much flexibility of manage accounts in OU level.
creation of stack sets is already supported in sceptre v2.7.0
➜ sceptre create --help
Usage: sceptre create [OPTIONS] PATH [CHANGE_SET_NAME]
Creates a stack for a given config PATH. Or if CHANGE_SET_NAME is
specified creates a change set for stack in PATH.
There is a serious limitations that would make it inappropriate for a lot of usecases though, namely that the stacksets don't work with OUs, if the OU gets updated, so it would need to be re-run on OU changes.
You can use service-managed permissions to target an OU instead of a list of accounts. See feature announcement: AWS CloudFormation StackSets introduces automatic deployments across accounts and regions through AWS Organizations
For now you can use a stack that includes a AWS::CloudFormation::StackSet resource. You can include the instance template inline or pass an S3 URL. Since CloudFormation already handles that, I don't see a need for Sceptre to add special handing for the full lifecycle of a stack set.
But this way does have its problems. A CloudFormation stack won't trigger an update on a resource unless it sees that the template configuration has changed. There are times where I have a stack set that is in a stable state as far as the main stack is concerned, but a few of the stack instances are in a OUTDATED state because of some resource conflict. After resolving the conflict I want to trigger an update on the affected stack instances to get them to a CURRENT state. To do that I have to circumvent the main stack and call the UpdateStackSet API directly on the stack set.
Perhaps to handle an exceptional case like this, Sceptre could include a new stackset command with sub-commands for operating with stack instances. For the use case above, subcommands wrapping UpdateStackSet and ListStackInstances would be helpful.
I don't see a need for Sceptre to add special handing for the full lifecycle of a stack set.
I changed my mind. The wrapper stack has some problems that I already described, and so Sceptre could add value by solving them.
I don't like to include an instance template inline because static analyzers such as cfn-lint and cfn_nag ignore the content. I can avoid that by keeping the stack set template separate. But then I have to maintain some boilerplate code to put the template in S3 before I can use it in the wrapper stack. Sceptre already solves this problem for normal stacks, so it should be able to do the same for a stack set.
A stack set has a lot of properties that don't apply to stacks. It could be supported with a new config file format that captures those settings.
I don't think it's right to implement support for a stack set as a custom hook, custom resolver, or custom template handler. It seems like it needs to be supported as a new core resource type on equal footing with the stack config.
I haven't hacked on Sceptre before, but I'd like to have a go at this feature. Where would be a good place to start?
@iainelder I wonder what the utility of stack sets is when Sceptre effectively can manage stacks across regions quite effectively. It's my understanding that stack sets are useful in cases where we want to deploy a given stack across a number of regions. However, Sceptre lets you manage groups of stacks, even cross-region, even more flexibly and powerfully than via Stack Sets. So... I'm just wondering, what benefit do you get from Stack Sets that is not provided by using Sceptre to deploy numerous stacks?
StackSets work not only across multiple regions but also multiple AWS accounts. We use it as a way of deploying standard functionality across new accounts automatically when they are created; e.g. new IAM Roles, AWS Config rules, guardrails, etc... Most of this can be replicated with Sceptre and without StackSets, but you need to teach Sceptre about each account and region, it's not an automatic thing.
what benefit do you get from Stack Sets
The compelling feature of StackSets in its service-managed permission model is automatic deployments.
With service-managed permissions, you can deploy stack instances to accounts managed by AWS Organizations. Using this permissions model, you don't have to create the necessary IAM roles; StackSets creates the IAM roles on your behalf. With this model, you can also turn on automatic deployments to accounts that you add to your organization in the future.
With automatic deployment enabled, StackSets automatically deploys to accounts that are added to the target organization or organizational units (OUs) in the future.
For example, it allows you to create a stack set that targets the organization root so that all existing and future accounts will get a stack instance. It's a low-admin way to establish a security baseline across an organization. CloudFormation does the deployments automatically so that you don't have to!
In a small organization, you might be responsible for creating all new accounts, and so it might be practical to use Sceptre to provision each one. In a large organization with thousands of accounts, where you may not even be aware of all the accounts being opened and closed on a given day, it's much more practical to let the StackSets service handle it for you.
This means that Sceptre would not need to be invoked for every new stack set operation, but mostly only when the template or the settings need to change. It can still add value here by doing the undifferentiated heavy lifting that requires.
That's really interesting. I don't have any experience with any of that. Regarding your question of where to start, check our our contributing wiki and get on our slack channel where us devs hang out.
Past that, this would be a pretty significant new feature, likely involving needing to to implement a new kind of config file altogether. I'd recommend taking a look at the ConfigReader and Stack classes in our codebase and get a sense of how they work. I think you'd need to make a proposal (you can add it to this issue) in terms of what sort of way StackSets would be configured and managed. From there, we can talk about implementation path if we can agree on core architecture.
Thanks, @jfalkenstein . Where can I find the contributing wiki? Searching on GitHub I find only a link to Erlang's commit message guidance.
I started searching for create_stack and worked backwards from there. I found it all quite easy to read until I got to the ConfigReader class :-) Its construct_stacks method is complex, and I think it's one of the parts that needs to change.
I can share a proposal here on my thoughts for how it would be configured and managed and then I hope you can guide me on an implementation.
There is already an issue for refactoring the tests on ConfigReader. Maybe it would make sense for me to tackle that first, or any of the other "beginner-friendly" issues, to get experience of your development process.
@iainelder i think @jfalkenstein meant the contributing docs? also you'll want to discuss this feature with the devs on the #sceptre slack channel