Nuke accounts without alias

[tenjaa]

Hi,
unfortunately our accounts do not have an alias and therefore we cannot use aws-nuke.

What do you think about adding a fallback for accounts without alias?

Currently there is a warning. I would propose to still print the warning and then make the prompt to nuke the account dependent on the account id, but still confirming that one wants to nuke an account without alias.

Idea of fallback:

The specified account doesn't have an alias.
For safety reasons you need to specify an account alias.
Your production account should contain the term 'prod'.

Do you really want to nuke the account with the ID 000000000000?
Do you want to continue? Enter 'no alias/000000000000' to continue.
> no-alias/000000000000

[cmantsch]

I think the intent of this is an additional safety net to not accidentally nuke production. Due to this requirement, you have to actually log into the account and set up an alias and can't blindly copy/paste account ids you found somewhere in the company intranet.

What is preventing you from setting up aliases for your accounts?

[tenjaa]

I agree that it would be a good idea. But in our case of a bigger enterprise we get accounts handed like they are without permissions to set an alias ourselves.

So that you cannot simply copy/paste ids, how about something like there must be a string SSM parameter i-really-want-to-nuke-this or a file in S3.
I would agree to make it as annoying as possible. Anything to be able to use it at all.

[AMMullan]

We're working through an account factory where we will be spinning up hundreds of accounts and a good proportion of these will be "sandbox" accounts that need to be nuked daily.

Having to give each account an alias is needless for anything other than having it as a requirement for using aws-nuke because we don't allow IAM Users and nothing else uses the alias.

I feel like there must be an alternative to an account alias as a way of safeguarding production accounts - but at the end of the day you have to define the config and explicitly say what accounts to target and then you have to pass the no-dry-run flag - if anyone has gone to that effort and put production Account ID's in the account list to be nuked without testing first then perhaps we really should let them... ;)

[stefanmcshane]

Massively agree with @AMMullan. Adding alias' adds an inconvenience, and doesn't prohibit potential destructions. Assuming that all protected accounts will include the name prod in the alias is also farsical. The MIT license offers zero warranties, and is offered at the user's own risks.

I have opened a PR #983 which gives the ability to disable this pointless check. In the event that the code owners do not accept this change, we can install the library with the change by cloning github.com/stefanmcshane/aws-nuke, checking out disable-alias and running go install

[tenjaa]

@der-eismann Do you have an opinion on this topic?

[edumgui]

I've upvoted @stefanmcshane's PR.

Also, I was thinking about opening a PR and adding a field in the YAML to override the "prod accounts" filter because we use three-letter environments (dev, pre, pro), so our account-blocklist aliases contain 'pro', not 'prod'.

As it seems to be hardcoded here, replacing it with a variable from the YAML will allow users to set their custom filter for production accounts aliases. For example, setting '-pro' if they are using suffixes, instead of the current filter that is not allowing to nuke accounts like 'test-photoproduction-reaction'.

[tenjaa]

In the meantime I am using this https://github.com/tenjaa/aws-nuke-prod
Small GitHub action that just syncs this repo daily into the fork

[ekristen]

Greetings @tenjaa @edumgui @stefanmcshane @AMMullan

A feature called Bypass Alias Checks has been implemented in the newly promoted fork and successor to this project. Please take a look and let me know if you run into issues.

---

Please see a copy of the notice from the README about the deprecation of this project. Sven was kind enough to grant me access to help triage and close issues and pull requests that have already been addressed in the actively maintained fork. Some additional information is located in the welcome issue for more information.

Caution

This repository for aws-nuke is no longer being actively maintained. We recommend users to switch to the actively maintained fork of this project at ekristen/aws-nuke.
We appreciate all the support and contributions we've received throughout the life of this project. We believe that the fork will continue to provide the functionality and support that you have come to expect from aws-nuke.
Please note that this deprecation means we will not be addressing issues, accepting pull requests, or making future releases from this repository.
Thank you for your understanding and support.