<p>Recently I've read a good book about Terraform that I think answers your question (Terraform Up &amp; Running 2nd edition. ISBN-13: 978-1492046905. ISBN-10: 1492046906). </p>

<p>Basically it says that all data in Terraform state file is stored in plain text, including sensitive data. The author says that at the moment of the writing (May 2019) there is no real solution for this, but workarounds like encryption and IAM to control user access based on policies (the book talks about AWS, so you have to find the Azure equivalent and prevent unauthorized access to the state file).</p>

<p>You can find more details on Chapter 3, pages 78 and 79. There is also an open issue at Github about this: <a href="https://github.com/hashicorp/terraform/issues/516" rel="nofollow noreferrer">https://github.com/hashicorp/terraform/issues/516</a>.</p>

CC BY-SA 4.0
2020-03-24T14:34:39.493Z
In the link you posted here, there is a closed issue about someone arguing that it its possible to store your credentials outside the fstab, in a credentials file (this may answer your second question with cloud-init).
cabreracanal
CC BY-SA 4.0
2020-04-09T23:16:42.413Z
At least the keys would not end up in some temp files somewhere. But I guess they still reside in the Terraform state.
kap
CC BY-SA 4.0
2020-04-09T23:18:50.643Z
Thank you, I will have a look at the book. There is IAM also for Azure and I guess for most other  AWS features there are Azure equivalents.
kap
CC BY-SA 4.0
2020-03-24T12:07:14.720Z
2020-03-24T12:07:14.720Z
cabreracanal
<p>What is a good way to mount an Azure File Storage automatically during provisioning on VMs?</p>

<p>There is a <a href="https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mount-azure-file-storage-on-linux-using-smb" rel="nofollow noreferrer">Microsoft doc</a> describing how a file share can be mounted in general. This requires that Azure CLI is installed and a user is logged in.</p>

<p>As an alternative, I have created a working setup using terraform working on local host:</p>

<p>First, the existing storage account needs to be defined:</p>

<pre><code>data "azurerm_storage_account" "storage-account" {
  name                = "storageaccount"
  resource_group_name = "RG-storage-account"
}
</code></pre>

<p>When a VM is provisioned, the share is mounted by a remote execution provisionier:</p>

<pre><code>resource "azurerm_virtual_machine" "vm" {
  # ...
  # stuff

  provisioner "remote-exec" {
    inline = [
      "sudo mkdir -p /mnt/${data.azurerm_storage_account.storage-accoun.name}/share",
      "sudo mount -t cifs //${data.azurerm_storage_account.storage-account.name}.file.core.windows.net/share /mnt/${data.azurerm_storage_account.storage-account.name}/share -o vers=3.0,dir_mode=0755,file_mode=0755,serverino,username=${data.azurerm_storage_account.storage-account.name},password=${data.azurerm_storage_account.storage-account.primary_access_key}",
    ]
  }
}
</code></pre>

<p>Similar it is also possible to inject the mount to <code>/etc/fstab</code>, also by using cloud init.</p>

<p>However, after applying, the key (accessed as <code>primary_access_key</code>) remains in the terraform state. Is this considered safe? Is there a way to delete the key from the state? Also, when using cloud-init, the key will remain in the custom data of the VM.</p>

<p>Is there another safe way to mount data on the VM without storing the keys?</p>

<terraform><azure>
Mount Azure FileShare using terraform
kap
# Mount Azure FileShare using terraform

(Asked by: username_0 on 2020-02-07)

What is a good way to mount an Azure File Storage automatically during provisioning on VMs?
There is a Microsoft doc describing how a file share can be mounted in general. This requires that Azure CLI is installed and a user is logged in.
As an alternative, I have created a working setup using terraform working on local host:
First, the existing storage account needs to be defined:
data "azurerm_storage_account" "storage-account" {
  name                = "storageaccount"
  resource_group_name = "RG-storage-account"
}

When a VM is provisioned, the share is mounted by a remote execution provisionier:
resource "azurerm_virtual_machine" "vm" {
  # ...
  # stuff

  provisioner "remote-exec" {
    inline = [
      "sudo mkdir -p /mnt/${data.azurerm_storage_account.storage-accoun.name}/share",
      "sudo mount -t cifs //${data.azurerm_storage_account.storage-account.name}.file.core.windows.net/share /mnt/${data.azurerm_storage_account.storage-account.name}/share -o vers=3.0,dir_mode=0755,file_mode=0755,serverino,username=${data.azurerm_storage_account.storage-account.name},password=${data.azurerm_storage_account.storage-account.primary_access_key}",
    ]
  }
}

Similar it is also possible to inject the mount to /etc/fstab, also by using cloud init.
However, after applying, the key (accessed as primary_access_key) remains in the terraform state. Is this considered safe? Is there a way to delete the key from the state? Also, when using cloud-init, the key will remain in the custom data of the VM.
Is there another safe way to mount data on the VM without storing the keys?

**Tags:** terraform, azure


---

## 1 answers

### Answer by username_1 on 2020-03-24. Score: 2

Recently I've read a good book about Terraform that I think answers your question (Terraform Up & Running 2nd edition. ISBN-13: 978-1492046905. ISBN-10: 1492046906).

Basically it says that all data in Terraform state file is stored in plain text, including sensitive data. The author says that at the moment of the writing (May 2019) there is no real solution for this, but workarounds like encryption and IAM to control user access based on policies (the book talks about AWS, so you have to find the Azure equivalent and prevent unauthorized access to the state file).

You can find more details on Chapter 3, pages 78 and 79. There is also an open issue at Github about this: <https://github.com/hashicorp/terraform/issues/516>.

> **Comments:**
> **username_1**: In the link you posted here, there is a closed issue about someone arguing that it its possible to store your credentials outside the fstab, in a credentials file (this may answer your second question with cloud-init).  
> **username_0**: At least the keys would not end up in some temp files somewhere. But I guess they still reside in the Terraform state.  
> **username_0**: Thank you, I will have a look at the book. There is IAM also for Azure and I guess for most other  AWS features there are Azure equivalents.  

---

