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.
-
@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.
-
@stacksofplates said in Ansible Agent Option?:
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.
Yes, LAN-like tools are only LAN-like if you treat them in that fashion. The behaviour is rarely intrinsic.
