allow passwords only on creation

[joshua-rutherford]

This is based on #120 so that should be merged first, but this simply makes it so the user's password and hash function are fully ignored after creation.

Expected usage is now:

resource "random_password" "keyser_soze" {
  length = 16
  special = true
}

resource "gsuite_user" "keyser_soze" {
  ...
  password = random_password.keyser_soze.result
}

or (following recommended best practices):

resource "random_password" "keyser_soze" {
  length = 16
  special = true
}

resource "gsuite_user" "keyser_soze" {
  ...
  hash_function = "md5"
  password = md5(random_password.keyser_soze.result)
}

[DeviaVir]

Makes sense. And the random_password.keyser_soze.result is what we'd use for the output so that users can still be given their passwords?

[joshua-rutherford]

Yes. I plan on automating this bit here in our repos. Basically, when a commit is merged into the repo I will run terraform state list and output it to disk (this is the record of resources prior to applying the merge). Then I will run terraform apply to update the resources in GSuite. Then I will run terraform state list again and output to disk (this is the record of the resources after applying the merge). The the diff of the two list commands will show the users delete and users created and I can take appropriate action for each (i.e., extract the password for the new users and automatically email them to their recovery email with their new credentials retrieved as terraform output).

[DeviaVir]

I understand the issue with this implementation, as when a user logs in this field would be set to false outside of terraform. However, it also provides a functionality to admins that allows them to use terraform to enforce a user to change their password on next login. I'm wondering if we can fix the bugs we've found with this and document (not a fan of red tape but not seeing many other options) the pitfalls of settings this to true.

[joshua-rutherford]

Yeah, that would be awesome but the problem is that user password reset is asynchronous. That is, the admin trips the flag and the user, when they reset, trips it back. So in this case terraform cannot truly be the authoritative source of truth as the state can and should change outside of the terraform flow. If you do want terraform to be authoritative on passwords, you really have to track and manage the passwords entirely through terraform. Obviously this poses its own problems.

[DeviaVir]

Agreed. I don't see a logical way to provide admins with a way to flip a bit once that would allow them to enforce the "change password" logic on update.

[DeviaVir]

still ironing out #120 but the changes here look good.

[joshua-rutherford]

If you'd prefer I can rebase this on master without the changes from #120 to get this merged sooner.

[DeviaVir]

@joshua-rutherford if it's no trouble, there's still a bit of thinking/ironing out on #120 to do I believe

[joshua-rutherford]

@DeviaVir, I have rebased on master but there is one question I have for you. Since I was basing this on #120 I did touch the update logic in creation. Do you want me to add that there because right now creating an existing GSuite user will not set the password or force a user to change their password. That may or may not be desired.

[DeviaVir]

@DeviaVir, I have rebased on master but there is one question I have for you. Since I was basing this on #120 I did touch the update logic in creation. Do you want me to add that there because right now creating an existing GSuite user will not set the password or force a user to change their password. That may or may not be desired.

That's for the import on creation function right? I think we'd not want to touch passwords for existing users either so it makes sense to leave that out (or take it out if it currently does do that)

[joshua-rutherford]

At present, if you define a resource that corresponds to a resource in GSuite already and you define the password or hash_function it will modify the resource in GSuite. It will not however trip force the user to change their password at next login. I'm open to what ever you'd prefer here as I'm not intending to use that bit of logic but I'd suspect that not editing the fields in the above case would be best.

[DeviaVir]

Yes, long as we document clearly that we only set user.ChangePasswordAtNextLogin on creation of a new user I think that logic is sound

[joshua-rutherford]

Updated to only touch passwords on creation of new accounts and added descriptive comments to example.

[DeviaVir]

Included in https://github.com/DeviaVir/terraform-provider-gsuite/releases/tag/v0.1.36