awslabs / awslabs/aws-deployment-framework
[FEATURE] protect accidentally stack overwrite with unique stack names
- Dominant language
- Python
- Stars
- 699
- Forks
- 235
- Avg merge
- 20h 53m
- Merged PRs (30d)
- 7
Description
**Problem**
Consider the following pipeline configuration
```yml
- name: foo
default_providers:
source:
provider: codecommit
properties:
account_id: 111111111111
build:
provider: codebuild
properties:
image: "STANDARD_5_0"
targets:
- path: /foo
properties:
template_filename: foo_template.yml
stack_name: foo
- path: /bar
properties:
stack_name: bar
template_filename: bar_template.yml
- path: /foo
properties:
template_filename: other_template.yml
```
Related to the [docs][docs-cf] the stack_name is constructed with: - `(String) default: ${ADF_STACK_PREFIX}${PIPELINE_NAME}`
That means in the following example the 1st and 3rd target will have the same stack name. Because those stacks will be deployed into the same accounts the 3rd stack will overwrite the 1st one. Maybe there are use cases where this is wanted but I think in most cases this is an unwanted behavior and in addition dangerous.
In addition due to the fact that the `stack_name` variable is able to be changed, it is also possible that other pipelines overwrite the current stack.
As mentioned this is maybe sometimes a wanted functionality, but I would love to have a possibility to protect stack names.
**possible solution**
I could think about a solution like
```yml
- name: foo
...
targets:
- path: /foo
properties:
template_filename: foo_template.yml
stack_name: foo
unique_stack_name: true
....
```
Maybe adding exceptions would be also possible in the above case
```yml
- name: foo
...
targets:
- path: /foo
properties:
template_filename: foo_template.yml
stack_name: foo
unique_stack_name: true
unique_stack_name_exceptions:
- {pipeline-name}/[target_name|target_number]
....
```
I would in addition love if it would be possible to make this a default behavior, maybe in the bootstrap repository configuration.
Currently it is super easy to accidentally delete some stacks because of the mentioned issue. Would be super nice to have an additional guard.
**Update:**
In addition it would be super nice to have this functionality in a script which is also put into the pipelines repository.
That one could be used in custom CI pipelines in feature branches.
[docs-cf]: https://github.com/awslabs/aws-deployment-framework/blob/master/docs/providers-guide.md#cloudformation
Contributor guide
Research direction
Start with docs/providers-guide.md at the CloudFormation provider section linked in the issue to understand how stack_name is constructed. No implementation files, tests, or entry points are named; the work is not ready to pick up until the desired uniqueness rules, exceptions, default configuration, and optional pipeline script are defined.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, python
- Domain
- cloud, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100