The way Github Actions work is that they spin up a VM for every workflow run. Therefore, every run takes place on a different VM. Virtual Machines generally get a different IP whenever they are spun up. I can however find no official documentation which clarifies if this is the case with Github Actions runner VMs.
Update 2022:
As noted in Krzysztof Madej's answer, GitHub now (Sept. 2022) proposes:
GitHub Actions Larger runners – Are now in public beta
That includes (for Team and Enterprise GitHub Action users only):
Fixed IP ranges to provide access to runners via allow list services.
So that would not apply for github.com runners.
2021:
This thread mentions (in 2019, so that might have changed since then):
Windows and Ubuntu hosted runners are hosted in Azure and have the same IP address ranges as Azure Data centers.
Currently, all hosted runners are in the East US 2 Azure region, but more regions may added over time.
Microsoft updates the Azure IP address ranges weekly in a JSON file that you can download from the Azure IP Ranges and Service Tags - Public Cloud 153 website. You can use this range of IP addresses if you require an allow-list to prevent unauthorized access to your internal resources.
So there should be a new address within a range of IPs.
It references: "Specifications for GitHub-hosted runners", which mentions:
Note: If you use an IP address allow list for your GitHub organization or enterprise account, you cannot use GitHub-hosted runners and must instead use self-hosted runners.
For more information, see "About self-hosted runners."
(Specifically, the IP address section)
You can assign fixed IP address for your runners:
Fixed IP ranges
Setup a fixed IP range for your machines by simply ticking a check box, this provides an IP range that can be allow listed in internal systems and in GitHub’s allow list to keep using Actions while making your GitHub environment more secure.
This in beta, but it helps to whitelist it on your firewall.
Related
We are trying to start using the Azure Pipelines agents instead of Self hosted ones. While trying to convert over or Acceptance tests I am running into an issue with the agent not allowing our test to connect to an api we spin up with in the Agent that is running on port 44392. Noticed this post. How to open TCP port on localhost on VSTS build agent?, from a couple years ago and is pretty similar to how our test is working. Just wondering if the answer is still accurate or not.
Since your are using the Hosted Agents, which means that the machine is a shared resource between many Azure DevOps Organizations (tenants) and managed (and locked) down by Microsoft.
In other words, we do not provide end user to open port with these agents. The answer in your link is still valid.
You may have to install an agent on your own virtual machine and run the build there. The VM can be in the cloud or on premise. You trade simplicity and cheapness for full control.
Azure DevOps CI: task: sftpupload#1 access issue
I need to copy my Artifacts to to private server through ftps. The server only allow IP's it know to access the server. How can I find Australia East Azure DevOps IP that I need to white list. Can any one help ?
How can I find Australia East Azure DevOps IP that I need to white list. Can any one help ?
It seems you are use Microsoft-hosted agent to run your task: sftpupload#1. For the Microsoft-hosted agent white list, you could check the document Microsoft-hosted agents Agent IP ranges for some more details:
Azure DevOps uses the Azure global network, IP ranges vary over time.
We publish a weekly JSON file listing IP ranges for Azure datacenters,
broken out by region. This file is published every Wednesday (US
Pacific time) with new planned IP ranges. The new IP ranges become
effective the following Monday. We recommend that you check back
frequently to ensure you keep an up-to-date list. If agent jobs begin
to fail, a key first troubleshooting step is to make sure your
configuration matches the latest list of IP addresses.
So, you could check that json file for the Microsoft-hosted agent white list.
Besides, if you want the white list for the Azure DevOps IP instead of Microsoft-hosted agent, you could check the document Allowed address lists and network connections for some more details.
Hope this helps.
Have installed VSTS agent in a very locked down environment. It makes a connection to VSTS, gets job but fails when downloading artefact. Gives error
Error: in getBuild, so retrying => retries pending : 4.
It retries 4 times and fails.
The agent is going thru a proxy. Have setup the proxy using ./config --proxyurl and also set HTTP_PROXY AND HTTPS_PROXY system environment vars.
The proxy is very limiting in that URLS are locked down, there is no authentication required. Does anybody know what URLs the agent accesses? Am hoping if can get a definitive list this will solve the issue. If anybody knows how can get a list would be great. Or maybe I have misconfigured?
Any ideas?
Tyring to run VSTS agent thru a proxy which limits sites
According to the document
I'm running a firewall and my code is in Azure Repos. What URLs does the agent need to communicate with?:
To ensure your organization works with any existing firewall or IP
restrictions, ensure that dev.azure.com and dev.azure.com are open
and update your allow-listed IPs to include the following IP
addresses, based on your IP version. If you're currently allow-listing
the 13.107.6.183 and 13.107.9.183 IP addresses, leave them in place,
as you don't need to remove them.
And With just the organization's name or ID, you can get its base URL using the global Resource Areas REST API (https://dev.azure.com/_apis/resourceAreas). This API doesn't require authentication and provides information about the location (URL) of the organization as well as the base URL for REST APIs, which can live on different domains.
Please check this document Best practices for working with URLs in Azure DevOps extensions and integrations for some more details.
Hope this helps.
I'm getting an error in my release pipeline (Azure DevOps) when I deploy content to a static website in Azure Storage with IP restrictions enabled.
Error parsing destination location "https://MYSITE.blob.core.windows.net/$web": Failed to validate destination. The remote server returned an error: (403) Forbidden.
The release was working fine until I added IP Restrictions to the storage account to keep the content private. Today, we use IP restrictions to control access. Soon, we will remove the IP restrictions in favor of vpn and vnets. However, my expectation is that I will have the same problem.
My assumption is that Azure DevOps cannot access the storage account because it is not whitelisted in the IP Address list. My release pipeline uses the AzureBlob File Copy task.
steps:
- task: AzureFileCopy#2
displayName: 'AzureBlob File Copy'
inputs:
SourcePath: '$(System.DefaultWorkingDirectory)/_XXXXX/_site'
azureSubscription: 'XXXX'
Destination: AzureBlob
storage: XXXX
ContainerName: '$web'
I have already enabled "trusted Microsoft services" but that doesn't
help.
Whitelisting the IP Addresses for Azure DevOps is not a good option because there are TONS of them and they change regularly.
I've seen suggestions to remove the IP restrictions and re-enable them after the publish step. This is risky because if something were to fail after the IP restrictions are removed, my site would be publicly accessible.
I'm hoping someone has other ideas! Thanks.
You can add a step to whitelist the agent IP address, then remove it from the whitelist at the end of the deployment. You can get the IP address by making a REST call to something like ipify.
I have done that for similar scenarios and it works well.
I would recommend a different approach: running an Azure DevOps agent with a static IP and/or inside the private VNet.
Why I consider this a better choice:
audit logs will be filled with addition and removal of rules, making harder analysis in case of attack
the Azure connection must be more powerful than needed, specifically to change Rules in Security Groups or Firewall or Application Gateway or else, while it only needs deploy permissions
it opens traffic from outside, while temporarily, while a private agent needs always initiate from inside
No solution is perfect, so it is important to chose the best for your specific scenario.
I've tried to get VSTS to connect to our enterprise Git repository.
To do this I had to get our firewall opened up, and as a result we found that VSTS does not connect to our network using the VSTS domain, ie ########.visualstudio.com
Instead it connects using the IP address of the build agent, which is in the range specified in the Azure Public IP list.
Does anyone know if this is a bug on MS's part? We could free up our firewall to all the Azure Public IP's, but this is very fragile (they can/will change), and presents a significant security risk as anyone using Azure could attempt to connect to our Git repository.
Interestingly, if you install a private build agent, then VSTS connects to this using the VSTS domain, we have observed this.
In my opinion, it's because the Hosted Build IP updates continuously. You can check the following Q&A:
What IP Addresses are used by Hosted Build?
We have an XML document released every Wednesday that contains all of
the IP ranges for Azure Datacenters broken out by region. Please see
https://www.microsoft.com/en-us/download/confirmation.aspx?id=41653:
This file contains the Compute IP address ranges (including SQL
ranges) used by the Microsoft Azure Datacenters. A new xml file will
be uploaded every Wednesday (Pacific Time) with the new planned IP
address ranges. New IP address ranges will be effective on the
following Monday (Pacific Time). Please download the new xml file and
perform the necessary changes on your site before Monday. The Hosted
agent should be in the same region as your VSTS account, you need to
whitelist the IP address ranges for your region which you can get from
the link above. To verify your region in VSTS navigate to the
Settings page at .visualstudio.com/_admin/_home/settings,
Under Account you will see a field for Region.