AzureRM backend support for users to plan without permission to apply

[aidapsibr]

Current Terraform Version

0.15.0

Use-cases

Enable users to access a particular storage container with only Storage Blob Data Reader for performing no-lock plans to validate changes locally.

Attempted Solutions

Attempted to assign the role and leverage the use_azuread_auth option on the backend to access a particular storage container.

Proposal

Currently, authorization fails even with use_azuread_auth and appropriate data roles, because the backend tries to listKeys on the storage account. Updating the backend flow to skip this step and instead use AzureAD tokens to access the blobs would enable this directly. This should be a non-breaking change I believe since storage account owner (listKeys) has the blob data access roles.

References

#20831 - The title of this was misleading, you no longer directly need to provide a key, but the backend will still use the keys to access blobs.

[aidapsibr]

This work would also enable Storage Blob Data Contributor to be sufficient for running apply and locked plans as an intended side-effect.

[JustinGrote]

Curious why this has been backlogged so long. The code just has to be adjusted to use RBAC for the operations rather than an account key, and the way it currently exists means each state file must have its own storage account for security since you basically use the "root password" for all operations, making RBAC like OIDC meaningless and misleading in the documentation.

Users who do not know this esoteric detail are going to think they are safe by putting their state files in separate containers within a storage account, whereas anyone who compromises the terraform access (or simply makes a mistake) can delete all the files in all containers, meaning the annoying overhead of one storage account per state file is necessary for proper security and isolation.

If this is not going to be remediated anytime soon then at least warn people via the documentation that it still uses legacy account key access on the backend despite the "RBAC" configuration and best practice is one storage account per state file or environment.

[aidapsibr]

I'm just the one who opened the issue, our solution was to do the same as you described with separate storage accounts which is really unfortunate. Wish this would be prioritized.

[JustinGrote]

@aidapsibr my apologies, I saw you were able to edit the tags and assumed you were a maintainer :)

[yann-soubeyrand]

Isn’t this issue fixed by using use_azuread_auth = true in Terraform azurerm backend configuration block?

[BzSpi]

I don't think so since user must be Data Owner to have the lock permission.

[KoenR3]

This is still a major security issue. If you disable access keys on a storage account, remote state no longer functions. The ability to remove the use of root keys is critical in moving everything to managed identities.

[JustinGrote]

The latest versions seem to do this correctly, I've been able to not provide an access key and have everything in TFState work with RBAC, so my tfstate for different environments can be two containers in the same storage account and work fine now.