Terraform-provider-azurerm: AzureRM provider doesn't support setting CORS for blob storage

[hashibot]

_This issue was originally opened by @joaocc as hashicorp/terraform#8825. It was migrated here as part of the provider split. The original body of the issue is below._

---

Terraform Version

Terraform v0.7.3

Affected Resource(s)

azurerm_storage_account

Expected Behavior

There is currently no way to configure CORS via Terraform.

Reference here: https://msdn.microsoft.com/en-us/library/azure/dn535601.aspx

This means that storage accounts created via terraform cannot be used for things as simple as serving images or js scripts to be used in a website.

Actual Behavior

Cloud storage doesn't allow requests from a different origin.

[tombuildsstuff]

Hey @joaocc

Thanks for opening this issue :)

Taking a look into this - it appears this option isn't available in the Azure SDK yet - and isn't in the Swagger either, which it's generated from. As such I've opened this issue asking for the Swagger to be updated to expose this property so that we can add support for this.

Thanks

[nbering]

@tombuildsstuff I'm not sure that this is correct. It may not be part of the ARM API, but it is certainly part of the storage API. It's part of the set-blob-service-properties action. I recall using this in the JavaScript SDK for a project over a year ago. I'm not sure if there's some architectural reason that the Terraform provider can't use that, though. It would seem to me that some calls are already being made to the Storage API to create blobs and containers.

Edit: Documentation link. https://docs.microsoft.com/en-us/rest/api/storageservices/set-blob-service-properties

[maetthu]

This is actually affects all Azure Storage products, not just Blob Storage. You can set CORS rules for

• Blob: https://docs.microsoft.com/en-us/rest/api/storageservices/set-blob-service-properties
• File: https://docs.microsoft.com/en-us/rest/api/storageservices/set-file-service-properties
• Queue: https://docs.microsoft.com/en-us/rest/api/storageservices/set-queue-service-properties
• Table: https://docs.microsoft.com/en-us/rest/api/storageservices/set-table-service-properties

[katbyte]

Exists and requires use of the storage SDK: https://github.com/Azure/azure-sdk-for-go/tree/51228ee60b238eaa5a9d53adc82ebd8b321bca4f/storage

[illfang]

Non-deprecated Storage SDK:

Azure Storage Blob SDK for Go
https://github.com/Azure/azure-storage-blob-go

[alexvicegrab]

Any update on this? Would be great to set the CORS headers using terraform.

[tombuildsstuff]

👋

Just to give an update here - this is blocked on the migration to the new Storage SDK which we plan to do at some point once some blockers have been resolved.

Thanks!

[iorlas]

So, when? I mean, what it could be, months? Years? Is there any label for blocker issues?

[tomasaschan]

@tombuildsstuff Are there any issues tracking the blockers to this one? Any way I can help sorting this out? Turns out I need this one too :)

[tombuildsstuff]

@tomasaschan at this time unfortunately we're blocked on a series of issues in the Azure Storage SDK for Go (some of which have been fixed, but others have no timeline/aren't planned to be fixed), including (in no particular order):

• https://github.com/Azure/azure-storage-blob-go/issues/86
• https://github.com/Azure/azure-storage-blob-go/issues/47
• https://github.com/Azure/azure-storage-blob-go/issues/96
• https://github.com/Azure/azure-storage-blob-go/issues/59
• https://github.com/Azure/azure-storage-blob-go/issues/42

To be honest, given we're been blocked from adopting this SDK for 12-18 months, I have a feeling we may end up forking the existing Storage SDK to add the new functionality (which we'd rather not do, as we then have to maintain this going forwards) - since I don't believe this alternate SDK is going to be suitable for our use-cases anytime soon. On the flip side, we'd rather not write/maintain another SDK - so we've been in a bit of a holding pattern with this one, unfortunately. In the interim I've reached out through some internal channels to work out the best way to proceed here.

Thanks!

[tomasaschan]

We're doing this with an azure_template_deployment at the moment. Not pretty, but works and doesn't require anything outside of terraform on the machine orchestrating the deployment:

data "template_file" "cors_config" {
  template = <<CORS
    {
      "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
      "contentVersion": "1.0.0.0",
      "parameters": {
        "storageAccountName": {
          "type": "string",
          "metadata": {
            "description": "Specifies the name of the Azure Storage account."
          }
        }
      },
      "resources": [
        {
          "type": "Microsoft.Storage/storageAccounts",
          "apiVersion": "2018-07-01",
          "name": "[parameters('storageAccountName')]",
          "location": "[resourceGroup().location]",
          "resources": [
            {
              "name": "default",
              "type": "blobServices",
              "apiVersion": "2018-07-01",
              "properties": {"cors": {"corsRules": [{"allowedOrigins": ["${join("\",\"", var.documents_cors_domains)}"], "allowedMethods": ["DELETE","GET","OPTIONS","PUT"], "maxAgeInSeconds": 3600, "exposedHeaders": ["*"], "allowedHeaders": ["*"]}]}},
              "dependsOn": ["[concat('Microsoft.Storage/storageAccounts/', parameters('storageAccountName'))]"]
            }
          ]
        }
      ]
    }
  CORS
}

resource "azurerm_template_deployment" "cors_settings" {
  name                = "cors-settings"
  resource_group_name = "${azurerm_resource_group.rg.name}"
  deployment_mode     = "Incremental"

  parameters = {
    "storageAccountName" = "${azurerm_storage_account.documents.name}"
  }

  template_body = "${data.template_file.cors_config.rendered}"
}

[ricohomewood]

@tombuildsstuff @katbyte is this now possible to deliver now that you have migrated to the giovanni 3.0 SDK and already released queue_properties as part of the 1.32 milestone for setting CORS on Storage Accounts for queues as per here: ?https://github.com/terraform-providers/terraform-provider-azurerm/pull/3859 I would assume that this would be a simple thing to now deploy, probably in the 1.33 milestone? Do you still need to label this with hashibot/ignore?

[tombuildsstuff]

👋

Taking a look at the example scenario provided by @tomasaschan in this comment, I'd agree with @ricohomewood's comment that I believe this functionality is now supported by Terraform (via #3859).

If you're looking to use Terraform to configure CORS for another Storage resource - would you mind opening a new issue with more details about the use-case? However since the Azure Provider now supports configuring the CORS settings for a Storage Account I'm going to close this issue for the moment.

Thanks!

[ricohomewood]

Hi @tombuildsstuff I think this may have been closed in error as this case is talking about configuring CORS for blob service whereas the 3859 release only fixed this for queue_properties in the Storage Account as such blob_properties would still not be available to configure which should be possible now with the updated storage SDK? Correct me if im wrong and that blob_properties would be available for setting CORS?

[tomasaschan]

@tombuildsstuff I agree; this was probably closed in error.

The scenario outlined in this issue is _technically_ supported, since it's possible with an ARM template, but I agree with @ricohomewood that this should be natively supported by a Terraform resource (either the blob storage account/container itself, or a new resource for CORS settings).

The fact that it's possible to work around the lack of native support for this using inlined ARM templates, makes the issue lower priority, but (IMO) does not make it resolved completely.

[tombuildsstuff]

@ricohomewood @tomasaschan sorry - thanks for letting us know.

[ricohomewood]

Thanks @tombuildsstuff being that queue_properties is already delivered i assume the scope of work for just adding blob_properties is relatively small? Would this be something that could be delivered in the next milestone? Thanks

[tombuildsstuff]

@ricohomewood

[..] being that queue_properties is already delivered i assume the scope of work for just adding blob_properties is relatively small? Would this be something that could be delivered in the next milestone?

Unfortunately this isn't something we've got a timeline for at the moment, since we're focused on 2.0 right now - but I'd agree this (should) be fairly quick to add

[worldspawn]

Hey folks, I am running Azurerm 1.34.0 and am experiencing this. I had an existing storage resource defined and created and then added a queue_properties block and now consistently get:

"\ufeff<?xml version=\"1.0\" encoding=\"utf-8\"?><Error><Code>InvalidXmlDocument</Code><Message>XML specified is not syntactically valid.\nRequestId:681cc93d-f003-001f-4cb8-7c7f2f000000\nTime:2019-10-07T02:41:47.5887920Z</Message><LineNumber>2</LineNumber><LinePosition>56</LinePosition><Reason>Unexpected value for Version.</Reason></Error>" error: invalid character 'ï' looking for beginning of value

Here is the complete resource. The location is australiasoutheast.

resource "azurerm_storage_account" "storage" {
    name = "${local.storagename}"
    location            = "${data.azurerm_resource_group.appgroup.location}"
    resource_group_name = "${data.azurerm_resource_group.appgroup.name}"
    account_kind        = "Storage"
    account_tier        = "Standard"
    account_replication_type = "LRS"
    enable_https_traffic_only = true

    queue_properties {
      cors_rule {
        allowed_headers = ["*"]
        allowed_methods = ["GET"]
        allowed_origins = ["*"]
        exposed_headers = ["*"]
        max_age_in_seconds = 300
      }
    }

    tags                = {
        environment = "${local.env}"
        region = "${local.region}"
        workspace = "${local.workspace}"
    }
}

[tombuildsstuff]

@worldspawn out of interest if you add/remove a tag to the storage account first does that error still occur? It appears that Storage Account is using an older API version (whilst we're requesting a new one) - adding/removing a Tag in Azure normally allows that to be updated

[ricohomewood]

@tombuildsstuff any chance this could make it in the v1.37.0 milestone due to its relative small scope for blob_properties?

[worldspawn]

@tombuildsstuff I gave that a go and no change.

Error: Error updating Azure Storage Account `queue_properties` "dbtauprodpreprod": queues.Client#SetServiceProperties: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: error response cannot be parsed: "\ufeff<?xml version=\"1.0\" encoding=\"utf-8\"?><Error><Code>InvalidXmlDocument</Code><Message>XML specified is not syntactically valid.\nRequestId:21b83f73-d003-004f-578f-7d1d41000000\nTime:2019-10-08T04:17:25.7489508Z</Message><LineNumber>2</LineNumber><LinePosition>56</LinePosition><Reason>Unexpected value for Version.</Reason></Error>" error: invalid character 'ï' looking for beginning of value

[pixelicous]

Would also appreciate support for this, so i can get full automation, thank you. 🙏

[ricohomewood]

@tombuildsstuff Is there a reason this issue is on the Blocked milestone? There's actually nothing blocking this now I believe? Any update if this oldest ticket could be added to the next milestone as it looks fairly straight forward to add? Thanks

[ronnie-webb]

@brunhil will this be in the next release?

[tomasaschan]

🎉

[hashibot[bot]]

This has been released in version 2.0.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.0.0"
}
# ... other configuration ...

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!