Adding support for non-dedicated accounts

[aaronsteers]

Functional Description

Is there any way to support nuking environments that do not have fully dedicated accounts? Similar to #65 which added support for specific resource types, I'd like to delete resources: (A) when the resources have a matching tag, and/or (B) when the resource has an ID (ARN on AWS) which is contained within a specific list or tracked resource IDs

The latter case (B) would require that somewhere we are logging the IDs of resources which were created (not yet solved for) and would be needed in order to give an option for resources that do not support tags needed to implement (A). (For example: ECS clusters have an ARN but do not yet support tagging.)

Has this been considered or is there a way to implement this today? And if not, is it something you would consider in the roadmap and/or accept a PR for?

Sample Workflow

One option for an adapted workflow would look like:

1. During the terraform design process, we apply a uniquely generated tag to apply to all (taggable) resources.
2. For resources known to not be taggable (such as ECS) we log the ARNs into a text file or into state variables (or both)
3. Nuke called twice, once with an arg like --nuke_tag=terraform-autotag-8fsCd and once with an arg like --resource_list=created_resources.txt

Additional Background

The specific use case is that (mostly for training labs and POCs), we don't always have the luxury of being able to create new AWS accounts, but we still want to have confidence that we can ALWAYS successfully destroy an environment after we are finished with it.

Thanks!

[brikis98]

This is not currently supported. Adding support for nuking resources with specific tags (for resources that support tags) makes sense, and a PR for that is welcome.

As for supporting nuking resources with specific IDs, that seems like a more esoteric use case. cloud-nuke is not a Terraform-specific tool, so I'm not a fan of building something into it to track IDs specific to Terraform functionality. Moreover, I'm not certain the approach would work in the general case. For example, to delete some resources, you must first delete all dependent resources: e.g., to delete a VPC, you must remove subnets; to remove subnets, you must remove attached security groups; and so on. So if you passed in the ID of just a VPC, would we automatically clean up the attached subnets and security groups, or only if you passed in the IDs for ALL of those? The former goes against the "delete only these IDs" concept, but the latter seems practically very hard to do, and unlikely to be used.

[aaronsteers]

@brikis98 - Those are great points regarding the resource ID list, and I have to agree with you that the dependency-hierarchy problem would be a significant challenge.

Per your feedback, I may look deeper into adding the tag-filter option (for those resources that support tags) - unless of course someone else picks this up first 😄.

[aaronsteers]

I noticed that tag-based exclusions are now becoming a thing (https://github.com/gruntwork-io/cloud-nuke/issues/103) - perhaps this would ease the way for tag-filtering as well... (?)

[aaronsteers]

FYI - I've kicked off a PR to hopefully start to making progress on this: #109

Feedback and contributions welcome. :)

[james00012]

Tag based filtering capability has been added recently. Closing this issue.