Hello Jeff,
----- Original Message -----
From: "Jeff Pullen" <jpullen(a)redhat.com>
To: "SCAP Security Guide" <scap-security-guide(a)lists.fedorahosted.org>
Sent: Saturday, November 14, 2015 5:07:25 AM
Subject: OpenStack scap content
I'm new here...
Welcome!
so I apologize if this has already been discussed. It seems
that not much has been done lately with the OpenStack SCAP content. So it
seems like a good place to start learning how to contribute to this project.
1. I wanted to get opinions on how to tackle the quick release cycle, and
various components used within OpenStack. I noticed that in RHEL it is
broken into versions (5/6/7), but Fedora isn't. OpenStack has a Fedora like
release cycle, and it may be difficult to maintain numerous versions. Does
it make sense to just have this work with the latest version?
Red Hat Enterprise Linux is in SSG split into dedicated subfolders because it
has a longer support period than Fedora. We align with the vendor support
model (support both those Red Hat Enterprise Linux and Fedora versions, that
are supported by the vendor currently). For Fedora we support those releases
receiving security updates in particular period (for example Fedora 21 will be
supported till 2015-12-01:
[1]
https://github.com/OpenSCAP/scap-security-guide/issues/853
After that date SSG upstream will discontinue support of Fedora 21, and support
only more recent Fedora releases).
For the beginning (because we truly are ad beginning FWIW contributing SCAP
content for OpenStack), I would propose to start supporting just the current
master (most recent) version, IOW "Liberty":
[2]
http://www.openstack.org/software/liberty/
plus support for the six Core Services:
[3]
http://www.openstack.org/software/project-navigator
Later we can adjust the SSG directory layout for the OpenStack project to
better map to added rules for various OpenStack releases.
2. OpenStack also has different server roles that will have different
requirements, and services. For example the controllers have databases and
web servers, where the computes will not. What is the best way to separate
these?
Are both of the controllers and one-purpose dedicated computers / nodes intended
to run always the very same OpenStack version? We basically have two choices:
* have one benchmark / security checklist per OpenStack release (containing
all rules intended for that release). Then create particular profiles (oriented
e.g. just to controllers, or just to end-point nodes), where each profile would
contain just sub-set of the whole set of rules available for that OpenStack release.
This approach might be quicker to implement, but there might arise issues how to
decide which rules should be applied against particular "flavour" (e.g.
controller,
or end-point node) of underlying OpenStack release (since final benchmark would need
to contain CPE identifiers for both / multiple of these possible flavours),
* another option is to create two benchmarks per OpenStack release (one for controllers,
second for end-point nodes). Here we would solve the issue of easy applicability (each
benchmark would be applicable just to that "flavour" / "purpose" of
OpenStack systems).
On the other hand this might take longer time to implement (the need of two / more
separate
benchmarks, the need to categorize rules as either applicable to controller or end-point
node etc.) Are we sure there can't be other group (purpose oriented) machines in
OpenStack
than just controllers and end-point nodes?
Finally, if there are resources that can cut down on the learning curve on
how all the scap files interact with each other I would really appreciate if
you could send me those (off list).
There are some of them available as of right now, but given the recent changes
in the SSG git repository layout, they are / will be pretty outdated. As of right
now we are in the process of providing updated / more recent ones, and within that
effort organizing SSG Q/A Contributor Workshop to:
* identify current issues / bottlenecks users need to overcome trying to contribute to
SSG,
* present an updated model of contributing to SSG (enforced mainly by repository
structure
layout changes performed in the last release),
* and obtain feedback on that one (+ fix those issues, still recognized as unclear /
leading to possible confusion).
That workshop will happen on Tuesday in a week from now (2015-11-24) -- see my post
in other thread (&& consider participating).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
> --
> SCAP Security Guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
https://github.com/OpenSCAP/scap-security-guide/