зеркало из https://github.com/github/docs.git
Add documentation for Actions: Private networking with Azure VNET (#39075)
Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Kevin Heis <heiskr@users.noreply.github.com> Co-authored-by: Siara <108543037+SiaraMist@users.noreply.github.com>
This commit is contained in:
Joe Clark
GitHub
Родитель
70a0476f72
Коммит
1ffee22b65
Двоичные данные
assets/images/enterprise/settings/private-networking-settings-add-network.png
Normal file
Двоичные данные
assets/images/enterprise/settings/private-networking-settings-add-network.png
Normal file
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 74 KiB |
|
|
@ -11,7 +11,7 @@ topics:
|
|||
- Actions
|
||||
- Developer
|
||||
---
|
||||
|
||||
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
## About {% data variables.product.prodname_dotcom %}-hosted runners networking
|
||||
|
|
@ -22,7 +22,7 @@ By default, {% data variables.product.prodname_dotcom %}-hosted runners have acc
|
|||
|
||||
{% ifversion fpt or ghec or ghes %}
|
||||
|
||||
### Using an API Gateway with OIDC
|
||||
## Using an API Gateway with OIDC
|
||||
|
||||
With {% data variables.product.prodname_actions %}, you can use OpenID Connect (OIDC) tokens to authenticate your workflow outside of {% data variables.product.prodname_actions %}. For example, you could run an API Gateway on the edge of your private network that authenticates incoming requests with the OIDC token and then makes API requests on behalf of your workflow in your private network.
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ But there are various advantages too:
|
|||
For more information, see [a reference implementation of an API Gateway](https://github.com/github/actions-oidc-gateway-example) (note that this requires customization for your use case and is not ready-to-run as-is), and "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)".
|
||||
{% endif %}
|
||||
|
||||
### Using WireGuard to create a network overlay
|
||||
## Using WireGuard to create a network overlay
|
||||
|
||||
If you don't want to maintain separate infrastructure for an API Gateway, you can create an overlay network between your runner and a service in your private network, by running WireGuard in both places.
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ There are various disadvantages to this approach:
|
|||
|
||||
There are some advantages too, as you can run WireGuard on an existing server so you don't have to maintain separate infrastructure, and it's well supported on {% data variables.product.prodname_dotcom %}-hosted runners.
|
||||
|
||||
### Example: Configuring WireGuard
|
||||
## Example: Configuring WireGuard
|
||||
|
||||
This example workflow configures WireGuard to connect to a private service.
|
||||
|
||||
|
|
@ -103,3 +103,289 @@ Its disadvantages are similar to WireGuard: The connection is one-to-one, so you
|
|||
However, there are some advantages over WireGuard: NAT traversal is built-in, so you don't need to expose a port to the public internet. It is by far the quickest of these options to get up and running, since Tailscale provides an {% data variables.product.prodname_actions %} workflow with a single step to connect to the overlay network.
|
||||
|
||||
For more information, see the [Tailscale GitHub Action](https://github.com/tailscale/github-action), as well as "[AUTOTITLE](/actions/security-guides/encrypted-secrets)" for how to securely store keys.
|
||||
|
||||
{% ifversion actions-private-networking-azure-vnet %}
|
||||
|
||||
## Using an Azure Virtual Network (VNET)
|
||||
|
||||
{% note %}
|
||||
|
||||
**Notes:**
|
||||
|
||||
- {% data reusables.actions.github-hosted-larger-runners-azure-vnet-beta %}
|
||||
- Only larger runners are supported with Azure VNET. For more information about larger runners, see "[AUTOTITLE](/enterprise-cloud@latest/actions/using-github-hosted-runners/about-larger-runners)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.actions.azure-vnet-injected-runners-intro %}
|
||||
|
||||
Using {% data variables.product.company_short %}-hosted runners within Azure VNET allows you to perform the following actions.
|
||||
- Privately connect a runner to resources inside an Azure network without opening internet ports, including on-premises resources accessible from the Azure network.
|
||||
- Restrict what {% data variables.product.company_short %}-hosted runners can access or connect to with full control over outbound network policies.
|
||||
- Monitor network logs for {% data variables.product.company_short %}-hosted runners and view all connectivity to and from a runner.
|
||||
|
||||
With this functionality, the {% data variables.product.company_short %}-hosted runner's network interface card (NIC) is deployed into your Azure VNET. As a result, all communication is kept private within the network boundaries, and networking policies applied to the VNET also apply to the runner.
|
||||
|
||||
For example, if your VNET is configured with an Azure ExpressRoute to provide access to on-premises resources (artifactory) or connected to a VPN tunnel to provide access to other cloud-based resources, those access policies also apply to your runners.
|
||||
|
||||
Similarly, if your VNET is configured with a Network Security Group (NSG) for controlled outbound access, those outbound rules also apply to your runners.
|
||||
|
||||
If you have enabled any network logs monitoring for your VNET, you can also monitor inbound/outbound network traffic for your runners.
|
||||
|
||||
To use {% data variables.product.company_short %}-hosted runners with Azure VNET, you will need to complete the following actions.
|
||||
|
||||
- Create an Azure VNET or use an existing one
|
||||
- Configure your Azure subscription
|
||||
- Grant {% data variables.product.prodname_actions %} access
|
||||
- Configure a private network in your {% data variables.product.company_short %} account settings
|
||||
- Enable the {% data variables.product.prodname_actions %} service
|
||||
- Create a VNET-injected runner group
|
||||
- Give repository access to the VNET-injected runner group at the organization level
|
||||
- Add a {% data variables.product.company_short %}-hosted runner to the VNET-injected runner group
|
||||
|
||||
### Configuring your Azure subscription
|
||||
|
||||
Before configuring {% data variables.product.prodname_actions %} for VNET-injection, you will need to register the the resource provider in Azure and delegate a subnet where network interfaces (NICs) will be allocated.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** To configure {% data variables.product.prodname_actions %} for VNET-injection, you must use an Azure account with the Subscription Contributor role and the Network Contributor role. These roles enable you to register the 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.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
|
||||
### Granting {% data variables.product.prodname_actions %} access
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Azure Firewall or other Azure integrated security systems like ZScaler must not conflict with the NSG rules.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
**For Layer7/DNS/firewall filtering:**
|
||||
|
||||
To grant {% data variables.product.prodname_actions %} access, you can use {% data variables.product.company_short %}'s self-hosted runner URLs. For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#communication-between-self-hosted-runners-and-github)."
|
||||
|
||||
**For Layer 3/IP Layer filtering:**
|
||||
|
||||
1. If no outbound internet traffic is allowed in your subnet, you must give {% data variables.product.prodname_actions %} access to specific IP ranges to allow communication from the virtual machine to the {% data variables.product.prodname_actions %} service and Azure dependency service. Save the following `.bicep` file. You will use this in the next step.
|
||||
|
||||
```yaml copy
|
||||
@description('NSG for outbound rules')
|
||||
param location string
|
||||
param nsgName string = 'actions_NSG'
|
||||
|
||||
resource actions_NSG 'Microsoft.Network/networkSecurityGroups@2017-06-01' = {
|
||||
name: nsgName
|
||||
location: location
|
||||
properties: {
|
||||
securityRules: [
|
||||
{
|
||||
name: 'DenyInternetOutBoundOverwrite'
|
||||
properties: {
|
||||
protocol: '*'
|
||||
sourcePortRange: '*'
|
||||
destinationPortRange: '*'
|
||||
sourceAddressPrefix: '*'
|
||||
destinationAddressPrefix: 'Internet'
|
||||
access: 'Deny'
|
||||
priority: 400
|
||||
direction: 'Outbound'
|
||||
}
|
||||
}
|
||||
{
|
||||
name: 'AllowVnetOutBoundOverwrite'
|
||||
properties: {
|
||||
protocol: 'TCP'
|
||||
sourcePortRange: '*'
|
||||
destinationPortRange: '443'
|
||||
sourceAddressPrefix: '*'
|
||||
destinationAddressPrefix: 'VirtualNetwork'
|
||||
access: 'Allow'
|
||||
priority: 200
|
||||
direction: 'Outbound'
|
||||
destinationAddressPrefixes: []
|
||||
}
|
||||
}
|
||||
{
|
||||
name: 'AllowAzureCloudOutBound'
|
||||
properties: {
|
||||
protocol: 'TCP'
|
||||
sourcePortRange: '*'
|
||||
destinationPortRange: '443'
|
||||
sourceAddressPrefix: '*'
|
||||
destinationAddressPrefix: 'AzureCloud'
|
||||
access: 'Allow'
|
||||
priority: 210
|
||||
direction: 'Outbound'
|
||||
destinationAddressPrefixes: []
|
||||
}
|
||||
}
|
||||
{
|
||||
name: 'AllowInternetOutBoundGitHub'
|
||||
properties: {
|
||||
protocol: 'TCP'
|
||||
sourcePortRange: '*'
|
||||
destinationPortRange: '443'
|
||||
sourceAddressPrefix: '*'
|
||||
access: 'Allow'
|
||||
priority: 220
|
||||
direction: 'Outbound'
|
||||
destinationAddressPrefixes: [
|
||||
'140.82.112.0/20'
|
||||
'142.250.0.0/15'
|
||||
'143.55.64.0/20'
|
||||
'192.30.252.0/22'
|
||||
'185.199.108.0/22'
|
||||
]
|
||||
}
|
||||
}
|
||||
{
|
||||
name: 'AllowInternetOutBoundMicrosoft'
|
||||
properties: {
|
||||
protocol: 'TCP'
|
||||
sourcePortRange: '*'
|
||||
destinationPortRange: '443'
|
||||
sourceAddressPrefix: '*'
|
||||
access: 'Allow'
|
||||
priority: 230
|
||||
direction: 'Outbound'
|
||||
destinationAddressPrefixes: [
|
||||
'13.64.0.0/11'
|
||||
'13.96.0.0/13'
|
||||
'13.104.0.0/14'
|
||||
'20.33.0.0/16'
|
||||
'20.34.0.0/15'
|
||||
'20.36.0.0/14'
|
||||
'20.40.0.0/13'
|
||||
'20.48.0.0/12'
|
||||
'20.64.0.0/10'
|
||||
'20.128.0.0/16'
|
||||
'52.224.0.0/11'
|
||||
'204.79.197.200'
|
||||
]
|
||||
}
|
||||
}
|
||||
{
|
||||
name: 'AllowInternetOutBoundCannonical'
|
||||
properties: {
|
||||
protocol: 'TCP'
|
||||
sourcePortRange: '*'
|
||||
destinationPortRange: '443'
|
||||
sourceAddressPrefix: '*'
|
||||
destinationAddressPrefix: '185.125.188.0/22'
|
||||
access: 'Allow'
|
||||
priority: 240
|
||||
direction: 'Outbound'
|
||||
destinationAddressPrefixes: []
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
1. To deploy the Network Security Group (NSG) with the required rules and configure the subnet to use it, run the following command.
|
||||
|
||||
```shell copy
|
||||
az deployment group create --resource-group RESOURCE_GROUP_NAME --template-file ./actions-nsg-deployment.bicep --parameters location=AZURE_LOCATION nsgName=NSG_NAME
|
||||
```
|
||||
|
||||
### Registering the resource provider
|
||||
|
||||
1. Follow the [Register resource provider](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/resource-providers-and-types#register-resource-provider-1) procedures in the Azure documentation.
|
||||
1. When selecting a subscription, select the subscription that will contain your VNET.
|
||||
1. When searching for a resource provider, search for "GitHub.Network" in the "Filter by name" text field.
|
||||
|
||||
### Delegating the subnet
|
||||
|
||||
1. Delegate the subnet to the `GitHub.Network/NetworkSettings` resource type. For more information, see [Add or remove a subnet delegation](https://learn.microsoft.com/en-us/azure/virtual-network/manage-subnet-delegation?tabs=manage-subnet-delegation-portal) in the Azure documentation.
|
||||
|
||||
### Creating a network settings resource
|
||||
|
||||
1. Create a network settings resource in Azure.
|
||||
|
||||
1. Save the following template in a file named `networkSettingsPayload.json`.
|
||||
|
||||
```json copy
|
||||
{
|
||||
"location": "AZURE_REGION",
|
||||
"properties": {
|
||||
"subnetId": "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME/ providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME",
|
||||
"organizationId": "GITHUB_ORGANIZATION_ID"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
1. Use the following command in the Azure CLI to create a network settings resource in Azure. For more information, see [Azure Command-Line Interface (CLI) documentation](https://learn.microsoft.com/en-us/cli/azure/) in the Azure documentation.
|
||||
|
||||
```shell copy
|
||||
az resource create -g RESOURCE_GROUP_NAME -n RESOURCE_NAME --resource-type GitHub. Network/networkSettings --properties @networkSettingsPayload.json
|
||||
```
|
||||
|
||||
The command will return the full payload for the created resource. The following is an example of a portion of the full payload. Note the `GitHubId` hash value. You will use this value to configure your {% data variables.product.company_short %} settings.
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME/providers/ GitHub.Network/networkSettings/RESOURCE_NAME",
|
||||
"name": "RESOURCE_NAME",
|
||||
"type": "github.network/networksettings",
|
||||
"tags": {
|
||||
"GitHubId": "00000000000000000000000000000000000"
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
### Configuring VNET settings with {% data variables.product.company_short %}
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
1. In the left sidebar, click **Networking**.
|
||||
1. Optionally, use the "Find private network" search box to find an existing private network.
|
||||
1. To the right of the "Find private network" search box, click **Add private network** to make a new private network.
|
||||
|
||||
1. Alternatively, if you have not registered any private networks for your enterprise, click **Set up private network**.
|
||||
1. In the "Network settings resource ID" text field, enter the `GitHubId` you obtained while configuring your Azure subscription for VNET-injection.
|
||||
1. Under "Set a custom name," create a name for your private network.
|
||||
1. Click **Add private network**.
|
||||
|
||||
### Enabling the {% data variables.product.prodname_actions %} service
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.settings-tab %}
|
||||
1. In the left sidebar, click **Networking**.
|
||||
1. Under "Services allowed," click **{% data variables.product.prodname_actions %}**
|
||||
1. Click **Save changes**.
|
||||
|
||||
### Creating a VNET-injected runner group
|
||||
|
||||
1. Create a new runner group for your enterprise. For more information about how to create a runner group, see "[AUTOTITLE](/enterprise-cloud@latest/actions/using-github-hosted-runners/controlling-access-to-larger-runners#creating-a-runner-group-for-an-enterprise)."
|
||||
{% data reusables.actions.workflows.runner-groups-enterprise-organization-access %}
|
||||
1. While configuring your runner group, under "Private network access," use the dropdown menu to select the private network you created for VNET-injection.
|
||||
1. Click **Create group** to create the group and apply the policy.
|
||||
|
||||
### Configuring repository access at the organization level
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** For the VNET-injected runner to be accessible by required repositories within your enterprise-owned organizations, those repositories must have access to that VNET-inject runner group at the organization level.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
1. Give repository access to the VNET-injected runner group at the organization level. For more information, see "[AUTOTITLE](/actions/using-github-hosted-runners/controlling-access-to-larger-runners#changing-which-repositories-can-access-a-runner-group)."
|
||||
|
||||
### Adding the {% data variables.product.company_short %}-hosted runner to the runner group
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** When adding your {% data variables.product.company_short %}-hosted runner runner to a runner group, select the VNET-injected runner group you created in the previous procedures. For more information about runner groups, see "[AUTOTITLE](/enterprise-cloud@latest/actions/using-github-hosted-runners/managing-larger-runners#adding-a-larger-runner-to-an-enterprise)."
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.enterprise-accounts.access-enterprise %}
|
||||
{% data reusables.enterprise-accounts.policies-tab %}
|
||||
{% data reusables.enterprise-accounts.actions-tab %}
|
||||
{% data reusables.enterprise-accounts.actions-runners-tab %}
|
||||
{% data reusables.actions.add-hosted-runner %}
|
||||
{% data reusables.actions.org-access-to-github-hosted-runners %}
|
||||
|
||||
{% endif %}
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ versions:
|
|||
feature: actions-hosted-runners
|
||||
type: tutorial
|
||||
---
|
||||
|
||||
|
||||
{% data reusables.actions.enterprise-github-hosted-runners %}
|
||||
|
||||
## About runner groups
|
||||
|
|
@ -79,6 +79,16 @@ For runner groups in an organization, you can change what repositories in the or
|
|||
- [Changing which workflows can access an organization runner group](#changing-which-workflows-can-access-an-organization-runner-group)
|
||||
- [Changing which workflows can access an enterprise runner group](#changing-which-workflows-can-access-an-enterprise-runner-group)
|
||||
|
||||
{% ifversion actions-private-networking-azure-vnet %}
|
||||
|
||||
## Configuring private network access for larger runners
|
||||
|
||||
{% data reusables.actions.azure-vnet-injected-runners-intro %}
|
||||
|
||||
If you have configured your enterprise to connect to an Azure VNET, you can give runner groups access to the virtual network. For more information, see "[AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network#using-an-azure-virtual-network-vnet)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Changing which workflows can access an organization runner group
|
||||
|
||||
{% data reusables.actions.runner-groups-org-navigation %}
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Enterprise owners can add {% data variables.actions.hosted_runner %}s to an ente
|
|||
{% data reusables.enterprise-accounts.actions-tab %}
|
||||
{% data reusables.enterprise-accounts.actions-runners-tab %}
|
||||
{% data reusables.actions.add-hosted-runner %}
|
||||
1. To allow organizations to access your {% data variables.actions.hosted_runner %}s, specify the list of organizations that can use it. For more information, see "[Managing access to your runners](#managing-access-to-your-runners)."
|
||||
{% data reusables.actions.org-access-to-github-hosted-runners %}
|
||||
|
||||
{% endif %}
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ You can add a {% data variables.actions.hosted_runner %} to an organization, whe
|
|||
|
||||
## Allowing repositories to access {% data variables.actions.hosted_runner %}s
|
||||
|
||||
Repositories are granted access to {% data variables.actions.hosted_runner %}s through runner groups. Enterprise administrators can choose which organizations are granted access to enterprise-level runner groups, and organization administrators control repository-level access to all {% data variables.actions.hosted_runner %}s. Organization administrators can use and configure enterprise-level runner groups for the repositories in their organization, or they can create organization-level runner groups to control access.
|
||||
Repositories are granted access to {% data variables.actions.hosted_runner %}s through runner groups. Enterprise administrators can choose which organizations are granted access to enterprise-level runner groups, and organization administrators control repository-level access to all {% data variables.actions.hosted_runner %}s. Organization administrators can use and configure enterprise-level runner groups for the repositories in their organization, or they can create organization-level runner groups to control access.
|
||||
|
||||
- **For enterprise-level runner groups**: {% data reusables.actions.about-enterprise-level-runner-groups %}
|
||||
- **For organization-level runner groups**: {% data reusables.actions.about-organization-level-runner-groups %}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,4 @@
|
|||
# Reference: #9954
|
||||
# Documentation for larger-hosted runners with Azure Vnet injection public beta
|
||||
versions:
|
||||
ghec: '*'
|
||||
|
|
@ -0,0 +1 @@
|
|||
If you are using Azure and {% data variables.product.prodname_ghe_cloud %}, you can create {% data variables.product.company_short %}-hosted runners in your Azure Virtual Network(s) (VNET). This enables you to take advantage of {% data variables.product.company_short %}-managed infrastructure for your CI/CD while providing you with full control over the networking policies of your runners. For more information about Azure VNET, see [What is Azure Virtual Network?](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview) in the Azure documentation.
|
||||
|
|
@ -14,6 +14,6 @@ If no group is specified during the registration process, runners are automatica
|
|||
When creating a group, you must choose a policy that defines which organizations have access to the runner group.
|
||||
|
||||
{% data reusables.actions.runner-groups-add-to-enterprise-first-steps %}
|
||||
1. To choose a policy for organization access, select the **Organization access** dropdown menu and click a policy. You can configure a runner group to be accessible to a specific list of organizations, or all organizations in the enterprise.{% ifversion ghes %} By default, only private repositories can access runners in a runner group, but you can override this.{% endif %}
|
||||
{% data reusables.actions.workflows.runner-groups-enterprise-organization-access %}
|
||||
{% data reusables.actions.runner-group-assign-policy-workflow %}
|
||||
1. Click **Save group** to create the group and apply the policy.
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
Using {% data variables.product.company_short %}-hosted larger runners with an Azure Virtual Network (VNET) is in beta and subject to change.
|
||||
|
|
@ -0,0 +1 @@
|
|||
1. To allow organizations to access your {% data variables.actions.hosted_runner %}s, specify the list of organizations that can use it. For more information, see "[Managing access to your runners](#managing-access-to-your-runners)."
|
||||
|
|
@ -0,0 +1 @@
|
|||
1. To choose a policy for organization access, select the **Organization access** dropdown menu and click a policy. You can configure a runner group to be accessible to a specific list of organizations, or all organizations in the enterprise.{% ifversion ghes %} By default, only private repositories can access runners in a runner group, but you can override this.{% endif %}
|
||||
Загрузка…
Ссылка в новой задаче