-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
Cannot destroy attached security groups #13593
Comments
Hi @awilkins 👋 Thank you for taking the time to file this. Given that it's been a bit of time, and there's been a number of Terraform and AWS Provider releases since then, can you confirm whether this is an issue you are still running into? |
If #265 remains open, then it's very likely that this is still an issue. The thread in that ticket identifies another edge case managing Security Group attachments - you can't have zero SGs on an ENI, and you can't have more than 5 either, so any config changes that result in temporary attachment counts outside the bounds of 1-5 should involve an intermediate step that either temporarily removes an existing SG (there should probably be a warning that you have to override involved here because of the potential for service dropout), or creates a security group that permits no traffic to serve as a temporary placeholder where an SG would be left with no rules. |
Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you! |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Terraform 0.12.23
Provider 2.64.0
As per #4982, the provider often attempts to destroy security groups that it should know are still attached to resources, because it did the attaching. If you're destroying a whole graph this is probably OK, if you just did something to taint the SG, not so great.
SGs can't be destroyed when attached to resources, so this just times out, eventually.
Workaround :
name_prefix
, notname
create_before_destroy
You have to be OK with suffixed names for this.
Potential Resolution
Detach security groups from all the known points where they are attached before attempting to delete them.
The rub : you can't detach all security groups from any given entity, but you are often in the situation where the only security group on an entity is the one you are trying to delete.
In these cases, you should be able to attach another security group temporarily, before attaching the new group after the tainted group has been destroyed and recreated.
Every VPC has a default group which can't be deleted. This may be a viable candidate ; but it also allows all ingress traffic from anything in that group and also permits all egress traffic to the internet. If something breaks before this group is attached, you have an entity left quite open in a security sense.
Instead : how about create a temporary SG with no rules, attach this to any entity in the config graph which will have zero SGs as the result of a tainted SG being destroyed, and detach it again after recreation / re-attachment.
The text was updated successfully, but these errors were encountered: