[OpenSCAP] How shall we distribute SCAP content to client hosts - Design discussion

Development
1

Hello Community,

We are architecturing a new design to foreman openscap.

We have two goals in the new architecture:

Solve the SCAP content distribution to host clients, and
2.

Handle reports correctly.

In this email, We’d like to focus on how to solve the distribution of SCAP
content to the host clients.

Current architecture:

··· -

SCAP Content: A file uploaded by the user on Foreman.

Policy: A policy is created by the user. When creating a policy, the
user chooses which SCAP content to use, and of this SCAP content which SCAP
policy to test. The user also chooses when to run the policy and he may
associate the policy to a hostgroup.

Once a policy is created a puppet module configures foreman_scap_client on
the client host with the data of the policy.

In the current architecture, when creating / editing a policy - the user is
prompted to save the SCAP content in the path that is configured by the
puppet module.

Please take a look at the puppet module
https://github.com/OpenSCAP/puppet-foreman_scap_client/blob/master/manifests/init.pp
and the overrides created
https://github.com/OpenSCAP/foreman_openscap/blob/master/app/models/concerns/foreman_openscap/policy_extensions.rb#L137
when creating a policy.

So, at this point the user is supposed to do one of two:

If the SCAP content is the content provided by scap-security-guide
https://github.com/OpenSCAP/scap-security-guide RPM, and that RPM is
installed on the client, he may copy / create a symlink from the
scap-security-guide xml to /var/lib/openscap/content/.xml
This is an easier part to solve and a suggested issue has been created (
#9950 http://projects.theforeman.org/issues/9950)
2.

The toughest part to solve is when the user has his own SCAP content or
a modified SCAP content (which apparently happens in most cases). The user
needs to manually copy the SCAP content to each of his hosts.

The proposed solutions are meant to solve the ^ pain:

We thought of using one of the following solutions in order to solve the
content distribution problem, and we would love to hear your opinion,
comments and thoughts (and help us think which is the best solution).

Solution A: Pulp with an RPM per each SCAP content. Create an RPM per
each SCAP content, and use Pulp (+ Katello’s content views ?) to distribute
the RPM to the hosts.

Solution B: Pulp with SCAP content. Create a plugin for pulp which
supports SCAP content as content for distribution.

Solution C: (which may be better for a “thin” Foreman). Foreman -> Smart
Proxy -> Host: Use Smart Proxy’s API to upload SCAP content to the Smart
proxy, provide a download url from the smart proxy (via the puppet module).
The foreman_scap_client will download the SCAP content and use it.

** Note on those solutions:

There is an OpenSCAP plugin for Smart Proxy.

Currently we assume that the puppet proxy is also the one to serve OpenSCAP
requests (for uploading the reports and sending them to Foreman, for
instance).

There is a work in progress
https://github.com/shlomizadok/foreman_openscap/tree/host_form_scap_policy_proxy,
so you could choose which Smart Proxy will serve host / hostgroup.

The purpose for each of the solutions is that when a user uploads an SCAP
content it will be distributed to the hosts (either selected hosts or via
hostgroup).

Looking forward hearing your comments and insights

2

> Hello Community,
>
> We are architecturing a new design to foreman openscap.
>
> We have two goals in the new architecture:
>
> 1.
>
> Solve the SCAP content distribution to host clients, and
> 2.
>
> Handle reports correctly.
>
> In this email, We’d like to focus on how to solve the distribution of SCAP
> content to the host clients.
>
> Current architecture:
>
> -
>
> SCAP Content: A file uploaded by the user on Foreman.
> -
>
> Policy: A policy is created by the user. When creating a policy, the
> user chooses which SCAP content to use, and of this SCAP content which SCAP
> policy to test. The user also chooses when to run the policy and he may
> associate the policy to a hostgroup.
>
>
> Once a policy is created a puppet module configures foreman_scap_client on
> the client host with the data of the policy.
>
> In the current architecture, when creating / editing a policy - the user is
> prompted to save the SCAP content in the path that is configured by the
> puppet module.
>
> Please take a look at the puppet module
> <https://github.com/OpenSCAP/puppet-foreman_scap_client/blob/master/manifests/init.pp>
> and the overrides created
> <https://github.com/OpenSCAP/foreman_openscap/blob/master/app/models/concerns/foreman_openscap/policy_extensions.rb#L137>
> when creating a policy.
>
> So, at this point the user is supposed to do one of two:
>
> 1.
>
> If the SCAP content is the content provided by scap-security-guide
> <https://github.com/OpenSCAP/scap-security-guide> RPM, and that RPM is
> installed on the client, he may copy / create a symlink from the
> scap-security-guide xml to /var/lib/openscap/content/<digest>.xml
> This is an easier part to solve and a suggested issue has been created (
> #9950 <Feature #9950: Add default RHEL / Fedora scap contents to foreman_scap_client and seed in foreman_openscap - OpenSCAP - Foreman>)
> 2.
>
> The toughest part to solve is when the user has his own SCAP content or
> a modified SCAP content (which apparently happens in most cases). The user
> needs to manually copy the SCAP content to each of his hosts.
>
>
> The proposed solutions are meant to solve the ^ pain:
>
> We thought of using one of the following solutions in order to solve the
> content distribution problem, and we would love to hear your opinion,
> comments and thoughts (and help us think which is the best solution).
>
>
> -
>
> Solution A: Pulp with an RPM per each SCAP content. Create an RPM per
> each SCAP content, and use Pulp (+ Katello’s content views ?) to distribute
> the RPM to the hosts.
> -
>
> Solution B: Pulp with SCAP content. Create a plugin for pulp which
> supports SCAP content as content for distribution.
> -
>
> Solution C: (which may be better for a “thin” Foreman). Foreman -> Smart
> Proxy -> Host: Use Smart Proxy’s API to upload SCAP content to the Smart
> proxy, provide a download url from the smart proxy (via the puppet module).
> The foreman_scap_client will download the SCAP content and use it.

I like C. It's simple. SCAP data is a just an XML file, right?

It's similar to how we get images to TFTP servers and that works well.

If there could typically be many dozens of SCAP XML's, it might make
sense to organize it with Pulp somehow.

··· On Tue, Mar 31, 2015 at 07:49:02AM -0700, Shlomi Zadok wrote:

** Note on those solutions:

There is an OpenSCAP plugin for Smart Proxy.

Currently we assume that the puppet proxy is also the one to serve OpenSCAP
requests (for uploading the reports and sending them to Foreman, for
instance).

There is a work in progress
https://github.com/shlomizadok/foreman_openscap/tree/host_form_scap_policy_proxy,
so you could choose which Smart Proxy will serve host / hostgroup.

The purpose for each of the solutions is that when a user uploads an SCAP
content it will be distributed to the hosts (either selected hosts or via
hostgroup).

Looking forward hearing your comments and insights

–
You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

3

So, are there 2 sets of files?? The way I read this is there are :

  1. SCAP Content Files
  2. Profile Files

Is this correct? If so, I assume that the profiles reference the scap files.

– bk

··· On 03/31/2015 01:02 PM, Stephen Benjamin wrote: > On Tue, Mar 31, 2015 at 07:49:02AM -0700, Shlomi Zadok wrote: >> Hello Community, >> >> We are architecturing a new design to foreman openscap. >> >> We have two goals in the new architecture: >> >> 1. >> >> Solve the SCAP content distribution to host clients, and >> 2. >> >> Handle reports correctly. >> >> In this email, We’d like to focus on how to solve the distribution of SCAP >> content to the host clients. >> >> Current architecture: >> >> - >> >> SCAP Content: A file uploaded by the user on Foreman. >> - >> >> Policy: A policy is created by the user. When creating a policy, the >> user chooses which SCAP content to use, and of this SCAP content which SCAP >> policy to test. The user also chooses when to run the policy and he may >> associate the policy to a hostgroup.
4

>
>
>
>>
>>> Hello Community,
>>>
>>> We are architecturing a new design to foreman openscap.
>>>
>>> We have two goals in the new architecture:
>>>
>>> 1.
>>>
>>> Solve the SCAP content distribution to host clients, and
>>> 2.
>>>
>>> Handle reports correctly.
>>>
>>> In this email, We’d like to focus on how to solve the distribution of
>>> SCAP
>>> content to the host clients.
>>>
>>> Current architecture:
>>>
>>> -
>>>
>>> SCAP Content: A file uploaded by the user on Foreman.
>>> -
>>>
>>> Policy: A policy is created by the user. When creating a policy, the
>>> user chooses which SCAP content to use, and of this SCAP content
>>> which SCAP
>>> policy to test. The user also chooses when to run the policy and he
>>> may
>>> associate the policy to a hostgroup.
>>>
>>
> So, are there 2 sets of files?? The way I read this is there are :
>
> 1) SCAP Content Files
> 2) Profile Files
>
>
> Is this correct? If so, I assume that the profiles reference the scap
> files.

one content can contain multiple policies… but they are in the same scap
content file.

Ohad

··· On Wed, Apr 1, 2015 at 4:31 PM, Bryan Kearney wrote: > On 03/31/2015 01:02 PM, Stephen Benjamin wrote: >> On Tue, Mar 31, 2015 at 07:49:02AM -0700, Shlomi Zadok wrote:

– bk

–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.