Encypting boot volume using OCI vault keys without instance destroy/create

[edvinas31]

Hi, I got a situation where I have existing environment running in production and I want to encrypt it's boot volumes with recently created OCI vault key (AES 32). After doing terraform plan I see that terraform wants first to delete an instance and then create it with a OCI vault key. At this time, we cannot allow instance recreation so it would not work for us.

My workaround was using OCI console to stop an instance, detach boot volume, assign encryption key, attach boot volume and start an instance. After doing that I have noticed that terraform still wants to delete and recreate an instance. So, I assumed that after doing modifications in OCI console terraform in state file did not find any changes. My next step was to modify state file, which terraform is using for that environment (by adding value to "kms_key_id" in "source_details" in state file). After that terraform did not show any infrastructure changes.

My question is if it is possible to change state in any other user friendly way or if there is any mechanism which could help me to avoid instance recreation?

[edvinas31]

Also, I have read this article https://www.hashicorp.com/blog/detecting-and-managing-drift-with-terraform. Let's assume I made changes in OCI console (attached oci_vault_kms key to a boot volume) without letting terraform know it. I would say that it is a drift. So if I run terraform refresh command I expect to see changes in my state file (oci_kms_key to be added to a boot volume). However this is not happening and terraform asks to recreate an instance

[edvinas31]

Any suggestions?

[varmax2511]

Hi @edvinas31 -- thanks for reaching out.

• kms_key_id is not updatable and hence a forceNew parameter prompting terraform to recreate https://registry.terraform.io/providers/hashicorp/oci/latest/docs/resources/core_instance

• Upon changing the kms_key_id, from OCI console terraform doesn't detect a diff on this field because the upstream service doesn't return it as part of their GET call, leaving terraform with no way to detect a diff on it

The scenario that you did via Console is possible via terraform as well. Stop the instance via Terraform, detach the volume and then set a kms key id to it. No need to update the instance config However, in terraform you also want that if the instance is recreated, the KMS key should be used together with the boot volume passed as source for launching this new instance.

[edvinas31]

Hi @varmax2511 thank you for your answer. Maybe you could tell me what would be a workflow of doing such thing using terraform (stopping the instance, detaching/attaching volumes). For example if I want to stop the instance should I change resource "state" parameter to "STOPPED"? https://registry.terraform.io/providers/hashicorp/oci/latest/docs/resources/core_instance#state

[krilor]

I'm currently facing the same you @edvinas31 and I see no good way of managing this with Terraform alone. Seems like I'll have to fall back on the oci cli to get this sorted.

@varmax2511 Just wondering, but is there a reason for not having/adding a oci_core_boot_volume_kms_key resource in the provider? Leaning on the same api as https://docs.oracle.com/en-us/iaas/tools/oci-cli/3.15.2/oci_cli_docs/cmdref/bv/boot-volume-kms-key.html, I mean