Ansible Agent Option?
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
I don't see SD-WANs as being LAN based. It's a way to span multiple networks. Especially if you don't treat it like a LAN. It's just enabling easier access to systems. Using one doesn't mean that you disable firewalls or treat that network any different than the internet, it's just a way for systems to see each other. I see it as a precursor to what IPV6 might be like once it's fully adopted.
If an SD-WAN like ZeroTier is simply the answer, that's okay. Not ideal, IMHO, but I know that that can work. The issue I see there is that there is a complexity or risk that has to be abated because it will tend to expose many networks that are usually isolated or are expected to be isolated. Of course, there are ways to limit the traffic to being nothing but Ansible, for example, but that's what I mean. You don't want to just use ZeroTier and do nothing else, as it will suddenly expose a lot of machines that were previously pretty well isolated by the nature of being off network from each other.
I think with (at least) ZT, you also have the fairly easy authentication as well. It's a plus or a minus depending how you look at it, but it's not like a LAN where someone can just jump on. You get essentially 802.1x out of the box but much easier.
If you do just have a central box to run the configuration management from, you can limit SSH access from that address. That's just as secure as normal pull methods with certs like Puppet. I know that's not the same as a message bus, but with the right sized keys and limiting where it's coming from it's just about there.
-
@stacksofplates said in Ansible Agent Option?:
If you do just have a central box to run the configuration management from, you can limit SSH access from that address. That's just as secure as normal pull methods with certs like Puppet. I know that's not the same as a message bus, but with the right sized keys and limiting where it's coming from it's just about there.
Locking down the clients to just be contacted by that one box is pretty easy. That part works well, in all the cases I am thinking of. It's the ad hoc port forwarding that becomes a problem.
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
What I've done in the past is have a ZT network for each client. That way they don't share a network.
Oh I figured that. But, as an example, one client we'd like to manage this way has something like 20% of computers on a LAN that are high priority and tightly controlled, and then 80% are on ad hoc networks (homes, cafes, hotels, etc.) We could do one server for the LAN and one for the "not LAN" to keep the LAN at least isolated from the "rabble." But it would be the exposure of all of the home users to each other would be the fear. Kind of like a Kindergarten classroom... all of the people most likely to be infected, all stuck together in the same place.
Fair enough, yeah you'd have to limit where the traffic comes from on that network.
A weird workaround for ansible-pull might be WSL. I haven't tried interacting over localhost with Windows using that.
-
@stacksofplates something I've not considered till just now, how much difference is there in bandwidth between the two approaches? Salt has the agent already on the end points, the bulk of communications is just the data. But Ansible pushed out a tiny client with each contact. Does that add up much?
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
If you do just have a central box to run the configuration management from, you can limit SSH access from that address. That's just as secure as normal pull methods with certs like Puppet. I know that's not the same as a message bus, but with the right sized keys and limiting where it's coming from it's just about there.
Locking down the clients to just be contacted by that one box is pretty easy. That part works well, in all the cases I am thinking of. It's the ad hoc port forwarding that becomes a problem.
You wouldn't need to though, at least with ZT. It handles NAT traversal natively.
-
@stacksofplates said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
If you do just have a central box to run the configuration management from, you can limit SSH access from that address. That's just as secure as normal pull methods with certs like Puppet. I know that's not the same as a message bus, but with the right sized keys and limiting where it's coming from it's just about there.
Locking down the clients to just be contacted by that one box is pretty easy. That part works well, in all the cases I am thinking of. It's the ad hoc port forwarding that becomes a problem.
You wouldn't need to though, at least with ZT. It handles NAT traversal natively.
Oh of course, if you add ZT, then it's mostly all moot.
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates something I've not considered till just now, how much difference is there in bandwidth between the two approaches? Salt has the agent already on the end points, the bulk of communications is just the data. But Ansible pushed out a tiny client with each contact. Does that add up much?
Depends if you use pipelining or not. There's also another tool called Mitogen that uses pure Python on the remote end. I've seen demos of some crazy speed increases, like literally 20-50x as fast. That said, I don't know how well or if at all it works with Windows.
-
-
Yeah this is their main docs and info: https://mitogen.networkgenomics.com/index.html
-
This is interesting. I unfortunately don't have the deep understanding of everyone contributing to this topic, but i'm taking it onboard as best I can.
I'd really throw effort into learning Ansible (at cursory glance it made more sense to me than Salt), if I could use it the manner I think @scottalanmiller is describing. I'm currently using different tools to wrangle our small fleet of devices into some sort of order. This is mostly MDM suite(s) and exploiting the Windows 10 PC options - but no server config management tools utilised as such (I have only a few, so return on potential time invested in Ansible, is very minimal).
JumpCloud has command runners for Linux, Windows and Mac..... I've been using it for Chocolatey and Powershell stuff on PCs (on and off LAN). There's an agent installed on your endpoint obviously.
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
What I've done in the past is have a ZT network for each client. That way they don't share a network.
Oh I figured that. But, as an example, one client we'd like to manage this way has something like 20% of computers on a LAN that are high priority and tightly controlled, and then 80% are on ad hoc networks (homes, cafes, hotels, etc.) We could do one server for the LAN and one for the "not LAN" to keep the LAN at least isolated from the "rabble." But it would be the exposure of all of the home users to each other would be the fear. Kind of like a Kindergarten classroom... all of the people most likely to be infected, all stuck together in the same place.
I don't see ZT as a solution to this, I see it as an unnecessary workaround.
So in this case, 80% are devices that need to be managed by an agent-based device management software (LANless). Otherwise, there's no way to contact them, as they'll not have known or public IP address... likely behind random unknown NAT.
All MDM solutions work this way, and true device management solutions... Jamf, Kace, Intune, even SaltStack can do it. Ansible clearly is not designed for for the kind of use environment you're asking about.
So short answer is no, use something better suited.
-
@Obsolesce said in Ansible Agent Option?:
I don't see ZT as a solution to this, I see it as an unnecessary workaround.
I don't see it that way. Agents were created when things like SD-WANs didn't exist. Now, all of you devices can connect easily no matter where they are. It's actually easier to implement paradigms like zero trust when the systems are connected that way.
-
@stacksofplates said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
I don't see ZT as a solution to this, I see it as an unnecessary workaround.
I don't see it that way. Agents were created when things like SD-WANs didn't exist. Now, all of you devices can connect easily no matter where they are. It's actually easier to implement paradigms like zero trust when the systems are connected that way.
You expect hundreds of different MSP clients or tenants to be "okay" with having ZeroTier installed on all of their devices? Potentially being a mistake away from being on the same LAN as everyone else or controlled by the same client management server everyone else is? No thanks. sorry but I don't trust that any MSPs single client management system is that secure, and don't want ZeroTier on evyerthing either. There are much better solutions and I'd question why others aren't being suggested instead.
-
@Obsolesce said in Ansible Agent Option?:
You expect hundreds of different MSP clients or tenants to be "okay" with having ZeroTier installed on all of their devices? Potentially being a mistake away from being on the same LAN as everyone else or controlled by the same client management server everyone else is? No thanks. sorry but I don't trust that any MSPs single client management system is that secure, and don't want ZeroTier on evyerthing either. There are much better solutions and I'd question why others aren't being suggested instead.
A. ZeroTier isn't the only SD-WAN software that exists so not sure why you're singling it out. B. Uh MSPs are famous for adding everyone to the same network that's not an SD-WAN, the customers obviously don't care and being joined to an SD-WAN. C. No one said there would be a single client management system? Not sure where that came from. D. This is somehow different than the MSP having 20 different application agents for each tool they want to run? E. The MSP is running scripts and controlling systems with elevated privileges. I think a single tun/tap device is the least of the customers worries.
With a zero trust model enabled concerns like these are negligent and it's pretty obvious if a customer is on the wrong network.
-
@stacksofplates said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
You expect hundreds of different MSP clients or tenants to be "okay" with having ZeroTier installed on all of their devices? Potentially being a mistake away from being on the same LAN as everyone else or controlled by the same client management server everyone else is? No thanks. sorry but I don't trust that any MSPs single client management system is that secure, and don't want ZeroTier on evyerthing either. There are much better solutions and I'd question why others aren't being suggested instead.
A. ZeroTier isn't the only SD-WAN software that exists so not sure why you're singling it out. B. Uh MSPs are famous for adding everyone to the same network that's not an SD-WAN, the customers obviously don't care and being joined to an SD-WAN. C. No one said there would be a single client management system? Not sure where that came from. D. This is somehow different than the MSP having 20 different application agents for each tool they want to run? E. The MSP is running scripts and controlling systems with elevated privileges. I think a single tun/tap device is the least of the customers worries.
With a zero trust model enabled concerns like these are negligent and it's pretty obvious if a customer is on the wrong network.
It comes down to the company being smart enough to hire an MSP that does it right is all. One ansible server for each tenant on their SD-Wan for example I would guess.
-
@Obsolesce said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
You expect hundreds of different MSP clients or tenants to be "okay" with having ZeroTier installed on all of their devices? Potentially being a mistake away from being on the same LAN as everyone else or controlled by the same client management server everyone else is? No thanks. sorry but I don't trust that any MSPs single client management system is that secure, and don't want ZeroTier on evyerthing either. There are much better solutions and I'd question why others aren't being suggested instead.
A. ZeroTier isn't the only SD-WAN software that exists so not sure why you're singling it out. B. Uh MSPs are famous for adding everyone to the same network that's not an SD-WAN, the customers obviously don't care and being joined to an SD-WAN. C. No one said there would be a single client management system? Not sure where that came from. D. This is somehow different than the MSP having 20 different application agents for each tool they want to run? E. The MSP is running scripts and controlling systems with elevated privileges. I think a single tun/tap device is the least of the customers worries.
With a zero trust model enabled concerns like these are negligent and it's pretty obvious if a customer is on the wrong network.
It comes down to the company being smart enough to hire an MSP that does it right is all. One ansible server for each tenant on their SD-Wan for example I would guess.
Right. It's no different if you have a single Salt master. If you're not keeping customers completely separate there is the possibility for bleeding between them.
-
@stacksofplates said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
I don't see ZT as a solution to this, I see it as an unnecessary workaround.
I don't see it that way. Agents were created when things like SD-WANs didn't exist. Now, all of you devices can connect easily no matter where they are. It's actually easier to implement paradigms like zero trust when the systems are connected that way.
Though, as Scott said earlier - using SD-WAN tech requires a lot more work to segregate the clients on that SD-WAN from each other.
With an agent - you don't worry about that at all. Instead you put all of your concern on the open port for the centralized server.
-
@Dashrender said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
I don't see ZT as a solution to this, I see it as an unnecessary workaround.
I don't see it that way. Agents were created when things like SD-WANs didn't exist. Now, all of you devices can connect easily no matter where they are. It's actually easier to implement paradigms like zero trust when the systems are connected that way.
Though, as Scott said earlier - using SD-WAN tech requires a lot more work to segregate the clients on that SD-WAN from each other.
With an agent - you don't worry about that at all. Instead you put all of your concern on the open port for the centralized server.
Yeah you do. You need to separate them by server. So you need a different master for each network. So you have multiple central servers that are each their own cert authority for the app.
-
@scottalanmiller Thanks very much for starting this discussion, and to everyone who has contributed. Very interested in this.
@scottalanmiller There is ANTS for Linux & macOS, https://github.com/ANTS-Framework/ants which uses an Ansible pull method.
- but for Windows that would mean adding Python (pip).
As far as my usage of Ansible is (or, will be) concerned, all workstations will be (are in the midst of being moved to) the latest build of Windows 10, where ssh(d) are supplied natively, and connections will be made via ssh. Again, primarily on the LAN where hostname resolution (given AD & Windows-provided DNS) is a solved problem.
So, my primary usage for Ansible will be (meaning I'm not there yet, gearing up while handling some other major projects on the go already) something primarily LAN-based. I do have RMM software I can leverage for Windows, but they (RMM & the world of such competing products, some with questionable security practices) all suck at some things, and what I'm using is ok but sucks in terms of being up to date (current and correct) at reporting patch status for Windows & 3rd-party apps.
I'm just thinking out loud here, but for remote units, perhaps a cloud-hosted VM, but... that means relying on something like "fail2ban" to block repeat offenders, hard to limit incoming connections in an ideal way. Some kind of scripted phone-home system ? On OS X this is easily accomplished (in response to detected network change) via something like crankd
Parse the originating IP out an email, temporarily allow ssh from said address...So, inordinately complex hackery to chase a less-than-ideal solution.
Generally, my thinking was - for when and where I want to leverage Ansible - a dedicated VM on each client (primary) network.
-
Thank-you !
https://hooks.technology/2017/08/ansible-tower-provisioning-callbacks/" or you can just use curl.
curl --data "host_config_key=d13a7b6e08e84c7d8f412b9754400a00"https://tower.example.com/api/v1/job_templates/26/callback/ -k
This has many benefits beyond just physical host provisioning. This allows systems to “check in” without using Ansible pull."Or, for Windows instead of curl, powerhsell
Invoke-WebRequestFood for thought there... (emphasis added by me)
