Page Properties | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
...
The CCE is a unique and immutable reference used by compliance-checking solutions such as OpenSCAP.
The Proposed Approach: Embed CCE->Resource Mappings & Compliance Results in the Catalog
- This is hastily written down after an after-hours TrevoRant
- Embed CCE-to-resource mapping data in the module itself, including how to determine the expected value
- During catalog compiles on the Puppet Server, use a function to build a data structure of the CCE-to-resource mappings, their compliant values, and the actual values.
- After the data structure is complete, add it to the catalog.
- Create tool to build using the data structure in the catalog
An Older Proposed Approach: Embed CCE->Resource Mappings in the Catalog
Our approach within modules will be to record the CCE->resource mapping in the Puppet catalog itself:
Use Puppet Resource tags to refer to CCE ids.(Trevor doesn't like tags because they are mutable under some circumstances)- Provide an inert custom type to track CCE->resource mappings as metadata in the catalog.
- It will accept:
- The CCE ID
- A collection of mapped resources (as a list or individually)
- Additional (optional) annotations for a given CCE(s)
Hypothetical example:
cce{ 'cce_indentifieridentifier':
resources => [Package['foo'], Service['foo']. File['/etc/foo.bar']] comments => 'An optional annotation about this particular mapping'
}
- It will accept:
- Use the catalog compiled for a given system to compil relevant security-compliance documentation.
...