Ansible Agent Option?
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
I already posted where we don't have it stored on a server. If I'm running from a laptop that's separate from everything else with no ports open, the laptop isn't "exposed" at all. And if you run from build boxes with no ports open like I described, it's the same scenario.
Right, but like I said, those are contrived cases that are different than the intention of the platforms to be used for ongoing maintenance, unless I am missing something. How do you make changes to the laptop, without logging in, and monitor that the state is returning correct? Where does the data go? How does it get the changes?
Huh? I'm talking about the Ansible "server". Everything is stored in git. The build boxes pull in the code changes at run time and set up the virtual environment. They run Ansible which has the changes from the new git pull and it does all of the work. The clients aren't immutable in this case.
So walk me through this, because this is the common scenario that seems to be the biggest stumbling block and is pretty simple, so if it works here, it basically works everywhere.
Scenario
Laptop is built in the office using any tools you want, Clonezilla and Ansible on the LAN? Sure, that's fine. It's base image and config are just great. Laptop runs Windows.
User takes laptop home. They do not have a static IP, they do not have port forwarding. The laptop now stays "forever" on a foreign network without "outside in" access. The user needs configuration changes made, new software or whatever.
While at home, behind the firewall, how does that laptop get told of the new configuration and how does it report back to the central Ansible server to let it know that things succeeded or failed?
Ok, I see where the hangup is. I was specifically describing how there isn't a security issue with the Ansible "server" for us because it's short lived and always changes boxes. That's why I brought that process up, not to directly deal with remote systems. I was specifically referencing that our controlling servers are short lived and then wiped so we don't have a machine that can access everything running all of the time.
-
@stacksofplates said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
I already posted where we don't have it stored on a server. If I'm running from a laptop that's separate from everything else with no ports open, the laptop isn't "exposed" at all. And if you run from build boxes with no ports open like I described, it's the same scenario.
Right, but like I said, those are contrived cases that are different than the intention of the platforms to be used for ongoing maintenance, unless I am missing something. How do you make changes to the laptop, without logging in, and monitor that the state is returning correct? Where does the data go? How does it get the changes?
Huh? I'm talking about the Ansible "server". Everything is stored in git. The build boxes pull in the code changes at run time and set up the virtual environment. They run Ansible which has the changes from the new git pull and it does all of the work. The clients aren't immutable in this case.
So walk me through this, because this is the common scenario that seems to be the biggest stumbling block and is pretty simple, so if it works here, it basically works everywhere.
Scenario
Laptop is built in the office using any tools you want, Clonezilla and Ansible on the LAN? Sure, that's fine. It's base image and config are just great. Laptop runs Windows.
User takes laptop home. They do not have a static IP, they do not have port forwarding. The laptop now stays "forever" on a foreign network without "outside in" access. The user needs configuration changes made, new software or whatever.
While at home, behind the firewall, how does that laptop get told of the new configuration and how does it report back to the central Ansible server to let it know that things succeeded or failed?
Ok, I see where the hangup is. I was specifically describing how there isn't a security issue with the Ansible "server" for us because it's short lived and always changes boxes. That's why I brought that process up, not to directly deal with remote systems. I was specifically referencing that our controlling servers are short lived and then wiped so we don't have a machine that can access everything running all of the time.
I see, that makes a lot more sense. For us, at least this is how we envision the process, we would have central server(s) that are communicating constantly with the client machines. Hourly, daily, whatever. But too often to make sense being offline most of the time. People might make changes at almost any time to push out right away.
-
@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.
Yeah this is the only way I know of to deal with it. I mean you can do bastion hosts but that's impossible to control at peoples homes, etc.
What I've done in the past is have a ZT network for each client. That way they don't share a network. Then I had an Ansible role to set up ZT on each system I wanted to be able to control. Since I have all of my stuff in roles, I can replicate environments easily. You treat the roles like libraries or functions, and just plug client/site/whatever specific data into the role with your playbook. So the only thing you really change is the variables for each client.
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
I already posted where we don't have it stored on a server. If I'm running from a laptop that's separate from everything else with no ports open, the laptop isn't "exposed" at all. And if you run from build boxes with no ports open like I described, it's the same scenario.
Right, but like I said, those are contrived cases that are different than the intention of the platforms to be used for ongoing maintenance, unless I am missing something. How do you make changes to the laptop, without logging in, and monitor that the state is returning correct? Where does the data go? How does it get the changes?
Huh? I'm talking about the Ansible "server". Everything is stored in git. The build boxes pull in the code changes at run time and set up the virtual environment. They run Ansible which has the changes from the new git pull and it does all of the work. The clients aren't immutable in this case.
So walk me through this, because this is the common scenario that seems to be the biggest stumbling block and is pretty simple, so if it works here, it basically works everywhere.
Scenario
Laptop is built in the office using any tools you want, Clonezilla and Ansible on the LAN? Sure, that's fine. It's base image and config are just great. Laptop runs Windows.
User takes laptop home. They do not have a static IP, they do not have port forwarding. The laptop now stays "forever" on a foreign network without "outside in" access. The user needs configuration changes made, new software or whatever.
While at home, behind the firewall, how does that laptop get told of the new configuration and how does it report back to the central Ansible server to let it know that things succeeded or failed?
Ok, I see where the hangup is. I was specifically describing how there isn't a security issue with the Ansible "server" for us because it's short lived and always changes boxes. That's why I brought that process up, not to directly deal with remote systems. I was specifically referencing that our controlling servers are short lived and then wiped so we don't have a machine that can access everything running all of the time.
I see, that makes a lot more sense. For us, at least this is how we envision the process, we would have central server(s) that are communicating constantly with the client machines. Hourly, daily, whatever. But too often to make sense being offline most of the time. People might make changes at almost any time to push out right away.
I mean any time I make a code change it's either pulled down and run based off of the push or it's able to be run right away by clicking a button. But the clients are for all intents and purposes always on. They're just VMs that we are controlling so it is a different scenario.
-
@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.
-
@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.
