Support for stored access policy/set container ACL

[OSalamaPret]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: 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

When creating a SAS (Shared Access Signature) there is an option to associate with a stored access policy, which gives greater control over the SAS.

To set up the stored access policy on a container level requires calling Set Container ACL, which we do not currently seem to have a resource for in AzureRM.

azurerm_storage_data_lake_gen2_filesystem and azurerm_storage_data_lake_gen2_path have options to specify ACL directly on a file/folder, but it's not possible to use this to set container ACL/stored access policy

azurerm_storage_container does not offer any ACL control either

I haven't got much experience working with azurerm but it appears we generally prefer embedding the ACL configuration resources within the main resource creation, in which case we'd have to modify both azurerm_storage_data_lake_gen2_filesystem and azurerm_storage_container to support this.

Worth noting you can only have 5 stored access policies on a container, so it feels it would be easier to manage & avoid quota errors if they're all defined together.

New or Affected Resource(s)/Data Source(s)

azurerm_storage_data_lake_gen2_filesystem azurerm_storage_container

Potential Terraform Configuration

resource "azurerm_storage_account" "example_storage" {
  name                     = "examplestorage"
  resource_group_name      = "examplegroup"
  location                 = "West Europe"
  account_tier             = "Standard"
  account_replication_type = "ZRS"
  is_hns_enabled           = "true"
}

resource "azurerm_storage_data_lake_gen2_filesystem" "example" {
  name               = "example"
  storage_account_id = azurerm_storage_account.example_storage.id
  stored_access_policies = [
    {
      policy_id   = "examplefullpolicy"
      start       = "2022-06-03T13:00:00Z"
      expiry      = "2022-06-04T13:00:00Z"
      permissions = "rcl"
    },
    {
      policy_id = "exampleemptypolicy"
    }
  ]
}

References

https://docs.microsoft.com/en-us/rest/api/storageservices/define-stored-access-policy https://docs.microsoft.com/en-us/rest/api/storageservices/set-container-acl

[szymonbr]

I fully support the request. In my project it's mandatory to rely on storage container policies. Hence the only workaround right now is to use null_resource along with running az command in local-exec provisioner. Maybe there could be other alternatives. But it doesn't matter. New azurerm_storage_account_blob_container_policy resource should definitely be added to the provideder. And data source azurerm_storage_account_blob_container_sas should be updated accordingly to choose whether to create standalone SAS token or based on specified azurerm_storage_account_blob_container_policy resource.

Additional justification of the request

A stored access policy provides an additional level of control over service-level shared access signatures (SASs) on the server side. Establishing a stored access policy serves to group shared access signatures and to provide additional restrictions for signatures that are bound by the policy. You can use a stored access policy to change the start time, expiry time, or permissions for a signature. You can also use a stored access policy to revoke a signature after it has been issued.

ref. https://docs.microsoft.com/en-gb/rest/api/storageservices/define-stored-access-policy

[erorubrz]

I find this also very important for my current project. Also big on security, since it allows deletion of the policy negating the SAS URL in case of information leak.