ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Ansible Agent Option?

    IT Discussion
    ansible
    11
    163
    17.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      scottalanmiller @Obsolesce
      last edited by

      @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...

      1. If you choose a good MSP, you aren't worried about the mistakes that aren't being made.
      2. If you choose a bad MSP, these decisions aren't going to be the problems.
      1 Reply Last reply Reply Quote 1
      • D
        Dashrender @stacksofplates
        last edited by

        @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.

        S 1 Reply Last reply Reply Quote 0
        • S
          scottalanmiller @Dashrender
          last edited by

          @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.

          1 Reply Last reply Reply Quote 0
          • S
            scottalanmiller @stacksofplates
            last edited by

            @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".

            S 1 Reply Last reply Reply Quote 0
            • S
              scottalanmiller @David_CSG
              last edited by

              @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.

              1 Reply Last reply Reply Quote 1
              • S
                scottalanmiller @Obsolesce
                last edited by

                @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.

                1 Reply Last reply Reply Quote 1
                • O
                  Obsolesce @scottalanmiller
                  last edited by

                  @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.

                  D S 2 Replies Last reply Reply Quote 0
                  • S
                    scottalanmiller @Dashrender
                    last edited by

                    @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".

                    D 1 Reply Last reply Reply Quote 0
                    • D
                      Dashrender @Obsolesce
                      last edited by

                      @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...

                      1 Reply Last reply Reply Quote 0
                      • S
                        scottalanmiller @Obsolesce
                        last edited by

                        @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 🙂

                        1 Reply Last reply Reply Quote 0
                        • D
                          Dashrender @scottalanmiller
                          last edited by

                          @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.

                          S 1 Reply Last reply Reply Quote 1
                          • matteo nunziatiM
                            matteo nunziati
                            last edited by

                            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....

                            1 Reply Last reply Reply Quote 0
                            • S
                              stacksofplates @scottalanmiller
                              last edited by

                              @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.

                              1 Reply Last reply Reply Quote 0
                              • S
                                stacksofplates @Dashrender
                                last edited by

                                @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.

                                S 1 Reply Last reply Reply Quote 0
                                • S
                                  scottalanmiller @stacksofplates
                                  last edited by

                                  @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.

                                  S 1 Reply Last reply Reply Quote 0
                                  • S
                                    stacksofplates @scottalanmiller
                                    last edited by stacksofplates

                                    @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.

                                    S 1 Reply Last reply Reply Quote 0
                                    • S
                                      scottalanmiller @stacksofplates
                                      last edited by

                                      @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.

                                      1 Reply Last reply Reply Quote 0
                                      • 1
                                      • 2
                                      • 3
                                      • 4
                                      • 5
                                      • 6
                                      • 7
                                      • 8
                                      • 9
                                      • 6 / 9
                                      • First post
                                        Last post