Repository: hashicorp/terraform-provider-azurerm

Issue #2977: Cannot create azurerm_storage_container in azurerm_storage_account that uses network_rules
Created: 2019-02-28T15:05:56Z
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


Terraform (and AzureRM Provider) Version
Terraform v0.11.11

provider.azurerm v1.21.0


Affected Resource(s)


azurerm_storage_account
azurerm_storage_container

Terraform Configuration Files

resource "azurerm_storage_account" "test-storage-acct" {
  name                     = "${var.prefix}storacct"
  resource_group_name      = "${var.resgroup}"
  location                 = "${var.location}"
  account_tier             = "Standard"
  account_replication_type = "LRS"
  network_rules {
    ip_rules                   = ["aaa.bbb.ccc.ddd/ee"]
    virtual_network_subnet_ids = ["${var.subnetid}"]
  }
}
resource "azurerm_storage_container" "provisioning" {
  name                  = "${var.prefix}-provisioning"
  resource_group_name   = "${var.resgroup}"
  storage_account_name  = "${azurerm_storage_account.test-storage-acct.name}"
  container_access_type = "private"
}

Debug Output

azurerm_storage_container.provisioning: Error creating container "philtesting1-provisioning" in storage account "philtesting1storacct": storage: service returned error: StatusCode=403, ErrorCode=AuthorizationFailure, ErrorMessage=This request is not authorized to perform this operation.
RequestId:a7f9d2e1-701e-00b3-4e74-cf3b34000000
Time:2019-02-28T14:45:53.7885750Z, RequestInitiated=Thu, 28 Feb 2019 14:45:53 GMT, RequestId=a7f9d2e1-701e-00b3-4e74-cf3b34000000, API Version=, QueryParameterName=, QueryParameterValue=


Expected Behavior
Container can be created in a storage account that uses network rules
Actual Behavior
After applying a network_rule to a storage account I cannot provision a container into it.  My public IP is included in the address range specified in the network rule.  I can successfully create the container via the Azure portal
Steps to Reproduce


terraform apply

Duplicate issue #14792: Storage Account should not try to use data-plane APIs (e.g. error reading share properties)
Created: 2022-01-04T15:42:13Z
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


Terraform (and AzureRM Provider) Version

Affected Resource(s)


azurerm_storage_account

Terraform Configuration Files

# 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: https://keybase.io/hashicorp
Debug Output

Panic Output

Expected Behaviour
Unless specific arguments (like share_properties) are actively used, the provider should not try to invoke "data-plane" APIs.
The Storage Account APIs are basically split between "control-plane" (always accessible) and "data-plane" (access can be limited via firewall in various setups). A reasonable use case would be to provision and manage the Storage Account via Terraform, but not provide any access to the data-plane to it (e.g. containers could be configured by the end application, so there would be no need for TF to invoke data-plane APIs).
Ideally the data-plane APIs should not be invoked if the properties are not provided), or there should at least be an argument (or flag of sort) to allow to suppress that behavior and let a Storage Account to be managed only in terms of publicly reachable APIs and settings.
See this code for reference, and the various invocation of the specific clients.
Actual Behaviour
Unfortunately the provider always tries to invoke some data-plane APIs even when there would be no need for it, requiring direct connectivity between the TF runner and the Storage Account.
For instance, you can create a StorageV2 account, and never bother using File Shares, including a property like share_properties. However during refresh TF will try to probe such property from the API, failing if data-plane APIs are not reachable.
Error: reading share properties for AzureRM Storage Account "XXXXXXX": storage.FileServicesClient#GetServiceProperties: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded


Steps to Reproduce
Create a Storage Account with kind=StorageV2 and setup firewall rules so Terraform is unable to connect to it.
Important Factoids

References
Similar issues and unexpected behavior can be found in:

#12485
#6659

Closing comment (2022-01-04T17:36:48Z): hi @lorenzo-biava
Thanks for opening this issue.
Taking a look through this appears to be a duplicate of #2977 - rather than having multiple issues open tracking the same thing I'm going to close this issue in favour of that one; would you mind subscribing to #2977 for updates?
Thanks!