Ansible Agent Option?
-
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-WebRequestFood 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?
-
@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.
Or, in some cases, at least in theory, the agents are actually just a dedicated, purpose built SD-WAN. Or a glorified one. In a way, ZT could be seen as the agent. Sort of.
-
@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?
If they were okay with an agent, yes. I would.
@Obsolesce said in Ansible Agent Option?:
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?
IT is always "a mistake away from disaster", that's the nature of IT. ZT or an SD-WAN itself is not the problem there. Any agent, including a backup agent, or any remote access, like SSH or WinRM, is always a mistake away from similar disaster.
-
@Obsolesce said in Ansible Agent Option?:
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, and if you think of it that way...
- If you choose a good MSP, you aren't worried about the mistakes that aren't being made.
- If you choose a bad MSP, these decisions aren't going to be the problems.
-
@stacksofplates said in Ansible Agent Option?:
@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.
OK, that's still likely easier to manage and deal with compared to the setup and config of the SD-WAN stuff.
and in a case like Scott's - I'm guessing he's just spinning up new VMs on his Scale - or someplace like Vultr.
-
@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.
Yes, at least with SaltStack's agent approach, we get a very easy deployment and setup protocol.
-
@stacksofplates said in Ansible Agent Option?:
@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.
You can definitely do that, but that's upping the complexity each time. Not that spinning up any of these tools (SS, Ansible, Chef, Puppet) in a LXC container with low resources isn't easy and easily repeatable, you can make that pretty low overhead. But definitely more complexity than a single "master pool".
-
@David_CSG said in Ansible Agent Option?:
@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).
Cool, will look into that. Adding Python isn't "ideal" but isn't bad at all. Chocolatey handles that, and anything that easy I consider a non-issue. We do that for SaltStack anyway.
-
@Obsolesce said in Ansible Agent Option?:
I don't know why everyone is so afraid to have a public facing service. Does anyone know about the internet?
I tend to be more okay with this than most, the issues we have are not servers with public IPs, but those behind NAT where port forwarding would be somewhere between problematic or impossible.
-
@scottalanmiller 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.
Or, in some cases, at least in theory, the agents are actually just a dedicated, purpose built SD-WAN. Or a glorified one. In a way, ZT could be seen as the agent. Sort of.
Same could then be said about a web browser or anything that reaches out from in the computer basically.
-
@Dashrender said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@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.
OK, that's still likely easier to manage and deal with compared to the setup and config of the SD-WAN stuff.
and in a case like Scott's - I'm guessing he's just spinning up new VMs on his Scale - or someplace like Vultr.
He's saying you do one SD-WAN + one Master (or two) per network / customer. So still an SD-WAN, but no risk of "bleed over".
-
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller 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.
Or, in some cases, at least in theory, the agents are actually just a dedicated, purpose built SD-WAN. Or a glorified one. In a way, ZT could be seen as the agent. Sort of.
Same could then be said about a web browser or anything that reaches out from in the computer basically.
That seemed like what the guy was saying earlier - our company had 18 agents installed...
-
@Obsolesce said in Ansible Agent Option?:
@scottalanmiller 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.
Or, in some cases, at least in theory, the agents are actually just a dedicated, purpose built SD-WAN. Or a glorified one. In a way, ZT could be seen as the agent. Sort of.
Same could then be said about a web browser or anything that reaches out from in the computer basically.
And sometimes is
-
@scottalanmiller said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@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.
OK, that's still likely easier to manage and deal with compared to the setup and config of the SD-WAN stuff.
and in a case like Scott's - I'm guessing he's just spinning up new VMs on his Scale - or someplace like Vultr.
He's saying you do one SD-WAN + one Master (or two) per network / customer. So still an SD-WAN, but no risk of "bleed over".
Yes I get that - but managing that SD-WAN is still more work than managing the agent on each end device. As you mentioned before, you have to setup the firewalls, etc on each endpoint with SD-WAN, not something you have to worry about (in this context) for the agent.
-
Unfortunately ansible is a push system. Even pull scripts are workaround which require more time.to be setup than anything else. And often they apply configs at cron intervals....
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@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.
You can definitely do that, but that's upping the complexity each time. Not that spinning up any of these tools (SS, Ansible, Chef, Puppet) in a LXC container with low resources isn't easy and easily repeatable, you can make that pretty low overhead. But definitely more complexity than a single "master pool".
Right but you have a single system tied to each network which is what you said earlier that you specifically didn't want.
-
@Dashrender said in Ansible Agent Option?:
@scottalanmiller said in Ansible Agent Option?:
@Dashrender said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
@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.
OK, that's still likely easier to manage and deal with compared to the setup and config of the SD-WAN stuff.
and in a case like Scott's - I'm guessing he's just spinning up new VMs on his Scale - or someplace like Vultr.
He's saying you do one SD-WAN + one Master (or two) per network / customer. So still an SD-WAN, but no risk of "bleed over".
Yes I get that - but managing that SD-WAN is still more work than managing the agent on each end device. As you mentioned before, you have to setup the firewalls, etc on each endpoint with SD-WAN, not something you have to worry about (in this context) for the agent.
I don't really see it that way but we aren't going to agree on everything. The firewalls need set up regardless, and it would be automated through whatever your tool is.
You need one "agent" which is the SD-WAN client and that's it. The other way you will have most likely more than that because you will want some time of minor logging, monitoring, remote support like RDP, etc. I mean it solves a lot of things with just one client.
-
@stacksofplates said in Ansible Agent Option?:
You need one "agent" which is the SD-WAN client and that's it. The other way you will have most likely more than that because you will want some time of minor logging, monitoring, remote support like RDP, etc.
Most of that traffic is outbound, though. In theory, with something like Salt, you can have zero inbound ports for IT. Sure, applications might need something, but there will never be a way around that. But no additional ports opened for IT use. Or if there is, they can be opened ad hoc and closed as soon as they are not used.
-
@scottalanmiller said in Ansible Agent Option?:
@stacksofplates said in Ansible Agent Option?:
You need one "agent" which is the SD-WAN client and that's it. The other way you will have most likely more than that because you will want some time of minor logging, monitoring, remote support like RDP, etc.
Most of that traffic is outbound, though. In theory, with something like Salt, you can have zero inbound ports for IT. Sure, applications might need something, but there will never be a way around that. But no additional ports opened for IT use. Or if there is, they can be opened ad hoc and closed as soon as they are not used.
A lot are, but a lot of new ones aren't. Monitoring tools like Prometheus scrape clients and logging tools like Loki scrape logs in a similar way.
My point is I think it's much easier to take the 10 minutes to write the automation to set the client up the way you want and only allow access on that network from where you define. Then it doesn't matter what tool you decide to use. And when new ones come out or old ones are deprecated it's much easier to adapt.
Yeah it's obviously bad to treat it like a LAN but if you stop using tools just because it can be treated that way you are sometimes stopping yourself from doing some really interesting and helpful things.
Not aimed at you, just a point in general.
