Open marcoboffi opened 2 years ago
@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
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?
I can confirm from my own experience that manipulation of table data is possible with Azure AD authentication.
I don't understand if implementation is blocked by this or not.
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.
Unfortunately, setting and/or retrieving ACLS for Storage Tables does not support AAD authentication at this time
My understanding is that:
@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.
@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.)
@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
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.
Community Note
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)
Potential Terraform Configuration
References
0000