Opinions: Ansible vs. SaltStack
-
@AdamF said in Opinions: Ansible vs. SaltStack:
So this is now a super old post, but still relevant. I have been using Saltstack to manage my servers. I don't have any downsides to this so far, but I like to re-evaluate every so often. I see that Ansible open sourced (a couple years ago) their Tower GUI (AWX) That's attractive to me.
What are the current opinions on server management in regards to Ansible vs Saltstack.
I believe AWX is much better these days. I still don't like it as much as just using Jenkins. Jenkins gives you a ton of flexibility while still giving you an interface to take inputs or run jobs.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
essentially every company has some number of workloads like this and once you have one, you can only use agentless when you are willing to not manage everything, just some things. Agent based is essentially the only way to use one tool for all
That's understandable. So what about if you are not managing workstations, and you would only use this to manage server workloads in various data centers? Would your same thinking still apply?
-
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
essentially every company has some number of workloads like this and once you have one, you can only use agentless when you are willing to not manage everything, just some things. Agent based is essentially the only way to use one tool for all
That's understandable. So what about if you are not managing workstations, and you would only use this to manage server workloads in various data centers? Would your same thinking still apply?
Depends, is every server open to the Internet and/or on a LAN that you have access to? Mine are not, I have a lot of servers that are like databases and are not accessible from the outside whatsoever. Salt works great and they are super secure. I can do loads of port forwarding and whatnot for Ansible and make it work as their IPs don't change, but it's a huge pain.
And what if you use any kind of scaling, combined with that kind of security, now you have to automate port forwarding and firewall rules, combined with the VMs, in real time, or you get management errors with the wrong stuff going to the wrong server.
Agents are just so much better IMHO in the real world. Not that that one factor means everything, but all other things being equal, I always want the agent.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
essentially every company has some number of workloads like this and once you have one, you can only use agentless when you are willing to not manage everything, just some things. Agent based is essentially the only way to use one tool for all
That's understandable. So what about if you are not managing workstations, and you would only use this to manage server workloads in various data centers? Would your same thinking still apply?
Depends, is every server open to the Internet and/or on a LAN that you have access to? Mine are not, I have a lot of servers that are like databases and are not accessible from the outside whatsoever. Salt works great and they are super secure. I can do loads of port forwarding and whatnot for Ansible and make it work as their IPs don't change, but it's a huge pain.
And what if you use any kind of scaling, combined with that kind of security, now you have to automate port forwarding and firewall rules, combined with the VMs, in real time, or you get management errors with the wrong stuff going to the wrong server.
Agents are just so much better IMHO in the real world. Not that that one factor means everything, but all other things being equal, I always want the agent.
That's fair. With Salt, on your salt master, do you rely on the keys for authentication, or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
essentially every company has some number of workloads like this and once you have one, you can only use agentless when you are willing to not manage everything, just some things. Agent based is essentially the only way to use one tool for all
That's understandable. So what about if you are not managing workstations, and you would only use this to manage server workloads in various data centers? Would your same thinking still apply?
Depends, is every server open to the Internet and/or on a LAN that you have access to? Mine are not, I have a lot of servers that are like databases and are not accessible from the outside whatsoever. Salt works great and they are super secure. I can do loads of port forwarding and whatnot for Ansible and make it work as their IPs don't change, but it's a huge pain.
And what if you use any kind of scaling, combined with that kind of security, now you have to automate port forwarding and firewall rules, combined with the VMs, in real time, or you get management errors with the wrong stuff going to the wrong server.
Agents are just so much better IMHO in the real world. Not that that one factor means everything, but all other things being equal, I always want the agent.
Also, is the new Salt Gui that you are talking about open source?
-
@AdamF said in Opinions: Ansible vs. SaltStack:
Also, is the new Salt Gui that you are talking about open source?
Yes
-
What is it called?
-
@AdamF said in Opinions: Ansible vs. SaltStack:
What is it called?
I have no memory of it, lol, but there's a thread around here about it. It's focused as an RMM, but Salt under the hood. Very cool idea. It's a lot of where SodiumSuite was going.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
What is it called?
I have no memory of it, lol, but there's a thread around here about it. It's focused as an RMM, but Salt under the hood. Very cool idea. It's a lot of where SodiumSuite was going.
Tactical RMM - Targetted as an RMM for Windows, includes Mesh Central, saltstack, a custom python agent, Django backend, Vue frontend.
UYUNI - OpenSuse Leap 15.2 based, but manages SUSE Linux Enterprise, openSUSE, Red Hat Enterprise Linux, CentOS, Oracle Linux and Ubuntu client systems. This is since 2018 the upstream project for SUSE Manager.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
What is it called?
I have no memory of it, lol, but there's a thread around here about it. It's focused as an RMM, but Salt under the hood. Very cool idea. It's a lot of where SodiumSuite was going.
There seem to be a bunch, in addition to the official paid-for thing they have now, and what @Romo listed.
https://github.com/erwindon/SaltGUI
https://speakerdeck.com/lothiraldan/saltpad-a-saltstack-web-gui -
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
-
@AdamF said in Opinions: Ansible vs. SaltStack:
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
That was over a week ago, lol.
-
@Romo said in Opinions: Ansible vs. SaltStack:
Tactical RMM - Targetted as an RMM for Windows, includes Mesh Central, saltstack, a custom python agent, Django backend, Vue frontend.
That's the one that I was thinking of.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
That was over a week ago, lol.
Ha! Just saw it this AM. Does this give you any concern with the future of the open source version of Salt?
-
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
That was over a week ago, lol.
Ha! Just saw it this AM. Does this give you any concern with the future of the open source version of Salt?
No, VMware has little interest in upsetting the balance of things. This kind of tool is already universally open source. Closed source only makes sense when you can dominate the field until some open source option takes over. Open source already owns this field.
Close sourcing an existing product is very hard to do, because you risk that someone else will fork it and keep it open and make your version irrelevant leaving you with literally nothing for the money that you spent.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
Whoa! VM Ware just acquired Saltstack. https://blogs.vmware.com/management/2020/10/vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation.html?utm_source=rss&utm_medium=rss&utm_campaign=vmware-completes-saltstack-acquisition-to-bolster-software-configuration-management-and-infrastructure-automation
I wonder what that means moving forward....
That was over a week ago, lol.
Ha! Just saw it this AM. Does this give you any concern with the future of the open source version of Salt?
No, VMware has little interest in upsetting the balance of things. This kind of tool is already universally open source. Closed source only makes sense when you can dominate the field until some open source option takes over. Open source already owns this field.
Close sourcing an existing product is very hard to do, because you risk that someone else will fork it and keep it open and make your version irrelevant leaving you with literally nothing for the money that you spent.
Makes sense. From yesterday: With Salt, on your salt master, do you rely on the keys for authentication, or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
-
@AdamF said in Opinions: Ansible vs. SaltStack:
Makes sense. From yesterday: With Salt, on your salt master, do you rely on the keys for authentication,
Yes, that's standard.
-
@AdamF said in Opinions: Ansible vs. SaltStack:
or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
No, this would make the agents pointless. Because they'd be unable to obtain a new address and keep working. This wouldn't just make mobile points not work, it would make any site without static IPs a problem, which is almost all of them today.
-
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
No, this would make the agents pointless. Because they'd be unable to obtain a new address and keep working. This wouldn't just make mobile points not work, it would make any site without static IPs a problem, which is almost all of them today.
So the only reason I brought this up, is because of a big vulnerability with SS a few months back. (https://www.helpnetsecurity.com/2020/05/04/saltstack-salt-vulnerabilities/) Specifically the section in the article that states:
“Adding network security controls that restrict access to the salt master (ports 4505 and 4506 being the defaults) to known minions, or at least block the wider Internet, would also be prudent as the authentication and authorization controls provided by Salt are not currently robust enough to be exposed to hostile networks,” the researchers added.
Now of course, an up to date master avoided this altogether, but still.
-
@AdamF said in Opinions: Ansible vs. SaltStack:
@scottalanmiller said in Opinions: Ansible vs. SaltStack:
@AdamF said in Opinions: Ansible vs. SaltStack:
or do you also lock down your firewall to only allow ports 4505:4506 FROM your minion IPs?
No, this would make the agents pointless. Because they'd be unable to obtain a new address and keep working. This wouldn't just make mobile points not work, it would make any site without static IPs a problem, which is almost all of them today.
So the only reason I brought this up, is because of a big vulnerability with SS a few months back. (https://www.helpnetsecurity.com/2020/05/04/saltstack-salt-vulnerabilities/) Specifically the section in the article that states:
“Adding network security controls that restrict access to the salt master (ports 4505 and 4506 being the defaults) to known minions, or at least block the wider Internet, would also be prudent as the authentication and authorization controls provided by Salt are not currently robust enough to be exposed to hostile networks,” the researchers added.
Now of course, an up to date master avoided this altogether, but still.
Yup, it's a risk for sure. As long as you connect servers to clients, somewhere there has to be a point of exposure, and that's a risk.