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.
-
@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-WebRequest
Food for thought there... (emphasis added by me)
-
@David_CSG said in Ansible Agent Option?:
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.I don't know why everyone is so afraid to have a public facing service. Does anyone know about the internet?
It's simple to lock down hosts and keep them updated, especially with cfg mgmt tools. You can auto update security packages, disallow user login, force secure certificate login, block every single incoming port, use cloud firewalls that AWS and Azure provide for example in front, not to mention all of their other security services and tools, I mean it's insane what you can do.
There's a whole internet and cloud out there you use every day for web browsing and other services like voup, ERP, and so many other services that run in the cloud that are not hacked.
And typically the services are hacked via social engineering, not directly. I mean there are a lot of exceptions such as jimbobs doughnut shop WordPress website because he uses outdated plug-ins and hasn't updated for 15 years...
Get my point?