Terraform: Force-destroying AWS IAM Users

[MattSurabian]

I'd love to be able to manage all of our organizations existing IAM users in
terraform. Backporting the data into .tfstate is straightforward, but using
terraform to destroy aws_iam_user records is not.

The limitations I've encountered would relate to any aws_iam_user resource,
whether created by terraform or backported, provided user credentials had been
generated for it (user/pass or access keys) at some point after creation.

The API won't allow deletion of a user that has credentials associated with
it. Much like #4005, I suspect the ideal scenario is to remove any "login
profiles" or "access keys" before deleting the user.

If a pull request was created that accomplished this would it be accepted?

[stack72]

Hi @MattSurabian

We would love to be able to get a PR that helps in this area. According to the IAM docs, deleting a user would need

The user must not belong to any groups, have any keys or signing certificates, or have any attached policies.

Look forward to seeing a PR for this work!

Thanks

Paul

[apparentlymart]

It would be great to have Terraform be able to take care of these steps automatically. Right now though the extra step of manually deleting the credentials can be valuable as a form of manual confirmation that the user is intended to be deleted: deleting a user accidentally is disruptive because it will invalidate the user's password and access keys, and these cannot be automatically restored.

So I would suggest having a new boolean attribute on aws_iam_user that would opt-in to the new proposed behavior, with the default being the current "safe" behavior. This way we retain the "safety net" but make it possible to deal with this extra confirmation step entirely within Terraform, by manually adding that additional attribute.

[MattSurabian]

I personally agree with @apparentlymart, I think some kind of force property would be great.

Precedent wise the AWS CLI expects users to remove all linked data explicitly before deleting the user. The only other tool I'm used to doing IAM user management with is Ansible, which opts to delete all linked data automatically with no safety net what-so-ever.

Terraform is already a tool that allows folks to wield tremendous power in their infrastructure and potentially cause serious damage, so I wonder how much offering a safety net in this instance makes a difference. I also wonder if automatic deletion might allow for easier iteration on this feature. Deprecating a force property seems more of a burden for users than having to add in specific calls to delete user data first; especially when the inability to manage that data is likely their biggest impediment to adopting Terraform more broadly in their org (this is currently the case for our org anyway). The ideal incarnation of this feature would allow for full control of all linked data. This would allow the project to track as close as possible to the CLI (is this even a priority for Hashicorp?) and facilitate complete user management aside from just basic creation and deletion; would we still want to have a force property then?

I can't promise a speady turn around on the full featured PR, but I could certainly manage either automatic deletion or a boolean force property; the question is where do we go from there?

[tkellen]

@phinze any thoughts here?

[tkellen]

a slightly unrelated but relevant concern to consider for user management in terraform (yeah yeah, we should just use vault):
https://github.com/hashicorp/terraform/issues/1604#issuecomment-137797595

[tkellen]

ping @phinze

[tmatilai]

I guess this is at least mostly fixed by the force_destroy option in the aws_iam_user resource.

[tmatilai]

Oh, seems that the force_destroy option only affects to API keys, not to the login profile, i.e. password. :/

[sachincab]

Yes, noticed that force_destroy does not affect login profile.
aws_iam_user.xxxxx: Error deleting IAM User xxxxx: DeleteConflict: Cannot delete entity, must delete login profile first.

[stack72]

Hi @sachincab / @tmatilai

I have just extended the force_Destroy to remove the LoginProfile as well now #9583

Hope this helps

P

[tkellen]

Thanks @stack72--really looking forward to seeing that land!

[stack72]

just merged it - it will be in Terraform 0.7.8 :)

[sachincab]

@stack72 , thanks for fixing this.

[rhenning]

Hi all. Any thoughts on whether or not force_destroy should apply to MFA devices & attached policies? Output below from v0.7.11 fwtw.

Got these two while testing some workflows today:

* aws_iam_user.testuser1: Error deleting IAM User testuser1: DeleteConflict: Cannot delete entity, must detach all policies first.
    status code: 409, request id: 930583a0-ac4d-11e6-82de-23747074d3cf

* aws_iam_user.testuser1: Error deleting IAM User testuser1: DeleteConflict: Cannot delete entity, must delete MFA device first.
    status code: 409, request id: aa41b1b7-ac4d-11e6-bb3f-3b4c7a310c65

Removing the manually applied policy and deactivating the user's MFA token allowed apply to continue. The former would never happen IRL for our use case but the latter could if following AWS's recommended practice of allowing IAM users to activate their own MFA using a restricted IAM policy.

Thanks!

[rhenning]

Hi @MattSurabian and @stack72. Regarding my previous comment/question, here's a WIP PR that aims to extend force_destroy to remove a user's MFA devices as well. It follows the same pattern as access key removal.

https://github.com/hashicorp/terraform/pull/10262

[stack72]

MFA deletion now included

[MattSurabian]

It's exciting to see this coming together! Thanks for everyone's hard work.

[gozer]

Would be interesting to see Virtual MFA devices get cleaned up as well. It's virtually identical to the MFA cases, except for the api calls becoming ListVirtualMFADevicesPages, DeactivateVirtualMFADevice, etc

[hashibot[bot]]

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.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.