Data provider address "Internet" does not work

[JimMadge]

✅ Checklist

• I have searched open and closed issues for duplicates.
• This is a problem observed when deploying a Data Safe Haven.
• I can reproduce this with the latest version.
• I have read through the documentation.
• This isn't an open-ended question (open a discussion if it is).

💻 System information

• Data Safe Haven version: develop (24fbad9)

📦 Packages

List of packages

acme==2.10.0
annotated-types==0.7.0
appdirs==1.4.4
Arpeggio==2.0.2
attrs==24.2.0
azure-common==1.1.28
azure-core==1.32.0
azure-identity==1.19.0
azure-keyvault-certificates==4.9.0
azure-keyvault-keys==4.10.0
azure-keyvault-secrets==4.9.0
azure-mgmt-compute==33.0.0
azure-mgmt-containerinstance==10.1.0
azure-mgmt-core==1.5.0
azure-mgmt-dns==8.2.0
azure-mgmt-keyvault==10.3.1
azure-mgmt-msi==7.0.0
azure-mgmt-rdbms==10.1.0
azure-mgmt-resource==23.2.0
azure-mgmt-storage==21.2.1
azure-storage-blob==12.23.1
azure-storage-file-datalake==12.17.0
azure-storage-file-share==12.19.0
certifi==2024.8.30
cffi==1.17.1
charset-normalizer==3.4.0
chevron==0.14.0
click==8.1.7
cryptography==43.0.3
-e git+ssh://[email protected]/alan-turing-institute/data-safe-haven.git@d51640b51032b49d35abd1e5f195c01d8e5a534a#egg=data_safe_haven
debugpy==1.8.8
dill==0.3.9
dnspython==2.7.0
fqdn==1.5.1
grpcio==1.66.2
idna==3.10
isodate==0.7.2
josepy==1.14.0
markdown-it-py==3.0.0
mdurl==0.1.2
msal==1.31.0
msal-extensions==1.2.0
msrest==0.7.1
oauthlib==3.2.2
parver==0.5
portalocker==2.10.1
protobuf==4.25.5
psycopg==3.1.19
psycopg-binary==3.1.19
pulumi==3.138.0
pulumi_azure_native==2.71.0
pulumi_azuread==6.0.1
pulumi_random==4.16.7
pycparser==2.22
pydantic==2.9.2
pydantic_core==2.23.4
Pygments==2.18.0
PyJWT==2.9.0
pyOpenSSL==24.2.1
pyRFC3339==2.0.1
pytz==2024.2
PyYAML==6.0.2
requests==2.32.3
requests-oauthlib==2.0.0
rich==13.9.4
semver==2.13.0
setuptools==75.2.0
shellingham==1.5.4
simple_acme_dns==3.2.0
six==1.16.0
typer==0.13.0
typing_extensions==4.12.2
urllib3==2.2.3
validators==0.34.0
websocket-client==1.8.0

🚫 Describe the problem

Default action Allow is not valid for NFS enabled storage accounts.
I'm a bit surprised by this because I'm sure I tested this for #2247. Perhaps I was changing this after deployment?

We either need to find a way to make this work, which might be,

• Allow a large CIDR range?
• Find why Allow is not valid anymore?

Or to remove this feature.

🌳 Log messages

Relevant log messages

  azure-native:storage:StorageAccount
(sre_data_storage_account_data_private_sensitive):
    error: PUT
https://management.azure.com/subscriptions/3f1a8e26-eae2-4539-952a-0a6184ec248a/resourceGroups/
shm-daimyo-sre-hojo-rg/providers/Microsoft.Storage/storageAccounts/shdaisrehojsensitivedata
    --------------------------------------------------------------------------------
    RESPONSE 400: 400 Bad Request
    ERROR CODE: NetworkAclsDefaultActionMisconfigured
    --------------------------------------------------------------------------------
    {
      "error": {
        "code": "NetworkAclsDefaultActionMisconfigured",
        "message": "NetworkAcls default action must be set to Deny for NFS enabled account."
      }
    }
    --------------------------------------------------------------------------------

♻️ To reproduce

• Deploy an SRE with data_provider_ip_addresses: Internet

[craddm]

Pulumi allowed me to change this on a storage account for an SRE that was already deployed - I changed the config to allow the internet, and it updated the setting on the storage account without issue.

In the portal, if you look at the account in question, you'll see the following warning on the networking tab -

NFS v3 is enabled for this storage account. Setting network access to 'all networks' will cause network access using this protocol to fail

However, I can still generate a token for it and access it through Azure storage explorer from any IP address, and can still also access it from the workspace...

The link that the above error message is attached to also says very little about this problem - the only relevant thing I see is where it says Traffic must originate from a VNet.

It looks to me kind of like this shouldn't work, and is thus prevented when creating the storage account, but actually does work.

[JimMadge]

Ah, so that makes sense. When I tested this I must have modified an already deployed storage account rather than deploying a new one. (I did think I tested on a fresh deploy though 🤷)

I'm not sure if there is anything we can do. Feels like the Azure API is blocking this?

[craddm]

I'm sure I saw people using Terraform have the same sorts of issues when I was googling around, and that it even warns you in the portal about it definitely suggest it's blocked by the API. So yes, don't think there's anything we can do about it really :(

[JimMadge]

Maybe for now, the thing is to add this as a known issue.