Support for Resource Instances within Azure Storage Networking

Lachlan-White commented 3 years ago

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

In the case of utilising an Azure Synapse Workspace within a Managed Virtual Network, to connect this Workspace to a secured Azure Data Lake or Storage account the use of a Resource Instance within the Azure Storage Account Networking Blade can be utilised.

This capability is in public preview but is soon to be a recommended way in which to implement connectivity between Microsoft Managed Virtual Networks and the Managed identity from within your tenant. https://docs.microsoft.com/en-us/azure/storage/common/storage-network-security?tabs=azure-portal#trusted-access-based-on-system-assigned-managed-identity

New or Affected Resource(s)

azurerm_storage_account
azurerm_stoage_account_network_rules

Potential Terraform Configuration

resource "azurerm_storage_account" "example" {
  name                = "storageaccountname"
  resource_group_name = azurerm_resource_group.example.name

  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "LRS"

  network_rules {
    default_action             = "Deny"
    ip_rules                   = ["100.0.0.1"]
    virtual_network_subnet_ids = [azurerm_subnet.example.id]
    resource_instance_type     = "Microsoft.Synapse/workspaces"
    resource_instance_name     = "mysynapseworkspace"
  }
}

References

drjwelch commented 3 years ago

Same applies for other services, in our case data factory. For anyone else arriving here, one workaround is to use self-hosted IR and allow its subnet through the firewall.

a30000931 commented 2 years ago

over a year since being raised - any news on this?

WaitingForGuacamole commented 2 years ago

Agreed, an update would be useful - closed issue https://azure.microsoft.com/en-us/updates/public-preview-ephemeral-os-disks-supports-hostbased-encryption-using-customer-managed-key/ is referenced above, which just links back to this issue, so it's hard to know if this issue is in the backlog?

loczek09 commented 2 years ago

Hi, There is private_link_access block within network_rules block where you can define resource id that needs access to storage account. https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/storage_account#network_rules

mahalel commented 1 year ago

I can confirm @loczek09's solution works:

resource "azurerm_storage_account_network_rules" "this" {

  storage_account_id = azurerm_storage_account.this.id

  default_action             = "Deny"
  ip_rules                   = []
  virtual_network_subnet_ids = []
  bypass                     = ["AzureServices"]
  private_link_access {
    endpoint_resource_id       = module.synapse_workspace[0].id
  }
}

Results in the following:

kimdogbe commented 1 year ago

This a good solution for a single resource with an id. I think this is still an issue when trying to set the "Instance name" value to "All in current subscription" or "All in current tenant" like so:

Anyone know if there is a way to setup in terraform to get the results above?

mikew3432 commented 1 year ago

This a good solution for a single resource with an id. I think this is still an issue when trying to set the "Instance name" value to "All in current subscription" or "All in current tenant" like so: [image] Anyone know if there is a way to setup in terraform to get the results above?

@kimdogbe I had a play around with configuring this on a resource and then looking at the Resource Explorer. For all Synapse Workspaces in current resource group the endpoint resource id might be something like "/providers/Microsoft.Synapse/workspaces/*"

ikhudur commented 8 months ago

Hello,

It has been almost 3 years since this has been raised. Any updated on if/when this will be introduced?

I want to allow a Fabric workspace to access a storage account as explained in [1] and [2], but currently (as I know) it is not possible to create a resource instance rule for resources outside of Azure?

[1] https://blog.fabric.microsoft.com/sv-se/blog/introducing-trusted-workspace-access-for-onelake-shortcuts?ft=All [2] https://learn.microsoft.com/en-us/fabric/security/security-trusted-workspace-access

JoshWeepie commented 7 months ago

Yup, just ran into this as well, I wanted to add Data Factory, but with the 'All in current subscription' option.

Tanchwa commented 5 months ago

Does anyone know if the workaround currently supports Azure VM managed identities as an argument? We have multiple SHIRs for different ADF workloads, and want to make sure only one of those instances can reach a particular storage account. Both SHIRs currently reside in the same subnet.

CaishenNefri commented 1 month ago

I think this is already implemented via private_link_access https://github.com/hashicorp/terraform-provider-azurerm/issues/14816#issuecomment-1006364592

hashicorp / terraform-provider-azurerm