feature request: lock state subcommand with lock key

[GeoffMillerAZ]

Feature description

It would be great if the CLI supported a remote state locking command. You can forcefully unlock a remotely locked state but it would be nice if you could lock the state remotely too. I would like to be able to lock the state and have it return a lock key or be able to specify a lock key. Then only operations with that key would be able to proceed. Then I would like to be able to unlock the state using the key. It may be nice to also have another option to be able to put a comment on the lock. If anyone else tries to manipulate the state, they would see that it was locked by another user and it could display to them the comment for the lock.

Use cases

CI/CD pipelines or manual builds

Especially due to terraform not supporting multiple targets on an apply statement or inter-module resource dependencies, it would be nice to be able to issue several terraform apply commands in a needed order. I can use the -refresh="false" flag to make sure that each of these commands doesn't take forever to complete. If I have a sizeable number of commands to run, then having it refresh each time would be a big slow down. But having -refresh="false" isn't exactly safe to do if another person or CI/CD process is also able to modify the state.

State File Repair

Another use case could arise if you need to repair or change a state file. Imagine you want to do a series of state mv commands to refactor your resource names or organization to make them more readable without actually destroying and recreating. It would be annoying/dangerous to have a state that changes in between commands.

Blocking Changes Due to Emergency

Yet another use case is to lock a state file due to an emergency. I may identify an issue where if a terraform operation were to run it may be dangerous. It would be nice to be able to lock the state and give the reason/ticket number as to what the issue is.

Example

terraform state lock
output: locked with key: xyz
terraform plan -lock-key=xyz
I can then review my changes and run the following commands knowing that they will apply the resources in the exact order that I need them applied in and without fear of other operations occuring in between:
terraform apply -refresh="false" -auto-approve -lock-key=xyz --target=module.accounts.module.iam_init_sandbox

terraform apply -refresh="false" -auto-approve -lock-key=xyz --target=module.accounts.module.iam_init_staging

terraform apply -refresh="false" -auto-approve -lock-key=xyz --target=module.accounts.module.iam_init_tools

terraform apply -refresh="false" -auto-approve -lock-key=xyz --target=module.accounts.module.sandbox.module.vpc_sandbox

terraform apply -refresh="false" -auto-approve -lock-key=xyz --target=module.accounts.module.staging.module.vpc_staging

terraform apply -refresh="false" -auto-approve -lock-key=xyz --target=module.accounts.module.tools.module.vpc_tools

This example only has a few commands but in real life I have dozens in the list. But then you would just unlock the state with the key.

terraform state unlock -lock-key=xyz

I currently do something similar but without the security of having the state locked and I just have to communicate with my team very well and deactivate any automation that could interfere. I also use this to prove my infra can be destroyed and recreated.

Related issue

#17285
Although my biggest reason for wanting to lock remote states is very similar to this other issue, I can see more use cases than just the pipelined approach to applying state commands. So I can see room for both features.

[GeoffMillerAZ]

#17203 closing as duplicate. Found after I submitted

[ghost]

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.