Sean,

The scenario in your third paragraph can also be performed in a similar
manor with ansible. Instead of the puppet agent communicating (ssl) with
the master, ansible can fetch its configuration from whatever your source
control is and execute locally. This can all be encrypted with your choice
of a rotating cert setup. This could happen during startup or userdata,
etc. Although, the rotation implementation is a handful and adds some
complexity, especially with security folks, it is convenient and easy to
manage expirations, rotations, and revocation....etc.

Don't hold your breath on the ACAS situation haha.

Matthew

On Fri, Aug 4, 2017 at 08:18 Sean <smalde...@gmail.com> wrote:

> I agree with keeping the bash remediations.  I make use of this projects
> bash remediations as a reference for my project...sort of a second opinion.
>
> Like Trevor said in #3, Ansible is not a great prospect to use in
> production environments on secured networks.  Automated, remote, privileged
> execution isn't a concept that's easy to get past the cyber security
> folks.  There is a catch-22 with this in the DoD arena though...We're all
> required to overlook RHEL-06-000529/RHEL-07-010340 with regard to allowing
> ACAS to run scans on our systems with unchallenged privilege escalation.  I
> tried to propose using SSH keys, SSH Agent, and pam_ssh_agent_auth, but we
> can't find anyone involved with ACAS who can speak intelligently about the
> topic.
>
> Anyway, the project I work on is similar to Trevor's in that we use
> Puppet.  Since Puppet is an agent process, which runs as root, and is
> secured with client ssl certificates, the "server" is never doing a remote
> execution.  The agent requests it's configuration from the server, the
> server authenticates the agent by the ssl certificate and provides the
> data.  Most of you probably know this already.
>
>
> P.S. Trevor's SIMP project is way cooler than mine, especially if you
> appreciate stylish, elegant, functional puppet modules!  My project is more
> like a rusty old ford truck - it gets the job done, but don't expect better
> than 10 gallons to the mile.
>
> --Sean
>
> On Fri, Aug 4, 2017 at 9:34 AM, Trevor Vaughan <tvaug...@onyxpoint.com>
> wrote:
>
>> 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 <
>> wcera...@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" <sh...@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-le...@lists.fedorahosted.org
>>> _______________________________________________
>>> scap-security-guide mailing list --
>>> scap-security-guide@lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> scap-security-guide-le...@lists.fedorahosted.org
>>>
>>
>>
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699 x788 <(410)%20541-6699>
>>
>> -- This account not approved for unencrypted proprietary information --
>>
>> _______________________________________________
>> scap-security-guide mailing list --
>> scap-security-guide@lists.fedorahosted.org
>> To unsubscribe send an email to
>> scap-security-guide-le...@lists.fedorahosted.org
>>
>>
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide@lists.fedorahosted.org
> To unsubscribe send an email to
> scap-security-guide-le...@lists.fedorahosted.org
>
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Reply via email to