diff --git a/assets/images/help/actions/actions-vnet-injected-larger-runners-architecture.png b/assets/images/help/actions/actions-vnet-injected-larger-runners-architecture.png new file mode 100644 index 0000000000..1fbbcda858 Binary files /dev/null and b/assets/images/help/actions/actions-vnet-injected-larger-runners-architecture.png differ diff --git a/content/actions/using-github-hosted-runners/about-github-hosted-runners.md b/content/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners.md similarity index 100% rename from content/actions/using-github-hosted-runners/about-github-hosted-runners.md rename to content/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners.md diff --git a/content/actions/using-github-hosted-runners/customizing-github-hosted-runners.md b/content/actions/using-github-hosted-runners/about-github-hosted-runners/customizing-github-hosted-runners.md similarity index 96% rename from content/actions/using-github-hosted-runners/customizing-github-hosted-runners.md rename to content/actions/using-github-hosted-runners/about-github-hosted-runners/customizing-github-hosted-runners.md index 0f56c3cccb..2afe48aa7b 100644 --- a/content/actions/using-github-hosted-runners/customizing-github-hosted-runners.md +++ b/content/actions/using-github-hosted-runners/about-github-hosted-runners/customizing-github-hosted-runners.md @@ -8,6 +8,8 @@ type: tutorial topics: - Workflows shortTitle: Customize runners +redirect_from: + - /actions/using-github-hosted-runners/customizing-github-hosted-runners --- {% data reusables.actions.enterprise-github-hosted-runners %} diff --git a/content/actions/using-github-hosted-runners/about-github-hosted-runners/index.md b/content/actions/using-github-hosted-runners/about-github-hosted-runners/index.md new file mode 100644 index 0000000000..b1f7cd5035 --- /dev/null +++ b/content/actions/using-github-hosted-runners/about-github-hosted-runners/index.md @@ -0,0 +1,15 @@ +--- +title: Using GitHub-hosted runners +shortTitle: About GitHub-hosted runners +intro: '{% data variables.product.prodname_dotcom %} offers hosted virtual machines to run workflows. The virtual machine contains an environment of tools, packages, and settings available for {% data variables.product.prodname_actions %} to use.' +versions: + fpt: '*' + ghec: '*' + ghes: '*' +children: + - /about-github-hosted-runners + - /monitoring-your-current-jobs + - /customizing-github-hosted-runners +--- + +{% data reusables.actions.enterprise-github-hosted-runners %} diff --git a/content/actions/using-github-hosted-runners/monitoring-your-current-jobs.md b/content/actions/using-github-hosted-runners/about-github-hosted-runners/monitoring-your-current-jobs.md similarity index 95% rename from content/actions/using-github-hosted-runners/monitoring-your-current-jobs.md rename to content/actions/using-github-hosted-runners/about-github-hosted-runners/monitoring-your-current-jobs.md index f8c8213953..5efd6f5f92 100644 --- a/content/actions/using-github-hosted-runners/monitoring-your-current-jobs.md +++ b/content/actions/using-github-hosted-runners/about-github-hosted-runners/monitoring-your-current-jobs.md @@ -4,6 +4,8 @@ shortTitle: Monitor current jobs intro: 'Monitor how {% data variables.product.prodname_dotcom %}-hosted runners are processing jobs in your organization or enterprise, and identify any related constraints.' versions: feature: github-runner-dashboard +redirect_from: + - /actions/using-github-hosted-runners/monitoring-your-current-jobs --- {% data reusables.actions.enterprise-github-hosted-runners %} diff --git a/content/actions/using-github-hosted-runners/about-larger-runners.md b/content/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners.md similarity index 100% rename from content/actions/using-github-hosted-runners/about-larger-runners.md rename to content/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners.md diff --git a/content/actions/using-github-hosted-runners/controlling-access-to-larger-runners.md b/content/actions/using-github-hosted-runners/about-larger-runners/controlling-access-to-larger-runners.md similarity index 98% rename from content/actions/using-github-hosted-runners/controlling-access-to-larger-runners.md rename to content/actions/using-github-hosted-runners/about-larger-runners/controlling-access-to-larger-runners.md index e716d1b68e..e4039d9b51 100644 --- a/content/actions/using-github-hosted-runners/controlling-access-to-larger-runners.md +++ b/content/actions/using-github-hosted-runners/about-larger-runners/controlling-access-to-larger-runners.md @@ -6,6 +6,8 @@ permissions: '{% data reusables.actions.larger-runner-permissions %}' versions: feature: actions-hosted-runners type: tutorial +redirect_from: + - /actions/using-github-hosted-runners/controlling-access-to-larger-runners --- {% data reusables.actions.enterprise-github-hosted-runners %} diff --git a/content/actions/using-github-hosted-runners/about-larger-runners/index.md b/content/actions/using-github-hosted-runners/about-larger-runners/index.md new file mode 100644 index 0000000000..42b11a0b71 --- /dev/null +++ b/content/actions/using-github-hosted-runners/about-larger-runners/index.md @@ -0,0 +1,14 @@ +--- +title: About larger runners +shortTitle: About larger runners +intro: '{% data variables.product.prodname_dotcom %} offers runners with more RAM, CPU, and disk space.' +versions: + feature: actions-hosted-runners +children: + - /about-larger-runners + - /managing-larger-runners + - /controlling-access-to-larger-runners + - /running-jobs-on-larger-runners +--- + +{% data reusables.actions.enterprise-github-hosted-runners %} diff --git a/content/actions/using-github-hosted-runners/managing-larger-runners.md b/content/actions/using-github-hosted-runners/about-larger-runners/managing-larger-runners.md similarity index 99% rename from content/actions/using-github-hosted-runners/managing-larger-runners.md rename to content/actions/using-github-hosted-runners/about-larger-runners/managing-larger-runners.md index 161a2d2cb6..d9b2ca578f 100644 --- a/content/actions/using-github-hosted-runners/managing-larger-runners.md +++ b/content/actions/using-github-hosted-runners/about-larger-runners/managing-larger-runners.md @@ -5,6 +5,8 @@ intro: 'You can configure {% data variables.actions.hosted_runner %}s for your o permissions: '{% data reusables.actions.larger-runner-permissions %}' versions: feature: actions-hosted-runners +redirect_from: + - /actions/using-github-hosted-runners/managing-larger-runners --- {% ifversion ghec %} diff --git a/content/actions/using-github-hosted-runners/running-jobs-on-larger-runners.md b/content/actions/using-github-hosted-runners/about-larger-runners/running-jobs-on-larger-runners.md similarity index 98% rename from content/actions/using-github-hosted-runners/running-jobs-on-larger-runners.md rename to content/actions/using-github-hosted-runners/about-larger-runners/running-jobs-on-larger-runners.md index e3aec04a3e..37a207d894 100644 --- a/content/actions/using-github-hosted-runners/running-jobs-on-larger-runners.md +++ b/content/actions/using-github-hosted-runners/about-larger-runners/running-jobs-on-larger-runners.md @@ -5,6 +5,8 @@ intro: 'You can speed up your workflows by configuring them to run on {% data va permissions: '{% data reusables.actions.larger-runner-permissions %}' versions: feature: actions-hosted-runners +redirect_from: + - /actions/using-github-hosted-runners/running-jobs-on-larger-runners --- ## Running jobs on your runner diff --git a/content/actions/using-github-hosted-runners/connecting-to-a-private-network.md b/content/actions/using-github-hosted-runners/connecting-to-a-private-network.md deleted file mode 100644 index ad225e1597..0000000000 --- a/content/actions/using-github-hosted-runners/connecting-to-a-private-network.md +++ /dev/null @@ -1,415 +0,0 @@ ---- -title: Connecting to a private network -shortTitle: Connect to a private network -intro: 'You can connect {% data variables.product.prodname_dotcom %}-hosted runners to resources on a private network, including package registries, secret managers, and other on-premises services.' -versions: - fpt: '*' - ghes: '*' - ghec: '*' -type: how_to -topics: - - Actions - - Developer ---- - -{% data reusables.actions.enterprise-github-hosted-runners %} - -## About {% data variables.product.prodname_dotcom %}-hosted runners networking - -By default, {% data variables.product.prodname_dotcom %}-hosted runners have access to the public internet. However, you may also want these runners to access resources on your private network, such as a package registry, a secret manager, or other on-premise services. - -{% data variables.product.prodname_dotcom %}-hosted runners are shared across all {% data variables.product.prodname_dotcom %} customers, so you will need a way of connecting your private network to just your runners while they are running your workflows. There are a few different approaches you could take to configure this access, each with different advantages and disadvantages. - -{% ifversion fpt or ghec or ghes %} - -## 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. - -The following diagram gives an overview of this solution's architecture: - -![Diagram of an OIDC gateway architecture, starting with a {% data variables.product.prodname_actions %} runner and ending with a private network's private service.](/assets/images/help/actions/actions-oidc-gateway.png) - -It's important that you authenticate not just that the OIDC token came from {% data variables.product.prodname_actions %}, but that it came specifically from your expected workflows, so that other {% data variables.product.prodname_actions %} users aren't able to access services in your private network. You can use OIDC claims to create these conditions. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#defining-trust-conditions-on-cloud-roles-using-oidc-claims)." - -The main disadvantage of this approach is you have to implement the API gateway to make requests on your behalf, as well as run it on the edge of your network. - -But there are various advantages too: -- You don't need to configure any firewalls, or modify the routing of your private network. -- The API gateway is stateless, and so it scales horizontally to handle high availability and high throughput. - -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 - -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. - -There are various disadvantages to this approach: - -- To reach WireGuard running on your private service, you will need a well-known IP address and port that your workflow can reference: this can either be a public IP address and port, a port mapping on a network gateway, or a service that dynamically updates DNS. -- WireGuard doesn't handle NAT traversal out of the box, so you'll need to identify a way to provide this service. -- This connection is one-to-one, so if you need high availability or high throughput you'll need to build that on top of WireGuard. -- You'll need to generate and securely store keys for both the runner and your private service. WireGuard uses UDP, so your network must support UDP traffic. - -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 - -This example workflow configures WireGuard to connect to a private service. - -For this example, the WireGuard instance running in the private network has this configuration: -- Overlay network IP address of `192.168.1.1` -- Public IP address and port of `1.2.3.4:56789` -- Public key `examplepubkey1234...` - -The WireGuard instance in the {% data variables.product.prodname_actions %} runner has this configuration: -- Overlay network IP address of `192.168.1.2` -- Private key stores as an {% data variables.product.prodname_actions %} secret under `WIREGUARD_PRIVATE_KEY` - -```yaml -name: WireGuard example - -on: - workflow_dispatch: - -jobs: - wireguard_example: - runs-on: ubuntu-latest - steps: - - run: sudo apt install wireguard - - - run: echo "${{ secrets.WIREGUARD_PRIVATE_KEY }}" > privatekey - - - run: sudo ip link add dev wg0 type wireguard - - - run: sudo ip address add dev wg0 192.168.1.2 peer 192.168.1.1 - - - run: sudo wg set wg0 listen-port 48123 private-key privatekey peer examplepubkey1234... allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:56789 - - - run: sudo ip link set up dev wg0 - - - run: curl -vvv http://192.168.1.1 -``` - -For more information, see [WireGuard's Quick Start](https://www.wireguard.com/quickstart/), as well as "[AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions)" for how to securely store keys. - -### Using Tailscale to create a network overlay - -Tailscale is a commercial product built on top of WireGuard. This option is very similar to WireGuard, except Tailscale is more of a complete product experience instead of an open source component. - -Its disadvantages are similar to WireGuard: The connection is one-to-one, so you might need to do additional work for high availability or high throughput. You still need to generate and securely store keys. The protocol is still UDP, so your network must support UDP traffic. - -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/using-secrets-in-github-actions)" 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 -- Register the resource provider -- Delegate the subnet -- Create a network settings resource in Azure -- 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 %} - -**Notes:** -- 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. -- To correctly associate the subnets with the right user, Azure `NetworkSettings` resources must be created in the same subscriptions where virtual networks are created. -- To ensure resource availability/data residency, resources must be created in the same Azure region. -- After you configure your Azure subscription, share your Azure Subscription ID with your {% data variables.product.company_short %} contact to enroll in the beta. - -{% 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 and name it `actions-nsg-deployment.bicep`. 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 in Azure - -1. Use the following GraphQL query to retrieve your enterprise `databaseId`. The enterprise `databaseId` is an integer you will use in the next step. For more information on working with GraphQL, see "[AUTOTITLE](/graphql/guides/forming-calls-with-graphql)." - - ```graphql - query( - $slug: String! - ){ - enterprise (slug: $slug) - { - slug - databaseId - } - } - - ``` - - {% data reusables.enterprise_migrations.retreive-enterprise-id-graphql %} - -1. Save the following template in a file named `networkSettingsPayload.json`. Replace `DATABASE_ID` with the enterprise `databaseId` integer you retrieved using GraphQL in the previous step. - - ```json copy - { - "subnetId": "/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP_NAME/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME", - "organizationId": "DATABASE_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' --api-version 2023-03-15-beta - ``` - - The command will return the full payload for the created resource. The following is an example of a portion of the full payload. - - {% note %} - - **Note:** The `GitHubId` hash value returned in the payload for the created resource is the network settings resource ID you will use in the next steps while configuring VNET settings with {% data variables.product.company_short %}. - - {% endnote %} - - ```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. - ![Screenshot of the "Networking" page of the Enterprise settings. A button, titled "Add private network", is highlighted with an orange outline.](/assets/images/enterprise/settings/private-networking-settings-add-network.png) -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 %} diff --git a/content/actions/using-github-hosted-runners/connecting-to-a-private-network/about-private-networking-with-github-hosted-runners.md b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/about-private-networking-with-github-hosted-runners.md new file mode 100644 index 0000000000..49e3354c6c --- /dev/null +++ b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/about-private-networking-with-github-hosted-runners.md @@ -0,0 +1,46 @@ +--- +title: About private networking with GitHub-hosted runners +shortTitle: About private networking +intro: '{% data reusables.actions.private-networking-intro %}' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +type: overview +topics: + - Actions + - Developer +--- + +{% data reusables.actions.enterprise-github-hosted-runners %} + +## About {% data variables.product.prodname_dotcom %}-hosted runners networking + +By default, {% data variables.product.prodname_dotcom %}-hosted runners have access to the public internet. However, you may also want these runners to access resources on your private network, such as a package registry, a secret manager, or other on-premise services. + +{% data variables.product.prodname_dotcom %}-hosted runners are shared across all {% data variables.product.prodname_dotcom %} customers, so you will need a way of connecting your private network to just your runners while they are running your workflows. There are a few different approaches you could take to configure this access, each with different advantages and disadvantages. + +## Using an API Gateway with OIDC + +{% data reusables.actions.private-networking-oidc-intro %} For more information, see "[AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network/using-an-api-gateway-with-oidc)." + +## Using WireGuard to create a network overlay + +{% data reusables.actions.private-networking-wireguard-intro %} For more information, see "[AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network/using-wireguard-to-create-a-network-overlay)." + +{% 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 %} For more information, see "[AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network/about-using-github-hosted-runners-in-your-azure-virtual-network)." + +{% endif %} diff --git a/content/actions/using-github-hosted-runners/connecting-to-a-private-network/about-using-github-hosted-runners-in-your-azure-virtual-network.md b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/about-using-github-hosted-runners-in-your-azure-virtual-network.md new file mode 100644 index 0000000000..6c39b8e0e1 --- /dev/null +++ b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/about-using-github-hosted-runners-in-your-azure-virtual-network.md @@ -0,0 +1,58 @@ +--- +title: About using GitHub-hosted runners in your Azure Virtual Network +shortTitle: About using a VNET +intro: 'You can create {% data variables.product.company_short %}-hosted runners in your Azure Virtual Network(s) (VNET).' +versions: + feature: actions-private-networking-azure-vnet +type: overview +topics: + - Actions + - Developer +--- + +## About using {% data variables.product.company_short %}-hosted runners in your 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 VNET without opening internet ports, including on-premises resources accessible from the Azure VNET. +- 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. + +## About network communication + +To facilitate communication between {% data variables.product.company_short %} networks and your VNET, {% data variables.product.company_short %}-hosted runner's network interface card (NIC) deploys into your Azure VNET. This way, all communication is kept private within the network boundaries, and networking policies applied to the VNET also apply to the runner. + +![Diagram of the network communication architecture between GitHub networks and your private networks. The diagram describes each step in connecting GitHub-hosted runners to an Azure VNET. Each step is numbered and the numbers correspond to the numbered descriptions of the step listed below the diagram.](/assets/images/help/actions/actions-vnet-injected-larger-runners-architecture.png) + +1. A {% data variables.product.prodname_actions %} workflow is triggered. +1. The {% data variables.product.prodname_actions %} service creates a runner. +1. The runner service deploys the {% data variables.product.company_short %}-hosted runner's network interface card (NIC) into your Azure VNET. +1. The runner agent picks up the workflow job. The {% data variables.product.prodname_actions %} service queues the job. +1. The runner sends logs back to the {% data variables.product.prodname_actions %} service. +1. The NIC accesses on-premise resources. + +## Using your VNET's network policies + +Because the {% data variables.product.company_short %}-hosted runner's NIC is deployed into your Azure VNET, 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. Additionally, any outbound rules applied to your VNET's network security group (NSG) also apply, giving you the ability to control outbound access for your runners + +If you have enabled any network logs monitoring for your VNET, you can also monitor network traffic for your runners. + +## Using {% data variables.product.company_short %}-hosted runners with an Azure VNET + +To use {% data variables.product.company_short %}-hosted runners with Azure VNET, you must configure Azure and configure your {% data variables.product.company_short %} settings to use {% data variables.product.company_short %}-hosted runners with a VNET. + +For more information about configuring Azure, see "[AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-an-azure-virtual-network-for-your-enterprise)." + +For more information about configuring your {% data variables.product.company_short %} settings to use {% data variables.product.company_short %}-hosted runners with a VNET, see "[AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-your-github-settings-for-use-with-azure-virtual-network)." \ No newline at end of file diff --git a/content/actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-azure-resources-for-private-networking-with-github-hosted-runners.md b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-azure-resources-for-private-networking-with-github-hosted-runners.md new file mode 100644 index 0000000000..33a5dc0115 --- /dev/null +++ b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-azure-resources-for-private-networking-with-github-hosted-runners.md @@ -0,0 +1,213 @@ +--- +title: Configuring Azure resources for private networking with GitHub-hosted runners +shortTitle: Configuring Azure resources +intro: 'Learn how to configure your Azure Virtual Network (VNET) to use {% data variables.product.company_short %}-hosted runners.' +versions: + feature: actions-private-networking-azure-vnet +type: how_to +topics: + - Actions + - Developer +redirect_from: + - /actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-an-azure-virtual-network-for-your-enterprise +--- + +{% note %} + +**Note:** {% data reusables.actions.github-hosted-larger-runners-azure-vnet-beta %} + +{% endnote %} + +## About configuring your Azure resources + +To use an Azure VNET for private networking, you must configure your Azure resources. You can use the following script to automate the process. For more information about private networking, see "[AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network/about-private-networking-with-github-hosted-runners)." + +## Prerequisites + +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. + +To correctly associate the subnets with the right user, Azure `NetworkSettings` resources must be created in the same subscriptions where virtual networks are created. + +To ensure resource availability/data residency, resources must be created in the same Azure region. + +After you configure your Azure subscription, share your Azure Subscription ID with your {% data variables.product.company_short %} contact to enroll in the beta. + +Save the following `.bicep` file in the same directory location of the script. Name the file `actions-nsg-deployment.bicep`. + +```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: [] + } + } + ] + } +} +``` + +## Using a script to configure your Azure resources + +Use the following script to set up a subnet with VNET-injection in Azure. The script creates all resources in the same resource group. + +To use the script, fill in the placeholder environment variable values with the actual values and run the script from a bash shell or Windows Subsystem for Linux. + +```bash copy +#!/bin/bash + +# This script creates the following resources in the specified subscription: +# - Resource group +# - Network Security Group rules +# - Virtual network (vnet) and subnet +# - Network Settings with specified subnet and GitHub Enterprise databse ID +# +# It also registers the `GitHub.Network` resource provider with the subscription, +# delegates the created subnet to the Actions service via the `GitHub.Network/NetworkSettings` +# resource type, and applies the NSG rules to the created subnet. + +# stop on failure +set -e + +#set environment +AZURE_LOCATION=YOUR_AZURE_LOCATION +SUBSCRIPTION_ID=YOUR_SUBSCRIPTION_ID +RESOURCE_GROUP_NAME=YOUR_RESOURCE_GROUP_NAME +VNET_NAME=YOUR_VNET_NAME +SUBNET_NAME=YOUR_SUBNET_NAME +NSG_NAME=YOUR_NSG_NAME +NETWORK_SETTINGS_RESOURCE_NAME=YOUR_NETWORK_SETTINGS_RESOURCE_NAME +DATABASE_ID=YOUR_DATABASE_ID + +echo login to Azure +. az login --output none + +echo set account context $SUBSCRIPTION_ID +. az account set --subscription $SUBSCRIPTION_ID + +echo Register resource provider GitHub.Network +. az provider register --namespace GitHub.Network + +echo Create resource group $RESOURCE_GROUP_NAME at $AZURE_LOCATION +. az group create --name $RESOURCE_GROUP_NAME --location $AZURE_LOCATION + +echo Create NSG rules deployed with 'actions-nsg-deployment.bicep' file +. az deployment group create --resource-group $RESOURCE_GROUP_NAME --template-file ./actions-nsg-deployment.bicep --parameters location=$AZURE_LOCATION nsgName=$NSG_NAME + +echo Create vnet $VNET_NAME and subnet $SUBNET_NAME +. az network vnet create --resource-group $RESOURCE_GROUP_NAME --name $VNET_NAME --address-prefix 10.0.0.0/16 --subnet-name $SUBNET_NAME --subnet-prefixes 10.0.0.0/24 + +echo Delegate subnet to GitHub.Network/networkSettings and apply NSG rules +. az network vnet subnet update --resource-group $RESOURCE_GROUP_NAME --name $SUBNET_NAME --vnet-name $VNET_NAME --delegations GitHub.Network/networkSettings --network-security-group $NSG_NAME + +echo Create network settings resource $NETWORK_SETTINGS_RESOURCE_NAME +. az resource create --resource-group $RESOURCE_GROUP_NAME --name $NETWORK_SETTINGS_RESOURCE_NAME --resource-type GitHub.Network/networkSettings --properties "{ \"location\": \"$AZURE_LOCATION\", \"properties\" : { \"subnetId\": \"/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP_NAME/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME\", \"organizationId\": \"$DATABASE_ID\" }}" --is-full-object --api-version 2023-03-15-beta + +echo To clean up and delete resources run the following command: +echo az group delete --resource-group $RESOURCE_GROUP_NAME + +``` + +The script will return the full payload for the created resource. The `GitHubId` hash value returned in the payload for the created resource is the network settings resource ID you will use in the next steps while configuring VNET settings with {% data variables.product.company_short %}. diff --git a/content/actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-your-github-settings-for-use-with-azure-virtual-network.md b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-your-github-settings-for-use-with-azure-virtual-network.md new file mode 100644 index 0000000000..ff6cc1fb70 --- /dev/null +++ b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/configuring-your-github-settings-for-use-with-azure-virtual-network.md @@ -0,0 +1,60 @@ +--- +title: Configuring your GitHub settings for use with Azure Virtual Network +shortTitle: Configuring {% data variables.product.company_short %} settings +intro: 'Learn how to configure your {% data variables.product.company_short %} settings to use {% data variables.product.company_short %}-hosted runners with an Azure Virtual Network (VNET).' +versions: + feature: actions-private-networking-azure-vnet +type: how_to +topics: + - Actions + - Developer +--- + +{% note %} + +**Note:** {% data reusables.actions.github-hosted-larger-runners-azure-vnet-beta %} + +{% endnote %} + +## About configuring your {% data variables.product.company_short %} settings for use with an Azure VNET + +To use an Azure VNET for private networking, you must configure your {% data variables.product.company_short %} settings. For more information about private networking, see "[AUTOTITLE](/actions/using-github-hosted-runners/connecting-to-a-private-network/about-private-networking-with-github-hosted-runners)." + +## Adding a private network and 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. 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. + ![Screenshot of the "Networking" page of the Enterprise settings. A button, titled "Add private network", is highlighted with an orange outline.](/assets/images/enterprise/settings/private-networking-settings-add-network.png) +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**. +1. Click the name of the private network. +1. Under "Services allowed," click **{% data variables.product.prodname_actions %}**. +1. Click **Save changes**. + +## Creating a VNET-injected runner group + +{% 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-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)." + +{% endnote %} + +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. + +## 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. + +{% endnote %} + +1. Add the {% data variables.product.company_short %}-hosted runner to the VNET-injected runner group. For more information, see "[AUTOTITLE](/enterprise-cloud@latest/actions/using-github-hosted-runners/managing-larger-runners#adding-a-larger-runner-to-an-enterprise)." diff --git a/content/actions/using-github-hosted-runners/connecting-to-a-private-network/index.md b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/index.md new file mode 100644 index 0000000000..856cd1432f --- /dev/null +++ b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/index.md @@ -0,0 +1,18 @@ +--- +title: 'Connecting to a private network with {% data variables.product.company_short %}-hosted runners' +shortTitle: Private networking +intro: '{% data reusables.actions.private-networking-intro %}' +versions: + fpt: '*' + ghec: '*' + ghes: '*' +children: + - /about-private-networking-with-github-hosted-runners + - /using-an-api-gateway-with-oidc + - /using-wireguard-to-create-a-network-overlay + - /about-using-github-hosted-runners-in-your-azure-virtual-network + - /configuring-azure-resources-for-private-networking-with-github-hosted-runners + - /configuring-your-github-settings-for-use-with-azure-virtual-network +--- + +{% data reusables.actions.enterprise-github-hosted-runners %} diff --git a/content/actions/using-github-hosted-runners/connecting-to-a-private-network/using-an-api-gateway-with-oidc.md b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/using-an-api-gateway-with-oidc.md new file mode 100644 index 0000000000..7f513af520 --- /dev/null +++ b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/using-an-api-gateway-with-oidc.md @@ -0,0 +1,32 @@ +--- +title: Using an API gateway with OIDC +shortTitle: Using OIDC +intro: 'You can use OpenID Connect (OIDC) tokens to authenticate your workflow.' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +type: how_to +topics: + - Actions + - Developer +--- + +## Using an API gateway with OIDC + +{% data reusables.actions.private-networking-oidc-intro %}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. + +The following diagram gives an overview of this solution's architecture: + +![Diagram of an OIDC gateway architecture, starting with a {% data variables.product.prodname_actions %} runner and ending with a private network's private service.](/assets/images/help/actions/actions-oidc-gateway.png) + +It's important that you verify not just that the OIDC token came from {% data variables.product.prodname_actions %}, but that it came specifically from your expected workflows, so that other {% data variables.product.prodname_actions %} users aren't able to access services in your private network. You can use OIDC claims to create these conditions. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#defining-trust-conditions-on-cloud-roles-using-oidc-claims)." + +The main disadvantages of this approach are that you must implement the API gateway to make requests on your behalf, and you must run the gateway on the edge of your network. + +The following advantages apply. + +- You don't need to configure any firewalls, or modify the routing of your private network. +- The API gateway is stateless and scales horizontally to handle high availability and high throughput. + +For more information, see [a reference implementation of an API Gateway](https://github.com/github/actions-oidc-gateway-example) in the github/actions-oidc-gateway repository. This implementation requires customization for your use case and is not ready-to-run as-is). For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)." diff --git a/content/actions/using-github-hosted-runners/connecting-to-a-private-network/using-wireguard-to-create-a-network-overlay.md b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/using-wireguard-to-create-a-network-overlay.md new file mode 100644 index 0000000000..330022fcb2 --- /dev/null +++ b/content/actions/using-github-hosted-runners/connecting-to-a-private-network/using-wireguard-to-create-a-network-overlay.md @@ -0,0 +1,76 @@ +--- +title: Using WireGuard to create a network overlay +shortTitle: Using WireGuard +intro: 'You can create an overlay network between your runner and a service in your private network.' +versions: + fpt: '*' + ghes: '*' + ghec: '*' +type: how_to +topics: + - Actions + - Developer +--- + +## Using WireGuard to create a network overlay + +{% data reusables.actions.private-networking-wireguard-intro %} + +There are various disadvantages to this approach: + +- To reach WireGuard running on your private service, you will need a well-known IP address and port that your workflow can reference: this can either be a public IP address and port, a port mapping on a network gateway, or a service that dynamically updates DNS. +- WireGuard doesn't handle NAT traversal out of the box, so you'll need to identify a way to provide this service. +- This connection is one-to-one, so if you need high availability or high throughput you'll need to build that on top of WireGuard. +- You'll need to generate and securely store keys for both the runner and your private service. WireGuard uses UDP, so your network must support UDP traffic. + +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 + +This example workflow configures WireGuard to connect to a private service. + +For this example, the WireGuard instance running in the private network has this configuration: +- Overlay network IP address of `192.168.1.1` +- Public IP address and port of `1.2.3.4:56789` +- Public key `examplepubkey1234...` + +The WireGuard instance in the {% data variables.product.prodname_actions %} runner has this configuration: +- Overlay network IP address of `192.168.1.2` +- Private key stores as an {% data variables.product.prodname_actions %} secret under `WIREGUARD_PRIVATE_KEY` + +```yaml +name: WireGuard example + +on: + workflow_dispatch: + +jobs: + wireguard_example: + runs-on: ubuntu-latest + steps: + - run: sudo apt install wireguard + + - run: echo "${{ secrets.WIREGUARD_PRIVATE_KEY }}" > privatekey + + - run: sudo ip link add dev wg0 type wireguard + + - run: sudo ip address add dev wg0 192.168.1.2 peer 192.168.1.1 + + - run: sudo wg set wg0 listen-port 48123 private-key privatekey peer examplepubkey1234... allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:56789 + + - run: sudo ip link set up dev wg0 + + - run: curl -vvv http://192.168.1.1 +``` + +For more information, see [WireGuard's Quick Start](https://www.wireguard.com/quickstart/), as well as "[AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions)" for how to securely store keys. + +### Using Tailscale to create a network overlay + +Tailscale is a commercial product built on top of WireGuard. This option is very similar to WireGuard, except Tailscale is more of a complete product experience instead of an open source component. + +Its disadvantages are similar to WireGuard: The connection is one-to-one, so you might need to do additional work for high availability or high throughput. You still need to generate and securely store keys. The protocol is still UDP, so your network must support UDP traffic. + +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/using-secrets-in-github-actions)" for how to securely store keys. diff --git a/content/actions/using-github-hosted-runners/index.md b/content/actions/using-github-hosted-runners/index.md index 5f3eeebb90..d9f5ca7062 100644 --- a/content/actions/using-github-hosted-runners/index.md +++ b/content/actions/using-github-hosted-runners/index.md @@ -8,13 +8,8 @@ versions: ghes: '*' children: - /about-github-hosted-runners - - /monitoring-your-current-jobs - - /customizing-github-hosted-runners - - /connecting-to-a-private-network - /about-larger-runners - - /managing-larger-runners - - /controlling-access-to-larger-runners - - /running-jobs-on-larger-runners + - /connecting-to-a-private-network --- - + {% data reusables.actions.enterprise-github-hosted-runners %} diff --git a/data/reusables/actions/azure-vnet-injected-runners-intro.md b/data/reusables/actions/azure-vnet-injected-runners-intro.md index 734f6c98fc..2c9aa516cd 100644 --- a/data/reusables/actions/azure-vnet-injected-runners-intro.md +++ b/data/reusables/actions/azure-vnet-injected-runners-intro.md @@ -1 +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. \ No newline at end of file +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 VNET(s). 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. \ No newline at end of file diff --git a/data/reusables/actions/private-networking-intro.md b/data/reusables/actions/private-networking-intro.md new file mode 100644 index 0000000000..8d2b14e2d0 --- /dev/null +++ b/data/reusables/actions/private-networking-intro.md @@ -0,0 +1 @@ +You can connect {% data variables.product.prodname_dotcom %}-hosted runners to resources on a private network, including package registries, secret managers, and other on-premises services. \ No newline at end of file diff --git a/data/reusables/actions/private-networking-oidc-intro.md b/data/reusables/actions/private-networking-oidc-intro.md new file mode 100644 index 0000000000..6cb9666f48 --- /dev/null +++ b/data/reusables/actions/private-networking-oidc-intro.md @@ -0,0 +1 @@ +With {% data variables.product.prodname_actions %}, you can use OpenID Connect (OIDC) tokens to authenticate your workflow outside of {% data variables.product.prodname_actions %}. \ No newline at end of file diff --git a/data/reusables/actions/private-networking-wireguard-intro.md b/data/reusables/actions/private-networking-wireguard-intro.md new file mode 100644 index 0000000000..f3f2f6e7ff --- /dev/null +++ b/data/reusables/actions/private-networking-wireguard-intro.md @@ -0,0 +1 @@ +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. \ No newline at end of file diff --git a/src/content-render/tests/render-changed-and-deleted-files.js b/src/content-render/tests/render-changed-and-deleted-files.js index fd7d45e5dc..3fa339d2bc 100644 --- a/src/content-render/tests/render-changed-and-deleted-files.js +++ b/src/content-render/tests/render-changed-and-deleted-files.js @@ -118,6 +118,9 @@ describe('deleted-content', () => { res.statusCode === 404 ? `The deleted file ${file} did not set up a redirect when deleted.` : '' - expect(res.statusCode, error).toBe(301) + // Certain articles that are deleted and moved under a directory with the same article name + // should just route to the map topic page instead of redirecting (docs content team confirmed). + // So, in this scenario, we'd get a 200 status code. + expect(res.statusCode === 301 || res.statusCode === 200, error).toBe(true) }) })