Closed jpreese closed 4 years ago
Great that you're working on rolling this out! I haven't tried to re-evaluate if there's a more restrictive set of sources available recently, so I'm relying on Azure NSGs with source addresses of all the AzureCloud.<region>
(ie: AzureCloud.eastus
, AzureCloud.centralus
) service tags for my Atlantis VM's region, the US. That seems to work and is acceptable for now, obviously alongside TLS and basic auth.
Of course I'd prefer a much smaller set of something like what we have for hosted build agents.
We're running this in Kubernetes, but thats still in a VNET with an NSG. You're saying that the AzureCloud service tags include Azure DevOps? Because that would be pretty solid.
Yes, those service tags appear to work fine. We've been running this for about 6 months now with a small, mildly active team. I haven't noticed any service hook logs showing webhooks that timed out. I think I recall getting this notion from this section in the docs, following the geography comment. The AzureCloud tags seem to cover all the same IP ranges.
Ok awesome! I'll bring that up on this side of the fence and see if we can get these opened. Thanks again!
@mcdafydd One small bit of clarification as there seems to be some conflicting bits of information. In your implementation, did you have to create a Public IP
resource in order for Azure to talk to your Atlantis instance? Or is it possible to just have an Internal loadbalancer/NSG that allows the AzureCloud tag? The NSG Inbound/Outbound are getting painful to figure out.
Additionally, if you're into blogging, you should totally do a writeup of your implementation. There is no information out there about Atlantis + DevOps. I planned on doing one after our roll out, but I would read yours right this very second if it existed.
Hi @jpreese - Yes, you'll need a public IP for Azure Devops to find your Atlantis URL, and it will need to be resolvable in your Internet-facing DNS. For me, the path looked something like this:
Azure Devops webhook to https://<atlantis URL>:4141/events
-> Azure public IP
-> Multiple inbound allow NSG rules with
-> one source address service tag per rule for AzureCloud.westus and all the other United States regions
-> dest. port 4141/tcp
-> dest. internal vNet IP of Atlantis
So you could definitely use an Azure public load balancer for that.
I haven't done much looking into the outbound rules, but I see that dev.azure.com
resolves to 13.107.42.20
at the moment, and that does happen to match one of the documented public IPs here.
Another thing I might recommend is using something like an Nginx proxy or maybe https://github.com/pusher/oauth2_proxy to add authentication to the lock screen page. This was discussed on the Atlantis issues as well.
I haven't done much blogging, but I appreciate the suggestion! I may try to put one together.
Oh, and if you want to DM me, I setup a Twitter profile just for that purpose here:
Good luck!
@mcdafydd
Oh the joys of a lack of a direct messaging mechanism, hopefully this reaches you :)
You've obviously done a lot of work with Atlantis and Azure DevOps, are you familiar with the origin IP address for AzDO's service hooks? We're in the process of rolling out Atlantis for AzDO, but the instance is behind a firewall and there doesn't seem to be a whole lot of documentation on configuring networking to allow services to accept requests from AzDO.
Based on your original PR (https://github.com/runatlantis/atlantis/pull/719) -- I'm seeing
20.23.242.132
in the logs. This also seems to be consistent with some testing I did where I grabbed the source IP from a test connection.