0
votes

I am working in a Terraform code. The requirements are:

  • Put TF state file onto Azure storage account. The access key to the storage account must be secured.
  • My TF program authenticate using Service Principal which client_id, client_secret, tenant_id should be encrypted and put onto Azure storage account.

My idea is to use a single KeyVault which contains all above secured secrets. But how a terraform program could secure the access key, connection to access the KeyVault? This is about management plane.

According to: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow , this provides a way of coding authorization request that the application has already registered on Azure AD service previously. How can I apply the similar idea with Terraform code? Or may you suggest any better way to realize the idea?

Thanks a lot.

2

2 Answers

1
votes

You can use Azure DevOps pipeline and provide the service principal secrets as secure variable group (can be linked from the KV) or as a service connection. Check: https://blog.gft.com/pl/2020/03/04/secure-terraform-delivery-pipeline-best-practices-part-1-2/ (disclaimer: I am the author) and https://blog.gft.com/pl/2020/04/24/automating-infrastructure-deployment-on-azure-using-ci-cd-pipeline-and-terraform/

0
votes

I don't think it's possible to encrypt both the storage access key and the secret of the service principal. For the backend state, you can use the service principal to authenticate so that you do not expose the storage access key. You just need to grant the right permission to the service principal. Take a look at this.

But for the service principal, if you stored things like client_id, client_secret, tenant_id in the storage account, you need to get them before execute the Terraform code. It also needs the storage access key or the service principal secret or SAS token.

So I think you can use the Azure CLI to authenticate: Log in with the service principal. Then you do not need to provide the azurerm with the secret. But actually, it's also not absolutely secure. You also can find the access token in the path ~/.azure/. For this, you can change the permission for this path. If you also think it's not secure, you can take a look at the Managed identity of the VM. But you need to have a VM before all the things.