Ansible Agent Option?
-
@scottalanmiller said in Ansible Agent Option?:
From what I've seen Ansible has more momentum and support (IBM bought them now) and more robust Windows handling. So it would be great if I am just missing a way to add an agent to it. That it is agentless by default is great, it's that it would be wonderful if it had an optional agent (native or third party) that is currently supported.
From what I seen,it's a totally different ballpark from what those who would use Ansible want to do,from what those who manage user devices want to do. Ansible works wonders in the area environment it's designed for... managing configurations of server farms, cloud resources, DevOps solutions,etc. That is big and the area of MDM and just regular ass user device management is already covered by agent based software.i mean when you think about it, there's no other way. It makes sense. That SaltStack is like Ansible and also uses an agent puts it above imo,and why that d8dnt take off better than Ansible is beyond me. I don't mind an agent,and I love SaltStack because it works so much easier. But that the big companies are more supporting Ansible for some reason we need to know both until i guess they either switch to SS, or they create a real native Ansible agent if nothing else.
Intune is all the way there now once you learn how it works and why it works the way it does. The absolute worst case scenario is that you have to do something through a powershell script on a device the same way you would using SS. That's about it,otherwise it's a built in functionality of Intune either right in the web GUI or API. That it uses Graph API is fantastic imo. This here was in reference to another reply,but too lazy to split this and find it.
-
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
A simple test would be this.... if MDM is the right tool for your laptops, then it would also be the right tool for your servers.
Servers are not mobile devices.
Nor are Desktops but it would be nice to manage them with the same tool. Intune comes to mind it will do some state management and is getting better with time...
Intune only works because it's built to work that way. The operating systems and software that runs on them is built to work with intune so that the devices can be managed. Intune is (M)DM. Jamf is (M)DM. SaltStack, Ansible, etc is not device management. SaltStack has a big plus that it works well to manage devices due to the nature of agent based.
SaltStack and Ansible are basically the same. But Ansible lacks an agent so access is less secure and way more complicated. You can layer SDN onto Ansible to achieve it, ZeroTier for example, but that carries complexity and problems. The agent nature is so superior, by such a staggering degree. In theory you can build an Ansible agent, that shouldn't be that hard. The problem is that no one seems to have made and maintained one, it's just a theory that you could do, but beyond that, if someone made an agent it seems like it would be perfect.
I didn't read through everything yet but these kind of statements are ridiculous, so I'm hoping you're hyperbolizing.
lacks an agent so access is less secure
That's 100% false.
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"?
-
It's not necessarily built for that use case. I think Salt (with agents) is a step backwards when doing immutable infrastructure because you're tying things such as certificates to systems whereas with Ansible, I can build the image and either leave only SSH access if I need it, or completely disable SSH and deploy the servers from the template with no logins at all.
Each tool has it's own purpose. Ansible and Terraform overlap in areas, but that doesn't negate the fact that either should exist.
-
There are ways to do a remote trigger which is like an agent, but it still uses SSH. https://hooks.technology/2019/06/ansible-and-jenkins-remote-triggers/ https://hooks.technology/2017/08/ansible-tower-provisioning-callbacks/
Ansible is more of a distributed configuration management tool. It doesn't have to be run from a single source. You obviously can from either cli or tools like Tower/AWX, Jenkins, Rundeck, Semaphore, etc. However it's not limited to that. You can run it from your laptop and control the same systems from a central Ansible server also. You lose that ability with agents.
-
@Dashrender said in Ansible Agent Option?:
@DustinB3403 said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
Why not have an Ansible server on the same network as the devices and reachable by the Ansible server?
From an MSP perspective that can get pretty inefficient and heavy.
Why is an MSP wanting to manage client user Windows mobile devices with Ansible? That doesn't make much sense and not really what it's for.
Even not an MSP, why would anyone want to use anything but state machines for managing their machines?
This kinda sounds like you wanna run DeepFreeze on all machines, except for a small area of the disk the users are allowed to write to. that does actually sound awesome - as long as you can prevent execution of programs from that space.
DeepFreeze is a different concept, but could have overlapping use cases. DF is about preserving a single state. State machines are about defining and managing state, which is assumed that it will change (possibly often.)
By change often in the case of a laptop/desktop would be that you're updating software? so you want to make sure you always have the latest version? or are you meaning something else?
That's one option, but you could think of that as not being a state change "Up to date" might be a bits and bytes change, but not a state change (does that make sense?) Moreso what I mean is that a user or group might want machines tweaked with new software, different software, different settings, new mapped drives, whatever, on a regular basis.
Wow, you sound like you have groups that waste a lot of time moving people around, changing their needed access to have those types of things change on a regular basis.
That sounds completely normal to me. Literally daily activity and doesn't at all sound extreme or abnormal.
You have people who want different settings, new mapped drives, etc daily? I definitely don't... maybe it's a matter of company size.
I think the last 'new' software I deployed was Citrix-workspace.
When you have thousands of machines, absolutely there are changes daily.
-
@Dashrender said in Ansible Agent Option?:
@DustinB3403 said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@DustinB3403 said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
@coliver said in Ansible Agent Option?:
@Obsolesce said in Ansible Agent Option?:
Why not have an Ansible server on the same network as the devices and reachable by the Ansible server?
From an MSP perspective that can get pretty inefficient and heavy.
Why is an MSP wanting to manage client user Windows mobile devices with Ansible? That doesn't make much sense and not really what it's for.
Even not an MSP, why would anyone want to use anything but state machines for managing their machines?
This kinda sounds like you wanna run DeepFreeze on all machines, except for a small area of the disk the users are allowed to write to. that does actually sound awesome - as long as you can prevent execution of programs from that space.
DeepFreeze is a different concept, but could have overlapping use cases. DF is about preserving a single state. State machines are about defining and managing state, which is assumed that it will change (possibly often.)
By change often in the case of a laptop/desktop would be that you're updating software? so you want to make sure you always have the latest version? or are you meaning something else?
That's one option, but you could think of that as not being a state change "Up to date" might be a bits and bytes change, but not a state change (does that make sense?) Moreso what I mean is that a user or group might want machines tweaked with new software, different software, different settings, new mapped drives, whatever, on a regular basis.
Wow, you sound like you have groups that waste a lot of time moving people around, changing their needed access to have those types of things change on a regular basis.
That sounds completely normal to me. Literally daily activity and doesn't at all sound extreme or abnormal.
You have people who want different settings, new mapped drives, etc daily? I definitely don't... maybe it's a matter of company size.
I think the last 'new' software I deployed was Citrix-workspace.
I have people who need things changed daily, yes.
I suppose that fact itself has little or nothing to do with the actual tool discussion though. You could just as easily use GP to push those changes if needed, or any of thousands of other tools. My bad for tangenting from Scott's comment.
Those push changes, but don't verify changes. GP doesn't even begin to do what state machines do. Totally different animal.
-
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
We are, but I want to give Ansible a fair shake and am asking if or how anyone is getting it to overcome this agentless limitation for accessing other machines.
Then you will need to test them in a scenario that they both equally support, or take the limitation factor out of it.
That's pretty silly. You don't test suitability of tools by altering the test till both products are equal. You test in plausible test cases to determine which is better.
-
@Obsolesce said in Ansible Agent Option?:
Ansible works wonders in the area environment it's designed for... managing configurations of server farms, cloud resources, DevOps solutions,etc.
Why are those not ways to describe desktops? Desktops are a form of server (I've spoken on this) not a special care, they are just as much devops as a server (if treated as such), etc. Hence my point, when you don't think of a desktop as a special case, then suddenly the descriptions of intended use case match.
-
@stacksofplates said in Ansible Agent Option?:
lacks an agent so access is less secure
That's 100% false.
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 the agent bypasses many weaknesses in the Windows methodologies. You can, in theory, do a lot of work to get Ansible on Windows to be on par with Ansible on Linux for security, but it's rather a bit. To make it even passable you have a script so long it's almost an agent itself. But at the end of the day, it's trying hard to get close to the default security of the agent method.
-
@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?
