-
Notifications
You must be signed in to change notification settings - Fork 718
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nuke accounts without alias #971
Comments
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? |
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 |
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... ;) |
Massively agree with @AMMullan. Adding alias' adds an inconvenience, and doesn't prohibit potential destructions. Assuming that all protected accounts will include the name 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 |
@der-eismann Do you have an opinion on this topic? |
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'. |
In the meantime I am using this https://github.com/tenjaa/aws-nuke-prod |
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 text was updated successfully, but these errors were encountered: