-
Notifications
You must be signed in to change notification settings - Fork 9.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support user accounts and/or SAS tokens for AzureRM backend auth #16763
Comments
While playing about with this I've come up with a decent way of wrapping both #!/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" |
Any plan on implementing this? If not I could try and create a PR for this issue sometime this month. |
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? |
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: |
|
👋 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! |
@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. |
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. |
Terraform Version
Overview
The azurerm backend currently supports two methods of authentication:
Via storage account key
These are pretty heavy-handed, quoting from the azure docs
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
The text was updated successfully, but these errors were encountered: