Skip to content
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

Created users with login profiles shouldn't reset their passwords #244

Closed
SmartassSkeleton opened this issue May 5, 2022 · 4 comments · Fixed by #271
Closed

Created users with login profiles shouldn't reset their passwords #244

SmartassSkeleton opened this issue May 5, 2022 · 4 comments · Fixed by #271

Comments

@SmartassSkeleton
Copy link

SmartassSkeleton commented May 5, 2022

Description

I recently created a bunch of users using the iam-user module in this repository using a for_each loop:

module "iam_users" {
  source   = "terraform-aws-modules/iam/aws//modules/iam-user"
  version  = "~> 4.20.0"
  for_each = var.users_map

  name          = each.key
  force_destroy = true

  create_iam_access_key         = each.value.create_iam_access_key
  create_iam_user_login_profile = each.value.create_iam_user_login_profile
}

I later on wanted to add a bunch of other IAM users in a 2nd iteration and make sure that they get a temporary password and require their reset on the first login using the same code.

When I terraform plan with the 2nd batch of users, I see that the created users in the first iteration will have new temporary passwords and will require to reset them on first login again:

# module.iam_groups_users.module.users.module.iam_users["user1"].aws_iam_user_login_profile.this[0] must be replaced
-/+ resource "aws_iam_user_login_profile" "this" {
      + encrypted_password      = (known after apply)
      ~ id                      = "user1" -> (known after apply)
      + key_fingerprint         = (known after apply)
      ~ password                = "REDACTED" -> (known after apply)
      ~ password_reset_required = false -> true # forces replacement
        # (2 unchanged attributes hidden)
    }

  # module.iam_groups_users.module.users.module.iam_users["user2"].aws_iam_user_login_profile.this[0] must be replaced
-/+ resource "aws_iam_user_login_profile" "this" {
      + encrypted_password      = (known after apply)
      ~ id                      = "user2" -> (known after apply)
      + key_fingerprint         = (known after apply)
      ~ password                = "REDACTED" -> (known after apply)
      ~ password_reset_required = false -> true # forces replacement
        # (2 unchanged attributes hidden)
    }

I am aware of the password_reset_required variable, but this forces me to change my variable configuration after applying the code.

Versions

  • Module version [Required]: 4.20

  • Terraform version:

Terraform v1.1.9
on linux_amd64
  • Provider version(s):
+ provider registry.terraform.io/hashicorp/aws v4.11.0

Reproduction Code [Required]

terraform plan/apply

Expected behavior

I'd expect the module to create the login profile with a generated password in the first place, but ignore changes that are made outside it's control, specially when it's with sensitive data like passwords/PGP.

Maybe add a lifcecycle meta-block?:

lifecycle {
    ignore_changes = [
      password_length,
      password_reset_required,
      pgp_key,
    ]

Edit:
I found out that this is an AWS provider issue tracked in here: hashicorp/terraform-provider-aws#23567

Actual behavior

password_reset_required is static and requires actions after terraform apply. This makes me have to worry about my variables post applying a new configuration.

@github-actions
Copy link

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

@github-actions github-actions bot added the stale label Jun 15, 2022
@github-actions
Copy link

This issue was automatically closed because of stale in 10 days

@antonbabenko
Copy link
Member

This issue has been resolved in version 5.3.1 🎉

@github-actions
Copy link

github-actions bot commented Nov 8, 2022

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants