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.
Related
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.
We use Azure DevOps with Microsoft-hosted agents, and because we would like to apply authorized IP ranges for our AKS we need the agent IP addresses.
To automate the process in our release pipeline we have included Azure CLI task with the command :
AGENT_IP=$(curl -s https://ipinfo.io/json | jq -r .ip)
az aks update --resource-group xxx --name yyy --api-server-authorized-ip-ranges ${AGENT_IP}
All the AGENT_IPs, we are getting from the command line, are not listed in the weekly json file.
Even the operation is executed successfully and the AGENT_IP is included in the "apiServerAccessProfile.authorizedIpRanges" section, sometimes we are not able to deploy our microservice to the AKS and we are getting an error: "Unable to connect to the server: dial tcp xx.xx.xx.xx:443: i/o timeout".
However sometimes the deployment is successful, even though the AGENT_IP is not listed in the weekly json.
Why the IP addresses I am getting, are not in the weekly json file ?
Randomly I am able to deploy to AKS ?
Please read these docs:
Allowed address lists and network connections
Agent IP ranges
I got IP address using this script:
Invoke-RestMethod -Uri ('http://ipinfo.io/'+(Invoke-WebRequest -uri "http://ifconfig.me/ip").Content)
And for build pipelines I got IP address which was outside of any IP range from weekly file for AzureCloud.westeurope. (In my case it was 168.63.69.117, 137.135.240.152). However for relese pipeline I got IP which are in IP ranges from weekly file:
52.157.67.128 - IP Range 52.157.64.0/18
40.118.28.211 - IP Range 40.118.0.0/17
But I noticed that build agents are located in Ireland and this is North Europe region. And yes, IP addresses matches IP ranges from North Europe:
137.135.240.152 - IP Range 137.135.128.0/17
168.63.69.117 - IP range 168.63.64.0/20
I have no idea why this works like that since I have West Europe region in my settings.
But to sum up:
build pipelines - North Europe region
release pipelines - West Europe region
My scenario is quite basic. Let me try to explain:
I do have an on-premise instance of Gitlab behind the firewalls of
my company
And I am trying to fetch data from a pipeline set on Azure Devops
(dev.azure.com)
I am getting this error when queuing a job run
##[error]Git fetch failed with exit code: 128
The IT security folks ask for an IP to Whitelist as INBOUND, but I have no clue what range I should give them.
Anyone faced such situation?
If as what your IT security asked and you used is hosted agent, the ip range should be the one which can grant the hosted agents access through a firewall.
Follow this doc:
To determine your geography, navigate to
https://dev.azure.com//_settings/organizationOverview,
get your region, and find the associated geography from the Azure
geography table. Once you have identified your geography, use the
IP ranges from the weekly file for all regions in that geography.
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.