Feedback Wanted!

[ekristen]

Please provide your feedback. Here are some of the issues.

• [rfc] [feature] DAG Deletion Order #298
• [rfc] i18n support - multiple languages - need feedback #388

[eaudetcobello]

The feature I'm waiting for the most is being able to specify only delete resources with these tags. Right now AFAIU it's only possible to exclude resources from deletion.

For example if I have EC2Address with a tag "Name", I should be able to say... delete all EC2Address with Name == "capi-*", do not touch any other EC2Address.

My use case for this feature is Cluster API test runs that tag all the resources they create with "capi-<cluster-name>". These resources are created on a shared account, so nuking everything isn't desirable.

[ekristen]

@eaudetcobello I'm considering adding a feature to flip from exclusion to inclusion via #327 -- there's much to consider with adding this behavior.

[BwL1289]

Exclude all AWS managed IAM policies as well as resources created by CDK. Essentially, reset the AWS account to how it was at initial creation.

---

EDITs:

1. Apologies, don't believe AWS managed policies can be deleted at all.
2. I am using the awesome community template provided for AWS Control Tower and attempting to adapt it to CDK. Will provide this to the community when complete.

[ekristen]

@BwL1289 and @eaudetcobello you can sort of already filter for removal using Global Filters Feature combined with the invert flag, but it would only work with a single tag, with Filter Groups you could possible extend this further.

[BwL1289]

@ekristen a technique I'm using for CDK is:

presets:
  # Exclude cdk resources from being nuked
  cdk:
    filters:
      # Exclude resources with cdk in the name
      __global__: # Catch all for all resources
        - type: "contains"
          value: "cdk"
        - type: glob
          value: "*cdk*"
        - property: Name
          type: "glob"
          value: "*cdk*"
        - property: ARN
          type: "glob"
          value: "*cdk*"
        - property: tag:aws:cloudformation:stack-name
          value: "CDKToolkit"

Will this work as I expect? Note: I know there's a ton of redundancy here. Guidance is appreciated.

[BwL1289]

As I'm finalizing CDK template, two other feature requests:

1. Filter default AWSServiceRoles and their associated IAM Policies
2. Filter S3 Bucket Policies

[ekristen]

Default service roles are already filtered.

Bucket policy isn't a separate resource and I'm not sure there's an argument to make it one. Why would you want to nuke a bucket policy but not the bucket?

[BwL1289]

Default service roles are already filtered

Thanks. Is this in the docs? Happy to help add it if not.

Why would you want to nuke a bucket policy but not the bucket?

I wouldn't. Similar to IAMRolePolicyAttachment, I want to retain the bucket policy along with the Bucket. Looking at S3Bucket source code, this may be default behavior as well. This is likely because S3 Bucket policies aren't nameable and can't be referenced outside of the bucket. For clarity, might be worth including in the docs as well. Happy to help with this.

[nimaft]

I'm trying to nuke multiple accounts with one config file, but I cannot figure out how to specify the credentials for each account. Is it even possible? I understand I can pass multiple account name/aliases in my config file, but I dont see a way add the profile associated with those accounts. Thank you so much!

[ekristen]

@nimaft you can only run against a single account at a time, but you can configure as many accounts as you want in the configuration file.

[Xylon2]

I tried using this but it's very complicated to configure and use. I ran it one time and it seemed to delete it's own access key and didn't even delete my VPCs which was all I needed it for.

[ekristen]

@Xylon2 its a complex tool. It'll delete everything period, including access keys. If you want open an issue including your config and logs.

What do you fix complicated? How would it be easier?

[zack-is-cool]

It would be nice to have a clear expectation of what properties you can filter on each resource type.

Today I was attempting to exclude a CloudTrailTrail using tags. CloudTrail objects have tags. But I don't believe this tool will allow you to filter on tags? see: https://github.com/ekristen/aws-nuke/blob/main/resources/cloudtrail-trails.go#L60-L63

Please correct me if I'm wrong 😄

I'll submit an issue if you confirm we should be able to filter on this

thanks in advance @ekristen

[ekristen]

@zack-is-cool unfortunately not all resources support both properties and even if does not all have their tags exposed. PRs welcome! I am currently working on auto-documentation based on property data when it exists, upcoming releases will have better documentation, there is a PR in progress #391

Please feel free to open an issue for the cloud trail objects missing tags.

[jarrodallan]

I hope this is the right thread, apologies if not.

A feature I would appreciate when deleting resources, specifically CloudFormation, triggering the remove but not waiting for the delete completion. CloudFormation delete should hopefully take care of the majority of the cleanup itself but it takes a decent amount of time to delete every resource in a stack.

Perhaps a method where the delete is triggered for all stacks then each is checked once the deletes have been triggered, rather than waiting for the full deletion before starting to delete other resources.

[ekristen]

@jarrodallan async deletes are in the works.

[benriou]

Feature request : could you please consider supporting wildcards in resource-types.exclusions ?

This would avoid to list any existing sub-service on a given AWS service.

Before :

resource-types:
  excludes:
    # These services are not sold by AWS anymore
    - "OpsWorksInstance"
    - "OpsWorksCMServer"
    - "OpsWorksCMBackup"
    - "OpsWorksApp"
    - "OpsWorksUserProfile"
    - "OpsWorksLayer"
    - "OpsWorksCMServerState"

After :

resource-types:
  excludes:
    # These services are not sold by AWS anymore
    - "OpsWorks*"

[ekristen]

@benriou this is covered via #302 and there is now a PR pending merge today to address it #479

[ekristen]

Any additional feedback please open an issue or comment on an existing one. I'm closing this issue now. Thank you everyone.