I have an application running on Web App that needs to communicate with Azure DevOps Microsoft hosted agent. I've set some IP restrictions to deny everything and now in the process of whitelisting agent's IPs. When I read this page it refers to weekly json that contains objects about everything what I need (CIDRs per region). I've parsed the json, added them to my allow list, however the agent's public IP address is not from the range mentioned in the json. The way I checked it was running bash task on the agent to curl icanhazip.com. Does anyone know if the list is complete or should I look somewhere else?
I.e. example in my case:
I use this data (since my ADO org is in West Europe):
{
"name": "AzureDevOps.WestEurope",
"id": "AzureDevOps.WestEurope",
"properties": {
"changeNumber": 1,
"region": "westeurope",
"regionId": 18,
"platform": "Azure",
"systemService": "AzureDevOps",
"addressPrefixes": [
"40.74.28.0/23"
],
"networkFeatures": null
}
}
but the agent initiates connection from the IP: 20.238.71.171, which is not in any of the CIDRs privided by that json file (checked all other regions with ADO).
Any thoughts / help?
You would need to whitelist ALL ranges from, for instance, Azure West Europe. Those are a lot of different IP ranges, as Azure DevOps hosted agents do not have a service Tag.
Since this opens up your firewall to literally every VM running in West Europe, this is usually not really desired, as it is just a bit short of opening up your App to the entire world.
Hence, what people usually do is the following:
First task in a build job, fetch the public IP address of the executing build agent, using something like ipfy.org
Use AZ CLI to add this IP as a single IP allow rule to your app
Do your deployment etc
Remove the IP rule again
If you mean MS-hosted agent:
You should use AzureCloud service tag
The IP address ranges for the hosted agents are listed in the weekly file under AzureCloud., such as AzureCloud.westus for the West US region.
Docs:
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#networking
Related
I am trying to build a proof-of-concept integration with Azure Cloud into another system. I am not an Azure subject matter expert, so I am struggling with the end-to-end integration.
I am having trouble associating a "Network Security Group" to the "Network Interface". I am able to create both, but they do not not associate to each other until I manually go into the Cloud Portal and associate.
I am using the following:
API Documentation:
https://learn.microsoft.com/en-us/rest/api/compute/virtualmachines
API Explorer:
https://resources.azure.com
I am calling the following end-points in order:
publicIPAddresses
https://management.azure.com/subscriptions/{subscriptionID}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/publicIPAddresses/{resourceName}?api-version=2018-07-01
networkInterfaces
https://management.azure.com/subscriptions/{subscriptionID}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/networkInterfaces/{resourceName}?api-version=2018-07-01
networkSecurityGroups
https://management.azure.com/subscriptions/{subscriptionID}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/networkSecurityGroups/{resourceName}?api-version=2018-07-01
virtualMachines : https://management.azure.com/subscriptions/{subscriptionID}/resourceGroups/{resourceGroup}/providers/Microsoft.Compute/virtualMachines/{resourceName}?$expand=instanceView&api-version=2018-06-01
Everything else works except the NSG associating to the NIC.
Within the "networkSecurityGroups" message, I pass in the following parameter under the properties node.
"networkInterfaces": [{
"id": "/subscriptions/" + subscriptionID + "/resourceGroups/" + resourceGroup + "/providers/Microsoft.Network/networkInterfaces/" + networkInterfaces
}
]
I've tried reversing it by referencing the NSG in the Interface REST call, but still doesn't work. Oddly enough, I use the same syntax to associate the Interface to the VM itself, and that works as expected. Variations of the same syntax work with associating the PublicIP to the Interface, disks to VM, ect.
Any thoughts?
pretty sure you need to add this under NIC properties section:
"networkSecurityGroup": {
"id": "NSG_Resource_Id"
}
I have an Azure Dev Test Lab that I am deploying to Azure via Power Shell. I am able to deploy the ARM templates and join to the test domain (not Azure AD) with no issues. The next step I would like to do is to set the IP to static. I can think of 3 ways to possibly do this. Either figure out the IP structure beforehand and deploy it with those settings. Let the DHCP assign the settings and try to problematically set them from Dynamic to Static using Powershell DSC. Or some type of preferred lease from the DHCP. These labs are meant to be stood up and torn down ad hoc. The IPs are internal and not Public. It is possible for me to know the IPs before hand. Could someone make a recommendation on what would make the most sense to pursue?
Well, there are several ways of looking at it, first of all, you can define ip at deployment time, by setting it to static, instead of dynamic:
{
"name": "xxx",
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2016-10-01",
"location": "loc",
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Static",
"privateIPAddress": "ipgoeshere",
"subnet": {
"id": "subnetgoeshere"
}
}
}
]
}
but this method is only valid if you know the available IP addresses beforehand and you will have to look those up and pass to the template.
Another way of doing this is créating NIC as dynamic, getting its IP address and setting it to static. All can be done with an ARM Template. The example is a bit too much to paste here, you can check it here. look for deployments called: "[concat(variables('vmNamePrefix'),'setStaticIp')]", and "[concat(variables('vmNamePrefix'),copyIndex(1),'-primaryIp')]", and their corresponding templates: getip and setip
You can do pretty much the same with powershell, I dont have a script Handy, but the logic is the same, deploy > getip > setip
I'm testing using a gMSA account to run an SF app, instead of NETWORKSERVICE.
Following the instructions from here:
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-application-runas-security
Created the gMSA on the domain controller using the powershell cmdlet:
New-ADServiceAccount -name MySA$ -DnsHostName MySA.contoso -ServicePrincipalNames http/MySA.contoso -PrincipalsAllowedToRetrieveManagedPassword Node0Machine$, Node1Machine$, Node2Machine$
Install-AdServiceAccount returned an "unspecified error" on each of the nodes, however Test-AdServiceAccount returns true for MySA$ (when running powershell as a domain user)
ApplicationManifest.xml has the following changes:
<Principals>
<Users>
<User Name="MySA" AccountType="ManagedServiceAccount" AccountName="Contoso\MySA$"/>
</Users>
</Principals>
<Policies>
<SecurityAccessPolicies>
<SecurityAccessPolicy ResourceRef="ConfigurationEncipherment" PrincipalRef="MySa" ResourceType="Certificate" />
</SecurityAccessPolicies>
<DefaultRunAsPolicy UserRef="MySA"/>
</Policies>
The Service Fabric explorer shows the following error for each service:
Error event: SourceId='System.Hosting', Property='CodePackageActivation:Code:SetupEntryPoint'.
There was an error during CodePackage activation.Service host failed to activate. Error:0x8007052e
I have also tried creating the cluster using the gMSA (we are using X509 successfully at the moment). Using the gMSA cluster config as a template, it fails with a timeout (presumably the "WindowsIdentities section is incorrect - there seems to be little documentation on this)
"security": {
"WindowsIdentities": {
"ClustergMSAIdentity": "MySA$#contoso",
"ClusterSPN": "http/MySa.contoso",
"ClientIdentities": [
{
"Identity": "contoso\\MySA$",
"IsAdmin": true
}
]
},
The Error:0x8007052e may be linked to a logon failure.
According to Secure a standalone cluster on Windows by using Windows security and Connect to a secure cluster
If you have more than 10 nodes or for clusters that are likely to grow or shrink. Microsoft strongly recommend using the Group Managed Service Account (gMSA) approach.
You will see also:
You can establish trust in two different ways:
Specify the domain group users that can connect.
Specify the domain node users that can connect.
[...]
Administrators have full access to management capabilities (including read/write capabilities). Users, by default, have only read access to management capabilities (for example, query capabilities), and the ability to resolve applications and services.
You may also find help on Getting Started with Group Managed Service Accounts
According to your comment, as soon as you add the gMSA to the ServiceFabricAdministrators group everything will work and it is probably due to the fact that "administrators have full access to management capabilities"
In my current code base, when i create a VM, DNS name is being dynamically set as same as the instance name. For example, consider if my VM name is "anandInstance", DNS name of the name is being generated as "anandInstance.cloudapp.net". Is there a way to change the DNS name like "dns1.cloudapp.net" during the creation thru REST API??
"Connect to existing VM" , is it possible to achieve this option through REST call? In case "connect to existing.." option , we are getting a list of vms/services to choose and VM is getting created successfully. How to achieve the same using API.
Thanks
In my current code base, when i create a VM, DNS name is being
dynamically set as same as the instance name. For example, consider if
my VM name is "anandInstance", DNS name of the name is being generated
as "anandInstance.cloudapp.net". Is there a way to change the DNS name
like "dns1.cloudapp.net" during the creation thru REST API??
I don't think it is possible. Imagine what a nightmare in the portal would become if you were able to do so? How would you link a Cloud Service (whatever.cloudapp.net) to an actual deployment (MyDemoVm123). However you can use your own domain and have CNAME records pointing to your "want-to-change-for-some-reason.cloudapp.net" (frankly I surely think that soon we will use even longer names)
"Connect to existing VM" , is it possible to achieve this option
through REST call?
Connection to a VM is essentially opening a RDP session. If it a windows VM, you can try using the Download RDP file API call. Once you get the file, just start it with "process.start". If it is linux VM, just start SSH client on port 22 (or one you have defined) from the Cloud Service DNS name you have.
UPDATE
From the azure portal,for stand alone machineoption, we are able to give the dns name with deafult cloudoneapp.net. How to do the same
through the rest api call.any specfic paramter is there to specify the
same?
When you are using the REST API, you first create a Cloud Service (still named hosted service in the REST API) where your machine will be hosted. Here you give the name for that hosted service (the dns name with deafult cloudoneapp.net). Then you call the Create Virtual Machine Deployment API action.
In case "connect to existing.." option , we are getting a list of vms/services to choose and VM is getting created successfully. How to
achieve the same using API.
When you want to get list of all VMs, just get a list of all Hosted Services, then get properties of each and make a guess whether it is a VM or a Cloud Service (maybe by querying for Properties of each service). I don't see a direct access to the list of Virtual Machines. But as this feature being PREVIEW, things might change in the future.
Hope my answer is clear?
I'm performing REST API operation Start Role (http://msdn.microsoft.com/en-us/library/jj157189.aspx)
In the link https://management.core.windows.net/{subscription-id}/services/hostedservices/{service-name}/deployments/{deployment-name}/roles/{role-name}/Operations we have replaced {service-name}, {deployment-name} and {role-name} with name of VM.
In result we have next message:
"ResourceNotFoundThe resource service name hostedservices is not supported."
List Hosted Services operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460781.aspx) shows us that we have 2 WMs as hosted services.
Get Role operaion (http://msdn.microsoft.com/en-us/library/jj157193.aspx) also gives info about each of VMs.
Thanks in advance.
You are using:
{subscription-id}/services/hostedservices/{service-name}/deployments/{deployment-name}/roles/{role-name}/Operations
But the correct Uri is:
{subscriptionID}/services/hostedservices/{serviceName}/deployments/{deploymentName}/roleInstances/{roleInstanceName}/Operations
See the difference?
I haven't worked with this particular operation, however a few things:
service-name: It should be the name of the hosted service (the one with .cloudapp.net) and what you see when you list your hosted service.
deployment-name: Generally speaking it's a GUID returned by Get Deployment operation (http://msdn.microsoft.com/en-us/library/windowsazure/ee460804.aspx).
role-name: Role name is also returned when you do a Get Deployment operation. You should use that. I'm not sure if it is same as the name of your VM.
Can you retry your operation after changing these values?
In my case, deployment name is the name of the first VM I created in this cloud service. So, if I added 3 machines to the same cloud service, all of them have the same deployment name - the name of the first machine.