Support user accounts and/or SAS tokens for AzureRM backend auth

[glenjamin]

Terraform Version

0.11.0

Overview

The azurerm backend currently supports two methods of authentication:

Via storage account key

These are pretty heavy-handed, quoting from the azure docs

Giving out your storage account key is like sharing the keys of your storage kingdom. It grants complete access.
This is especially relevant if you want to use the remote state data provider, as there's no way to grant read-only access using this method.

It would be good to support Shared Access Signatures, which are a form of authorization token derived from the storage account key that can impose restrictions like expiry time or more granular permissions.

Via service principal credentials

The other method currently supported is to use management API access credentials to grab the storage account key on demand, this is neater as it then uses the same credentials as the rest of the API. This shares most of the granularity downsides of the above approach, but there's not a lot that can be done about that due to the way azure IAM works.

The other downside about this approach is that service principals are a separate type of authentication credential that is managed separately from user accounts - so every user who needs to use terraform needs to have their own service principal. Support for using user account credentials was added to the terraform provider in hashicorp/terraform-provider-azurerm#42 - it would be good to get this into the backend as well.

References

hashicorp/terraform-provider-azurerm#42

[glenjamin]

While playing about with this I've come up with a decent way of wrapping both terraform init and az to grab a valid storage account key and pass it in as backend config

#!/bin/bash
set -eo pipefail

az account set --subscription "$subscription_id"
state_storage_access_key=$(
  az storage account keys list \
    --resource-group "$state_storage_resource_group" \
    --account-name "$state_storage_account" \
    --query '[0].value' -o tsv
)

terraform init \
  -backend-config="storage_account_name=$state_storage_account" \
  -backend-config="container_name=$state_storage_container" \
  -backend-config="access_key=$state_storage_access_key"

[alphalzh]

Any plan on implementing this? If not I could try and create a PR for this issue sometime this month.

[alphalzh]

For supporting this, the vendor azure-sdk-for-go must be updated, since in later versions of azure sdk they added support for using SAS tokens to access blob storage. Shall I just create a PR for updating the dependency first?

[perbergland]

I believe that the best solution for this would be to use the new (still in preview) RBAC data access for storage containers. Then the user could either pass their own short-lived access token for the "https://storage.azure.com/" resource id to terraform, and there could additionally be some convenient smartness based on the current parsing of the persisted Azure CLI access tokens in ~/.azure/accessTokens.json and use the refresh token to create a data access token.

Reference:
https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad-app

[tombuildsstuff]

Dependent on hashicorp/go-azure-helpers#8

[tombuildsstuff]

👋

Just to let you know that support for authenticating using SAS Tokens has been added in #19440 - we're also intending on supporting Azure CLI authentication in the near future :)

Thanks!

[haodeon]

@tombuildsstuff I've been trying to configure a remote backend using a storage account with Azure AD.

I've configured a test account with "Reader" role in the subscription and "Storage Blob Data Contributor" on a container within the storage account. However, in my testing it fails with "does not have authorization to perform action 'Microsoft.Storage/storageAccounts/listKeys/action'"

My use case is to have one storage account which holds my state files divided into separate containers. Azure AD RBAC determines access to the different containers. At the moment, even with Azure CLI authentication, if it retrieves the storage account key, one can read all the state files in all the containers.

Is this use case supported? It would be great if this could be clarified in the docs.

[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.