Closed fdalrymple-hp closed 1 year ago
@fdalrymple-hp Your virtual network must be under the same subscription ID as the resource you create. Thanks!
Will there be no intention to support a vNet not in the same subscription as the Private DNS Zone in the future? I suspect that our configuration is very typical of a normal enterprise with hub & spoke architecture and in this case for our main private DNS zone the only vNet that's in the same subscription is the core/transit vNet. All of the other vNets reside in more app-specific subscription outside of the core-connectivity subscription.
Additional data points:
profile
for each vNet I wish to add a link for, however that doesn't align with our (or any good) security practice.@fdalrymple-hp Currently we don't support vnet_id under different subscriptions, but we are considering adding this feature. Thanks!
I know this is an older thread but does support exist for same subscription ID but with different resource groups. Say Private DNS zone is in RG-DNS where the vnet being linked to the zone is in RG-NETWORK, is that supported?
@michael-andretta Do you want create a virtual network link like this?
- name: Create a Private DNS zone
azure_rm_privatednszone:
resource_group: "{{ resource_group }}"
name: "{{ domain_name }}.com"
state: present
- name: Create a virtual network
azure_rm_virtualnetwork:
name: "vnet{{ rpfx }}"
resource_group: "{{ resource_group_secondary }}"
address_prefixes_cidr:
- 10.1.0.0/16
- 172.100.0.0/16
dns_servers:
- 127.0.0.1
- 127.0.0.2
register: vnet_output
- name: Create a subnet
azure_rm_subnet:
name: "subnet{{ rpfx }}"
virtual_network_name: "vnet{{ rpfx }}"
resource_group: "{{ resource_group_secondary }}"
address_prefix_cidr: 10.1.0.0/24
- name: Create a virtual network link
azure_rm_privatednszonelink:
resource_group: "{{ resource_group }}"
name: "{{ link_name }}"
zone_name: "{{ domain_name }}.com"
virtual_network: "{{ vnet_output.state.id }}"
registration_enabled: true
state: present
I've recently encountered the same issue and after some digging we seem to have tracked down what's seems to be causing it. From the looks if it this has always fallen back on the current subscription context.
Starting in the module where it is parsing the resource id: https://github.com/ansible-collections/azure/blob/ebce7484bff7387ccc627180088008ed39be4a8d/plugins/modules/azure_rm_privatednszonelink.py#L160:~:text=self.virtual_network%20%3D%20format_resource_id,virtual_network%5B%27resource_group%27%5D)
Noting: subscription_id=virtual_network['subscription_id']
Looking further into parse_resource_id: https://github.com/Azure/msrestazure-for-python/blob/8e3def8c9927a349596e575de93df76de7a3a2b6/msrestazure/tools.py#L115:~:text=match%20%3D%20_ARMID_RE.match(rid)
And then taking a look at the regex it's trying to match.
Here it's trying to match on "subscription" and not "subscription_id" which the module expects.
With a quick local test I got this to work by removing "_id" like this:
self.virtual_network = format_resource_id(val=virtual_network['name'], subscription_id=virtual_network['subscription'], namespace='Microsoft.Network', types='virtualNetworks', resource_group=virtual_network['resource_group'])
Currently haven't tested if this break anything else, but deploying a private dns zone link for a virtual network in another subscription works. It also picks up on the existing one on additional runs.
Tasks used to successfully deploy link for virtual network in different subscription after changing the function:
name: SET SUBSCRIPTION CONTEXT
ansible.builtin.shell: az account set --subscription "1111111-2222-3333-4444-555555555555"
name: SETUP LINK TO PRIVATE DNSZONE azure.azcollection.azure_rm_privatednszonelink: resource_group: 'myresourcegroup' name: "dns-private-link" zone_name: "myzone.private.westeurope.azmk8s.io" virtual_network: "/subscriptions/5555555-4444-3333-2222-111111111111/resourceGroups/vnet-resourcegroup/providers/Microsoft.Network/virtualNetworks/my-vnet" state: present
@Fred-sun
Currently we don't support vnet_id under different subscriptions, but we are considering adding this feature. Thanks!
Please consider reopening this issue. I'm running into the same problem and would like support for vnet_id under a different subscription.
I confirm I have the problem with last following version : azure-cli 2.60.0-1~bookworm amd64 Azure CLI
and : /usr/lib/python3/dist-packages/ansible_collections Collection Version
azure.azcollection 1.14.0
/etc/ansible/collections/ansible_collections Collection Version
azure.azcollection 2.3.0
The error message is below. Even is provided virtual_network ID is correct (because it works when I use it to create link from Azure GUI), the error reports the bad virtual_network ID with the local subscription ID instead of remote subscription ID.
"ansible_loop_var": "item",
"changed": false,
"invocation": {
"module_args": {
"ad_user": null,
"adfs_authority_url": null,
"api_profile": "latest",
"append_tags": true,
"auth_source": "auto",
"cert_validation_mode": null,
"client_id": null,
"cloud_environment": "AzureCloud",
"disable_instance_discovery": false,
"log_mode": null,
"log_path": null,
"name": "pp-dataplatform-network-vnet_To_privatelink.azurecr.io",
"password": null,
"profile": "default",
"registration_enabled": false,
"resource_group": "fortigate",
"secret": null,
"state": "present",
"subscription_id": null,
"tags": null,
"tenant": null,
"thumbprint": null,
"virtual_network": "/subscriptions/<remote_subscription_id>/resourceGroups/pp-dataplatform-network-rg/providers/Microsoft.Network/virtualNetworks/pp-dataplatform-network-vnet",
"x509_certificate_path": null,
"zone_name": "privatelink.azurecr.io"
}
},
"item": "Gre-Data-Platform-WestEurope-Preprod-Subscription",
"msg": "Error creating or updating virtual network link pp-dataplatform-network-vnet_To_privatelink.azurecr.io - (BadRequest) Virtual network resource not found for '/subscriptions/<local_subscription_id>/resourceGroups/pp-dataplatform-network-rg/providers/Microsoft.Network/virtualNetworks/pp-dataplatform-network-vnet'\nCode: BadRequest\nMessage: Virtual network resource not found for '/subscriptions/<local_subscription_id>/resourceGroups/pp-dataplatform-network-rg/providers/Microsoft.Network/virtualNetworks/pp-dataplatform-network-vnet'"
}
When I fix azure_rm_privatednszonelink.py as mentioned above, see code below : ... if self.virtual_network: virtual_network = self.parse_resource_to_dict(self.virtual_network) self.virtual_network = format_resource_id(val=virtual_network['name'], subscription_id=virtual_network['subscription'], namespace='Microsoft.Network', types='virtualNetworks', resource_group=virtual_network['resource_group'])
I get following error : ... KeyError: 'subscription' ... meaning that virtual_network dict has no 'subscription' key.
Thank you for help.
SUMMARY
When executing module, supplying entire resource ID to the "virtual_network" parameter, seeing unexpected behavior. Ansible module seems to be reading the information provided to it correctly, however reviewing Azure logs would indicate that the wrong subscription ID is being provided to the call to ARM. The correct name and resource groups are being parsed and used.
ISSUE TYPE
COMPONENT NAME
azure_rm_privatednszonelink
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
username@hostname:~$ cat /etc/debian_version 11.5
STEPS TO REPRODUCE
EXPECTED RESULTS
Expect the vnet link to be created, or if it already exists for it to indicate so and not make any changes.
ACTUAL RESULTS
In the command output I get an error as seen below. Also worth noting that in the verbose output (invocation section) I see the vNet with the correct ID. In the Azure portal activity logs I get
"message": "Virtual network resource not found for '/subscriptions/55555555-4444-3333-2222-111111111111/resourceGroups/rg-networking/providers/Microsoft.Network/virtualNetworks/vnet-1'"
. The subscription_id for the vNet is the one related to the profile being used in the task, NOT the one provided in the virtual_network parameter nor the one showing in the verboseansible-playbook
output. The text error in the output fromansible-playbook
would indicate an operational conflict, however that error message is less deterministic than the indication from Azure Resource Manager that an incorrect resource ID is being used.