Ansible Agent Option?
-
@scottalanmiller said in Ansible Agent Option?:
It requires ports be open and exposed. At least for the central management way to use it, which is the "understood" use case. Exposed ports can be locked down, and nothing is perfect, but the degree to which port exposure is more risk than not port exposure is real. The agent provides an additional layer of security.
And you have this exact same thing with Salt. Except in the case of Salt, it's on the server that holds the keys to the kingdom. So it's a one stop shop to get to literally everything.
With Ansible, the controller(s) need 0 ports open. So each individual client (or whatever you want to call them) has to be attacked individually. All of this excluding immutable infra of course where you disable SSH after the template is built.
-
And to take it one step further, one thing we do for certain use cases is not even have Ansible installed on the build box. I wrote about it here: https://hooks.technology/2019/06/transient-playbooks-for-ansible/, but for brevity, the pipeline builds a virtualenv and installs Ansible there. Then we use Ansible to generate playbooks, inventory, group_vars, etc used by Ansible to do specific jobs, and then that environment is wiped away. Now, this was a specific case to allow people who don't know how to really use Ansible use it to deploy specific applications with specific configurations, but the code and credentials are only on the system for a very short time.
-
@stacksofplates said in Ansible Agent Option?:
The agent nature is so superior, by such a staggering degree.
This is also 100% false.
but that carries complexity and problems
Care to explain the "complexity" or "problems"?
Absolutely. Here is the first example, how to prep Windows to even work with Ansible, and this is just to get a baseline that isn't recommended due to it using stored passwords rather than something more complex:
https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
454 lines, just to get Windows ready for access. And yes it works, pretty nicely. But now we have to go secure it, machine by machine, additionally. Now, true, you can make Ansible itself do that extra work once it connects, and that would be the plan. But that you need 454 lines to get basic access, and then need more work to lock it down, it's a lot of "complexity" and "problems" right out of the gate.
Now once we've done that, in order to be accessed by the Ansible server we either need a static IP or we need some form of updating DNS so that the server can find it. We need a static IP and/or the DNS entry for every device that we want to access. If we are behind a firewall, we need port forwarding. If using dynamic addresses or rapidly changing ones, we can easily have situations where the device cannot be reached even though it is online. Lots of port forwarding, or address handling, or static IPs just for Ansible is a lot of complexity. And it adds potential risk, especially port forwarding.
Most shops, I would assume, tackle this by falling back to legacy "LAN based" infrastructures and simply abandoning Ansible for devices that don't fit the model. Unless most shops don't see this as a hurtle and somehow are using Ansible for remote users, regularly moving devices, those behind NAT, etc. then I would say that the market has agreed that the complexity and problems are great enough that they simply don't use the tool (in those cases.)
How many shops are not depending on LAN centric thinking and not avoiding using the tool universally? My guess is that that alone demonstrates my point. Adoption, it would seem, must be missing completely in those areas. Much of this thread is talking about how "it just isn't meant for that", and those statements are just another way of those people claiming that it has complexity and problems that aren't worth surmounting.
-
@stacksofplates said in Ansible Agent Option?:
All of this excluding immutable infra of course where you disable SSH after the template is built.
Yes, all of the options are pretty equally secure if you take them offline after completion. Assumption being that we need ongoing support and configuration through the tool.
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
All of this excluding immutable infra of course where you disable SSH after the template is built.
Yes, all of the options are pretty equally secure if you take them offline after completion. Assumption being that we need ongoing support and configuration through the tool.
You still have that. That's the point of immutable infrastructure. You rebuild the template with your CM tool and redeploy.
-
@stacksofplates said in Ansible Agent Option?:
And you have this exact same thing with Salt. Except in the case of Salt, it's on the server that holds the keys to the kingdom. So it's a one stop shop to get to literally everything.
Salt allows me to run the Salt Minion without a server. Doesn't suit my purposes, but the option exists and could work for us, but isn't as robust as we would like, but is extremely secure. There is no Master, and all Salt clients (including Windows and Mac) still work, with nothing else. AFAIK, Ansible cannot do this outside of UNIX machines? Am I wrong there?
When using Ansible as the Ansible team describes in their demos and papers, it uses a central server for management the same as Salt. The difference seems to be, however, that you can attack the clients OR the server, because both are exposed. The same "keys to the kingdom", but also separate keys to each individual "estate". Sure, you could in theory take the server to inaccessible, but then it can't really be used for configuration as you can't access it for changes. Unless, and this seems to make sense, that you would do so via Git updates and otherwise it is self managing?
-
@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.
-
@stacksofplates said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
All of this excluding immutable infra of course where you disable SSH after the template is built.
Yes, all of the options are pretty equally secure if you take them offline after completion. Assumption being that we need ongoing support and configuration through the tool.
You still have that. That's the point of immutable infrastructure. You rebuild the template with your CM tool and redeploy.
Agreed. Immutable seems, at least today, a bit silly for most use cases we would consider. An example that I am working on (that is great for Ansible so ignore it in the general case, not what I'm discussing broadly) is all desktops and AD servers. All things not well suitable to immutability. Possible, but awkward.
-
@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.
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.
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
And you have this exact same thing with Salt. Except in the case of Salt, it's on the server that holds the keys to the kingdom. So it's a one stop shop to get to literally everything.
Salt allows me to run the Salt Minion without a server. Doesn't suit my purposes, but the option exists and could work for us, but isn't as robust as we would like, but is extremely secure. There is no Master, and all Salt clients (including Windows and Mac) still work, with nothing else. AFAIK, Ansible cannot do this outside of UNIX machines? Am I wrong there?
When using Ansible as the Ansible team describes in their demos and papers, it uses a central server for management the same as Salt.
It's still a distributed system. It's like Git, by design it's distributed, but you can still use a central server like GitHub, GitLab, etc.
The difference seems to be, however, that you can attack the clients OR the server, because both are exposed. The same "keys to the kingdom", but also separate keys to each individual "estate". Sure, you could in theory take the server to inaccessible, but then it can't really be used for configuration as you can't access it for changes. Unless, and this seems to make sense, that you would do so via Git updates and otherwise it is self managing?
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.
-
@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?
-
@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.
