aws-nuke
aws-nuke copied to clipboard
rebuy-de
Allow nuke of "prod" labelled accounts with optional flag
Hi, I know that you prevent the nuke of "prod" accounts (with the "prod" keyword in account alias). And I understand the reason behind this. However, I think it should be up to the user to decide whether he wants to nuke an account or not (whatever the name). At least, an additional flag should allow this, ex: '--force-prod-nuke' or something similar.
I am in a situation where I have to provision accounts begin created and named by anotther department. And guess what... they have "prod" in the alias. So I'm kind of stuck. I can either:
- use another tool that is less restrictive (too bad, this one does a fine job!)
- change the alias before nuking, then nuke, then restore the alias...
- create a ticket and hope this feature can be implemented somehow ;)
Thanks !
I'd suggest a fork to remove hard-coded string "prod" or changing alias naming convention from "prod"
With flag, someone will write a blog post or wrap it in a shell script and allow curl | bash. It's way too easy for a human mistake and greater unintended consequences.
As a workaround I suggest using a script including aws cli command to replace the account alias with a value that does not contain 'prod'
aws iam create-account-alias --account-alias
@dxciberaws That's exactly what I am doing in practice but I think it would be better to let the user decide which accounts he wants to nuke instead of imposing a hardcoded safeguard. Or maybe display a warning message if this pattern is found in the alias instead of abruptly stopping the program.
There are quite a bit of safety bypass required to get to the point of deleting an account arbitrarily named prod. I would like to have a way to whitelist prod; in the meantime, we just named our prod account something else.
Hi, Nothing about this request ? I know this is a “human security” but an option to disable is also a “human security” ... We can also blacklist account ID in config.
Hello. Sorry for the late reply. I have very mixed feelings about this. On the one hand I understand that it is hard to work around this limitation in some cases and sometimes even not possible to work around this at all. On the other hand this is an ultimately dangerous tool. There a many comments out there that say such a tool should not exist at all.
Currently I do not see an safe way for disabling this feature for some, while having one safeguard less for others.
As a slight modification of this thread, I'm trying to use aws-nuke as an audit tool (looking for non-IaaC resources). For accounts currently matching the production filter, I'd love to be able to run aws-nuke in dry-run only mode. Being able to produce reports on drift, even if aws-nuke couldn't delete those directly, would be awesome.
We have an alias naming standard of xxx-prod and xxx-nonprod (hundreds of accounts).
Therefore aws-nuke won't work for us.
Are we expected to break our own naming standard just for the sake of this tool ?
I appreciate the intention to protect us from ourselves, but you shouldn't dictate what naming standards people use for their accounts.
By all means set a default, but if you really want to allow as many people as possible to use aws-nuke safely, why don't you make this configurable ?
A reason I cannot use this tool as well which is disappointing. We have nonprod which triggers and those are centralized under a cloudops group that standardized the aliases. An option to override this with a couple extra prompts of "are you really really really sure you want to kill PROD" would be nice.
This would have been a nice way to clean up production accounts we close. But it seems the author is not willing to trust the Team members that this tool was build for.
So I'll find another tool.
@svenwltr I appreciate your thoughts on the danger of this tool. Yes indeed it can be very dangerous and your attempt at a safety mechanism is appreciated. As an I.T. person, however, it is very normal for me to potentially dangerous things every day. I am accustomed to being very very careful. With that said, it's still nice to have a very deliberate safety check that prevents major accidents. I propose that it is possible to have a very deliberate bypass switch that would negate account aliases and allow us to nuke prod. The mechanism just has to be something that a person could not possibly create by mistake.
For example, in the DNS world, it's very common for me to have to create a TXT record with a key in it to validate that I own that domain.
In the aws-nuke world, perhaps we could go create a special token in the cloud that nuke checks for. The token could be anything with a special name such as an EC2 instance, or an S3 bucket with a file in it. If you went with the S3 idea the bucket name could be defined in the config and then in the bucket you could have us create a file named something like "nuke_bypass_ok." Or maybe have us create an IAM user named "the-nukinator" and put a tag on it named "hasta-la-vista-baby."
Think of how bash/linux forces elevated privileges. You can't just "sudo kaboom." You have to configure the sudoers file and allow certain privileges first, as the root user. THEN you can use sudo. It takes actual effort to wield the powers of the universe. Then, if someone makes a mistake after all of that, they get a warning the first time and the second time they're fired from their job. This idea of working amongst very dangerous things every day is very normal for us. AWS-Nuke is the same as "sudo rm -Rf /" It's normal for us to be one mistake away from destroying our world at any time. Thus, many of us here are requesting that you please allow us that similar "normal" functionality. AWS-Nuke isn't really dangerous to us...it's normal.
Maybe a solution for this is implementing a whitelist? Allow to delete the account only if are explicitly set on the whitelist (is exist) otherwise work in the standard way, including the "prod" protection and will solve some of this issues.
I want to add that while I forked this repo and just removed the check, I initially wanted to run aws-nuke in our nonprod/dev account only to find out that because our account alias was aws-org-nonprod, aws-nuke refused to run. On top of that, our AWS accounts are managed by another team and we can't change the alias of the account.
I would suggest if the concern is that someone would accidentally run this tool against a production envionment to add a few confirmation messages if the name includes the name prod + a flag to bypass it or explictly stating the account like @CGarces suggestion. At that point, there's nothing that someone who decides to run it against an environment can say since they made a conscious effort to bypass the check, and can't sue @svenwltr about how they deleted prod.
My favorite approach is that one posted by @lohman: https://github.com/rebuy-de/aws-nuke/issues/443#issuecomment-1102767038
I just did not have time for implementing this yet.
We also have the same naming standards as mentioned in https://github.com/rebuy-de/aws-nuke/issues/443#issuecomment-882523239
It will be nice to have it configurable instead of hard coding. We have a workaround by changing the alias name before aws-nuke and then updating later the operation but it's not the best solution. Having the keyword configurable will make it generic and will let us have our accounts with the alias as needed.
Here is the LOC: https://github.com/rebuy-de/aws-nuke/blob/6092ed818b8e6708b0496386cdc8b5559ab72bb0/pkg/config/config.go#L138
One can simply clone the repo, change that line and build the tool with go build. That took me about 5 minutes.
I encourage you to do the same, instead of commenting about how this is not working for you.
Thanks for this awesome tool. My 2cents on the topic: Keep the safety guard, but an optional (not too easy) override would be appreciated.
https://github.com/rebuy-de/aws-nuke/pull/983 could solve this in a more generic way and also allow nuking accounts without alias
