You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: data/reusables/actions/azure-vnet-procedures-prereqs.md
+34-7Lines changed: 34 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,24 +2,51 @@ You will use a script to automate configuring your Azure resources.
2
2
3
3
### Prerequisites
4
4
5
-
* Use an Azure account with the Subscription Contributor role and the Network Contributor role. These roles enable you to register the `GitHub.Network` resource provider and delegate the subnet. For more information, see [Azure built-in roles](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)on Microsoft Learn.
5
+
* Use an Azure account with the Subscription Contributor role and the Network Contributor role. These roles enable you to register the `GitHub.Network` resource provider and delegate the subnet. For more information, see [Azure built-in roles](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)in the Azure documentation.
6
6
7
7
* To correctly associate the subnets with the right user, Azure `NetworkSettings` resources must be created in the same subscriptions where virtual networks are created.
8
8
9
9
* To ensure resource availability/data residency, resources must be created in the same Azure region.
10
10
11
-
* Outbound network traffic from the subnet **must not** be subject to TLS interception as our Virtual Machines will not be configured to trust intermediate certificates that your network uses to perform TLS interception. For more details, see [Certificates used by Azure Firewall Premium](https://learn.microsoft.com/en-us/azure/firewall/premium-certificates#certificates-used-by-azure-firewall-premium) in the Microsoft documentation.
12
-
11
+
* Outbound network traffic from the subnet **must not** be subject to TLS interception as our Virtual Machines will not be configured to trust intermediate certificates that your network uses to perform the interception.
12
+
13
13
If you need to use TLS interception, you can install intermediate certificates via a custom image. See [AUTOTITLE](/actions/how-tos/manage-runners/larger-runners/use-custom-images).
14
14
15
-
*Save the following `.bicep` file. Name the file `actions-nsg-deployment.bicep`.
15
+
*We recommend some level of network traffic control over your Azure VNET and to use DNS/domain-based controls. The previously recommended IP addresses will be closed on or after July 1, 2026.
16
16
17
-
The `.bicep` file we provide contains the minimal set of rules to use {% data variables.product.company_short %}-hosted runners with Azure VNET. You may need to add rules for your specific use case.
18
17
19
-
If you use {% data variables.enterprise.data_residency %}, in the `AllowOutBoundGitHub` section, you must also include the ingress IP ranges for {% data variables.enterprise.data_residency_site %}. See [AUTOTITLE](/admin/data-residency/network-details-for-ghecom#ranges-for-ingress-traffic).
18
+
#### DNS/domain control (recommended)
19
+
20
+
If you control the outbound access of your {% data variables.product.company_short %}-hosted runners with Azure VNET using DNS or domains, you allow-list a set of domains for {% data variables.product.prodname_actions %} functionality. This is the recommended approach because the domains are published on the {% data variables.product.github %} meta endpoint, which {% data variables.product.github %} keeps up to date as network requirements change. For a breakdown of the domains by function, see the "Communication" section in [AUTOTITLE](/actions/reference/runners/self-hosted-runners#communication).
21
+
22
+
You can find the domains to allow-list on the {% data variables.product.github %} meta endpoint at [https://api.github.com/meta](https://api.github.com/meta). For more information on the meta endpoint, see [AUTOTITLE](/rest/meta/meta#get-github-meta-information).
23
+
24
+
There are three sections on the meta endpoint you can choose to allow-list based on:
25
+
26
+
*`domains.actions_inbound.full_domains`: An extremely specific list of exact domains needed for {% data variables.product.prodname_actions %} functionality, with no wildcarded domains.
27
+
*`domains.actions`: A middle-ground domain list, with some {% data variables.product.github %}-owned domains wildcarded, but other domains listed specifically.
28
+
*`domains.actions_inbound.wildcard_domains`: A list with primarily wildcarded domains. This will be the most stable from a domain change perspective.
29
+
30
+
> [!WARNING]
31
+
> Required domains on the meta endpoint are subject to change. {% data variables.product.github %} ensures a domain is on the meta endpoint for at least one week before it goes into use. The meta endpoint does not provide a "last updated" date, so you cannot rely on a timestamp to detect changes.
32
+
>
33
+
> If you plan to use the more specific domain lists, you must check for new domains on a weekly basis and update your network control systems appropriately, or your {% data variables.product.prodname_actions %} jobs may experience unintended issues. Because new domains are published at least a week before they are required, a weekly check leaves enough lead time to apply changes before they take effect. The middle-ground list that allows for some {% data variables.product.github %} domain wildcards will be much more stable, and the full wildcard list should see very little change.
34
+
35
+
You can use any technology of your choice for doing DNS/domain control on your Azure VNET. This guidance is for the minimal required domains for basic functionality; you may need to add more domains to your allow-list system for additional scenarios.
36
+
37
+
#### IP address controls
38
+
39
+
> [!WARNING]
40
+
> The IP-based `.bicep` template below is {% data variables.release-phases.closing_down %} and will be removed on or after July 1, 2026. It remains available to support migration to DNS/domain-based control (see "DNS/domain control" above). Customers who hard-code or template this IP list (for example, in Terraform) are at risk of broken traffic when the underlying Azure IP ranges change, because this static list is not kept up to date. Migrate to the meta endpoint domains before this template is removed.
20
41
21
42
> [!NOTE]
22
-
> As an alternative to using the following file, to allow {% data variables.product.prodname_actions %} to communicate with the runners, you can allow the same firewall domains that are required for communication between self-hosted runners and {% data variables.product.github %}. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/communicating-with-self-hosted-runners). To determine the appropriate subnet IP address range, we recommend adding a 30% buffer to the maximum job concurrency you anticipate. For instance, if your network configuration's runners are set to a maximum job concurrency of 300, it's recommended to utilize a subnet IP address range that can accommodate at least 390 runners. This buffer helps ensure that your network can handle unexpected increases in VM needs to meet job concurrency without running out of IP addresses.
43
+
> To determine the appropriate subnet IP address range, we recommend adding a 30% buffer to the maximum job concurrency you anticipate. For instance, if your network configuration's runners are set to a maximum job concurrency of 300, it's recommended to utilize a subnet IP address range that can accommodate at least 390 runners. This buffer helps ensure that your network can handle unexpected increases in VM needs to meet job concurrency without running out of IP addresses.
44
+
45
+
If you control outbound access using IP addresses during the transition period, save the following `.bicep` file. Name the file `actions-nsg-deployment.bicep`.
46
+
47
+
The `.bicep` file we provide contains the minimal set of rules to use {% data variables.product.company_short %}-hosted runners with Azure VNET. You may need to add rules for your specific use case.
48
+
49
+
If you use {% data variables.enterprise.data_residency %}, in the `AllowOutBoundGitHub` section, you must also include the ingress IP ranges for {% data variables.enterprise.data_residency_site %}. See [AUTOTITLE](/admin/data-residency/network-details-for-ghecom#ranges-for-ingress-traffic).
0 commit comments