The “Longer Terms Quests” section in the Infrastructure Apprentice Page currently contains outdated references to CSI (Community Services Infrastructure) that no longer relates to the current Infrastructure’s projects/applications.
I’d say that particular thing we can replace with a more generic thing that doesn’t refer to the now nonexistant CSI.
Something like “Look at the notes variable in inventory/host_vars and group_vars and see if it can be made more detailed or at least updated from the default value. Things to include might be if this host or group depends on another one or more information about what this host does.”
Thats just a first cut, other better ideas welcome!
Thanks for starting this thread. I would just want to add that it would be probably good to add comment to each host_vars/group_vars that describe what the machine is used for.
Mark Rosenbaum and I had been working parallel efforts to recover the CSI documents back in August, but then we both got busy. Smooge pulled a backup of the CSI out of his hat:
The original document covered a lot of stuff that was relevant in the RHEL 5 era and reads a lot like the content we’d find in a STIG. About half to 2/3 of my life is dealing with a variety of DISA STIGs, and analyzing the RHEL STIGs and implementing their automation falls within my scope of responsibilities. The Fedora Project has a mixture of RHEL and Fedora in the infrastructure, but DISA and Red Hat make it clear that the STIG is developed specifically for the RHEL product, not for Fedora, etc.
I doubt that we want to go full bore with DISA’s 452 item checklist of controls, but I do wonder if one of the other more generic control sets could be applied as a baseline (carefully so that we break as little as possible). You would definitely want to experiment on staging or some other test bed way before you started poking the production infra. A lot of the procedural stuff listed in the document reads very much like what parts of our enclave packages would say.
Ultimately, re-plumbing the CSI is both a technical and non-technical affair. At work we do it with a group chaired by someone called the Information System Security Manager (non technical, more about the rules and compliance) and a body of folks representing various technical (system administrators, network administrators, etc.) or procedural (physical security folks, configuration managers, etc.) disciplines.
I was wondering if we could sidetrack a little and add this landing page to the list of “Longer Term Quests”?
Since this project is under infra team, why don’t we revamp this landing page?
It would be easier for new contributors to understand which applications/projects are under which team and it wouild help them navigate teams and choose the one that suits them best.
Maybe we could make the graph more interactive like Obsidian’s graph (something similar)?
It’s just an idea, please let me know what you all think about it?
I think keeping it simple, not adding new technologies, concentrating up updating information is the most important. It is not the current format that is the problem, it is the information. There is so much updating work to be doing, lets get that done first.
Once the information is layed out updated and neat, someone from design could churn out a new graphic to kick it up a notch - because all the information would be there then.
The original document covered a lot of stuff that was relevant in the RHEL 5 era and reads a lot like the content we’d find in a STIG. About half to 2/3 of my life is dealing with a variety of DISA STIGs, and analyzing the RHEL STIGs and implementing their automation falls within my scope of responsibilities. The Fedora Project has a mixture of RHEL and Fedora in the infrastructure, but DISA and Red Hat make it clear that the STIG is developed specifically for the RHEL product, not for Fedora, etc.
Yep.
I doubt that we want to go full bore with DISA’s 452 item checklist of controls, but I do wonder if one of the other more generic control sets could be applied as a baseline (carefully so that we break as little as possible). You would definitely want to experiment on staging or some other test bed way before you started poking the production infra. A lot of the procedural stuff listed in the document reads very much like what parts of our enclave packages would say.
Yeah, I think we want to do sensible deployments and learn/add anything
we see from some other checklists, but I don’t think we want to go all
in on checking everything. Some of it will likely make little sense in
our setup, or as you mention, Fedora instances will not be taken into
account in any case.
Ultimately, re-plumbing the CSI is both a technical and non-technical affair. At work we do it with a group chaired by someone called the Information System Security Manager (non technical, more about the rules and compliance) and a body of folks representing various technical (system administrators, network administrators, etc.) or procedural (physical security folks, configuration managers, etc.) disciplines.
Yeah. I wonder if there is anything like CSI out there that we could
just leveage? something between what CSI was and what a full detailed
thing would be?