You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 27, 2021. It is now read-only.
Despite the comment here it seems that the password field of the user resource is not fully ignored on updates.
Based the behavior of the API (i.e., the user password can only be written, never read) it is generally a bad idea to store the password in the the resource state because it will result in terraform detecting that changes need to be made to the remote despite there not being any ability to actually confirm that it has or has not changed on subsequent reads. As a result, I have to create the user and immediately remove the password to prevent terraform plan and terraform apply from thinking there is a change as shown below.
Additionally, the change_password_next_login field should be omitted from terraform state as it will become out of sync when the user manually changes their password (as they should) on their next login.
Both of the above prevent me from using this resource in an automated way in a CI/CD pipeline. I propose a slight modification to the behavior.
Omit both password and change_password_next_login from the resource to prevent terraform from tracking them at all.
Set a password on creation only using one of two methods:
a. At the provider level such that all newly created users get the same password.
b. At the resource level such that the initial password is randomly generated.
Set the change_password_next_login true on creation only.
The only down side to this is that with random password generation we must get it out of terraform some way and I'm not sure the best way.
The text was updated successfully, but these errors were encountered:
Upon actually beginning to implement this I want to do two things:
Allow a user to provide the initial password and
Allow the user to keep the initial password out of their repositories.
So my thinking right now is to keep the password and hash_function properties and drop the change_password_next_login. We'd only populate the password, hash_function and change_password_next_login fields on creation only and leave them empty on all updates and imports. The change_password_next_login field would be initialized to true.
Despite the comment here it seems that the
password
field of the user resource is not fully ignored on updates.Based the behavior of the API (i.e., the user password can only be written, never read) it is generally a bad idea to store the password in the the resource state because it will result in terraform detecting that changes need to be made to the remote despite there not being any ability to actually confirm that it has or has not changed on subsequent reads. As a result, I have to create the user and immediately remove the password to prevent
terraform plan
andterraform apply
from thinking there is a change as shown below.Additionally, the
change_password_next_login
field should be omitted from terraform state as it will become out of sync when the user manually changes their password (as they should) on their next login.Both of the above prevent me from using this resource in an automated way in a CI/CD pipeline. I propose a slight modification to the behavior.
password
andchange_password_next_login
from the resource to prevent terraform from tracking them at all.a. At the provider level such that all newly created users get the same password.
b. At the resource level such that the initial password is randomly generated.
change_password_next_login
true on creation only.The only down side to this is that with random password generation we must get it out of terraform some way and I'm not sure the best way.
The text was updated successfully, but these errors were encountered: