RHEL 7.4 is out! That means we can now be public on how Ansible is shipping as part of the rhel-7-server-extras-rpms channel: https://access.redhat.com/downloads/content/ansible/2.3.1.0-3.el7/noarch/fd4...
Now that we can ensure every RHEL install has access to Ansible, is it time to remove the bash scripts?
The original premise of bash script inclusion was "bash is everywhere RHEL is" ..... and now Ansible carries the same truth.
Potential downside for discussion: Ansible binaries ship in the extras channel versus the core rhel-7-server (or whatever it's called). Will users mind enabling the extras channel?
I say we keep bash scripts as other distros will probably need them. Plus, I would think that we would want to handle environments where ansible will never be used.
On Tue, Aug 1, 2017 at 5:20 PM, Shawn Wells shawn@redhat.com wrote:
RHEL 7.4 is out! That means we can now be public on how Ansible is shipping as part of the rhel-7-server-extras-rpms channel: https://access.redhat.com/downloads/content/ansible/2.3. 1.0-3.el7/noarch/fd431d51/package
Now that we can ensure every RHEL install has access to Ansible, is it time to remove the bash scripts?
The original premise of bash script inclusion was "bash is everywhere RHEL is" ..... and now Ansible carries the same truth.
Potential downside for discussion: Ansible binaries ship in the extras channel versus the core rhel-7-server (or whatever it's called). Will users mind enabling the extras channel?
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
On 8/1/17 7:25 PM, Gabe Alford wrote:
I say we keep bash scripts as other distros will probably need them. Plus, I would think that we would want to handle environments where ansible will never be used.
Psh.... what other Linux distros? =P
You're totally right. And that definitely means we need to continue carrying bash remediations.
We discussed this idea internally as well, and we came up with the following reasons to not go further with it:
- why remove something we already have? there is no harm in keeping it - ansible is problematic on rhel6 due to python version - --remediate would stop working - bash is mentioned in the XCCDF spec, ansible @system is something we made up - in RHEL8 we could have ansible as default system for remediation
----- Original Message ----- From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Wednesday, August 2, 2017 1:40:18 AM Subject: Re: Time to drop bash remediations?
On 8/1/17 7:25 PM, Gabe Alford wrote:
I say we keep bash scripts as other distros will probably need them. Plus, I would think that we would want to handle environments where ansible will never be used.
Psh.... what other Linux distros? =P
You're totally right. And that definitely means we need to continue carrying bash remediations. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
There are a few other considerations that I would like to mention.
1) Ansible is **NOT** agentless. It needs SSH to be an agent. SSH should not be a requirement for a functional system since, in many production use cases, it is an unnecessary service. And, being an unnecessary service, per policy, SSH should not be running.
2) Ansible local is fine and can be run through many means, but as mentioned by Wesley, RHEL6 isn't much fun.
3) Having any account that has the power that Ansible requires should be isolated away from the rest of your production environment. IIRC, we discourage users from running privileged commands as root without explicit sets of sudo rules in place to constrain them. In theory, all sets of Ansible playbooks should come with an associated set of 'sudo' rules to be installed on the system. Additionally, use of Ansible should be constrained to a bastion that restricts users from running in parallel so that auditing is solid. Perhaps this could be a set of dynamically created containers that churn out independent audits?
Anyway, omnipotent SSH accounts were always up for tight scrutiny and there really needs to be an addition to the SSG targeting Ansible as part of the Red Hat stack since it's fundamentally just SSH in a loop.
Thanks,
Trevor
On Thu, Aug 3, 2017 at 7:27 AM, Wesley Ceraso Prudencio <wcerasop@redhat.com
wrote:
We discussed this idea internally as well, and we came up with the following reasons to not go further with it:
- why remove something we already have? there is no harm in keeping it
- ansible is problematic on rhel6 due to python version
- --remediate would stop working
- bash is mentioned in the XCCDF spec, ansible @system is something we
made up
- in RHEL8 we could have ansible as default system for remediation
----- Original Message ----- From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Wednesday, August 2, 2017 1:40:18 AM Subject: Re: Time to drop bash remediations?
On 8/1/17 7:25 PM, Gabe Alford wrote:
I say we keep bash scripts as other distros will probably need them. Plus, I would think that we would want to handle environments where ansible will never be used.
Psh.... what other Linux distros? =P
You're totally right. And that definitely means we need to continue carrying bash remediations. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
I'm probably missing the point here, but I don't understand. Ansible is agentless and doesn't require anything to run plays/tasks on a remote system other than an ssh connection/account and the proper privileges for that account. At the end of the day, it may end up running a command line via the "shell" module anyway, so what's the point?
What does ansible being available have anything to do with remediation of the target system? You only install ansible on the control system, not the target usually unless you're using the pull mechanism? I think it would be nice to have ansible plays that can do the remediation, but you can do that without having ansible installed on the target system...
?? confused ??
On 08/01/2017 04:20 PM, Shawn Wells wrote:
RHEL 7.4 is out! That means we can now be public on how Ansible is shipping as part of the rhel-7-server-extras-rpms channel: https://access.redhat.com/downloads/content/ansible/2.3.1.0-3.el7/noarch/fd4...
Now that we can ensure every RHEL install has access to Ansible, is it time to remove the bash scripts?
The original premise of bash script inclusion was "bash is everywhere RHEL is" ..... and now Ansible carries the same truth.
Potential downside for discussion: Ansible binaries ship in the extras channel versus the core rhel-7-server (or whatever it's called). Will users mind enabling the extras channel?
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
You can run Ansible playbooks locally without a server. Your describing a normal Ansible deployment, but if the Ansible package is installed on a local system, you don't need an external system.
Shawn... is your vision that Ansible would be a dependency for SSG remediations? I don't have an issue with that at all, but I'm just trying to think through how it would work when applying security policies during installation.
Tom A.
Sent from my iPhone
On Aug 1, 2017, at 7:32 PM, Bond Masuda bond.masuda@hexadiam.com wrote:
I'm probably missing the point here, but I don't understand. Ansible is agentless and doesn't require anything to run plays/tasks on a remote system other than an ssh connection/account and the proper privileges for that account. At the end of the day, it may end up running a command line via the "shell" module anyway, so what's the point?
What does ansible being available have anything to do with remediation of the target system? You only install ansible on the control system, not the target usually unless you're using the pull mechanism? I think it would be nice to have ansible plays that can do the remediation, but you can do that without having ansible installed on the target system...
?? confused ??
On 08/01/2017 04:20 PM, Shawn Wells wrote: RHEL 7.4 is out! That means we can now be public on how Ansible is shipping as part of the rhel-7-server-extras-rpms channel: https://access.redhat.com/downloads/content/ansible/2.3.1.0-3.el7/noarch/fd4...
Now that we can ensure every RHEL install has access to Ansible, is it time to remove the bash scripts?
The original premise of bash script inclusion was "bash is everywhere RHEL is" ..... and now Ansible carries the same truth.
Potential downside for discussion: Ansible binaries ship in the extras channel versus the core rhel-7-server (or whatever it's called). Will users mind enabling the extras channel?
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
scap-security-guide@lists.fedorahosted.org