Support for AzureAD to connect to Storage Table APi's

[marcoboffi]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Currently _storage_useazuread flag in provider configuration works only with Blob and Queue API's.
Authorization with Azure AD for Table is now available in preview (in ALL region).
Can you add support also for Storage Table API's ?

New or Affected Resource(s)

• azurerm_storage_table, azurerm_storage_table_entity

Potential Terraform Configuration

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

References

• 0000

[magodo]

@marcoboffi Thank you for submitting this :+1: During the development on this feature, I found that the API (at least for 2020-08-04) only supports for the table operations, but not the ACL operations of the table, which is necessary given current implementation of the provider.

See: https://github.com/Azure/azure-rest-api-specs/issues/17485

[beau-witter]

Based on the table on this page it appears that at least Blob, Table, and Queues can be managed via Azure AD now. It seems there is at least a way to do it for the File Shares as well (at least as SMB), so maybe that could be added as well?

[commakoerschgen]

I can confirm from my own experience that manipulation of table data is possible with Azure AD authentication.

[marcoboffi]

I don't understand if implementation is blocked by this or not.

[manicminer]

I don't understand if implementation is blocked by this or not.

Unfortunately, it is.

The Storage Tables API now supports AAD authentication to some extent and this will be partially enabled by #24798. Unfortunately, setting and/or retrieving ACLS for Storage Tables does not support AAD authentication at this time - this means that whilst AAD auth will be enabled for the azurerm_storage_table_entity resource & data sources, it won't yet be fully enabled for the azurerm_storage_table resource.

AAD auth support also won't extend to Files at this time, as this API does not properly support AAD authentication as yet.

See official docs for a breakdown of supported auth methods for different operations.

[jan-hudec]

Unfortunately, setting and/or retrieving ACLS for Storage Tables does not support AAD authentication at this time

My understanding is that:

1. that's the same situation as for Blobs, and
2. ACLs are only applicable to key access, so if you want AAD (Entra) authentication because you want to turn the key authentication off, you won't be using the ACLs anyway (and maybe using Entra role assignments intead).

[manicminer]

@jan-hudec Table ACLs are handled a bit differently and without introducing a breaking change, we need to read/get them regardless of whether it's explicitly configured.

Note that in the upcoming changes, I have broken down the API calls by auth method, so key auth is only actually used when retrieving/setting the ACLS, all the other API calls will use AAD auth if configured.

[jan-hudec]

@manicminer, the main reason to want Entra/AAD auth is to disable the key authentication altogether, in which case the reading of ACLs is going to fail. So it should be considered not a failure, but absence of any ACLs. (The proof of concept where I had the requirement has long since been scratched, but others will have similar requirement for security reasons.)

[tombuildsstuff]

@jan-hudec it's the migration paths which are going to complicate matters, since you can have both Entra and Shared Key access enabled either individually or simultaneously.

In addition we'd need to validate what happens to any ACLs when using both Shared Key and Entra auth - and when moving from Shared Key -> Entra -> Shared Key, it's not necessarily sufficient to just skip the check, since we'd want to be able to detect any changes here

[jkroepke]

To unblock this kind of issue, would it be possible to move ACLs to an dedicated resource?

Then, azurerm_storage_table could be used with AzureAD and users which is using ACL can use shared key together with the dedicated terraform resource.