Ansible Agent Option?
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
454 lines, just to get Windows ready for access.
That's disingenuous. First, 58 lines of that or so are comments. Second, your template should be enabling WinRM. Third, if you're using kerberos, you don't need anything like that.
The template should be enabling it, yes. Assuming you are in a templatable situation (we rarely are as an MSP, it's almost never an option at all, no licensing for it), then yes it is a bit of complexity just one time and then it is just cloned. But when nearly all templates are unique, it's still a "do it every time" task.
That's fair if you don't have control over the template.
If you have Kerberos, but often you do not in the cases being discussed. Kerberos doesn't work very well LAN less, so in the cases where this matters, that wouldn't be there. And even those on a LAN, one of the specific benefits of the state machines is reducing the dependency on things like AD.
Kerberos doesn't imply AD. And as long as your kerberos server is accessible everywhere (some type of cloud infra or whatever) it's fine without being LAN based.
-
@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.
-
@stacksofplates said in Ansible Agent Option?:
Kerberos doesn't imply AD. And as long as your kerberos server is accessible everywhere (some type of cloud infra or whatever) it's fine without being LAN based.
Okay, that's a good thought.
-
@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?
-
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.
-
I've got loads of that exact scenario to deal with, so it's not me trying to find a hole, it's the machines we work the hardest to support currently.
-
@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.
-
@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.
-
