Collector compliance views

_images/compliance.menu.png

Collector's interfaces to analyze compliance data and to configure the framework are all grouped in the menu Compliance.

Switch between compliance views using the drop-down menu.

 

Status

This view has 4 stacked panels. The top 3 are folded upon page load.

Per-module compliance status

This panel present the compliant/not-compliant status aggregated by module.

The aggregation is done on the data cursor filtered in the downmost, unaggregated, view.

It helps answer the following questions:

  • What corporate rule is alarmingly not respected
  • What corporate rule is surprisingly well respected
  • How the compliance ratio of a rule evolved in the last year
  • Which modules runs on more than 1000 nodes
_images/compliance.status.module.png
Module column

The module name.

Total column

The number of nodes checked by this module.

Ok column

The number of nodes passing the compliance checks of the module.

Percent column

100 * Ok / Total.

History column

Week over week plot of ok/not ok/not applicable status returned by modules for the node. The plotted status are the worst case in the week, meaning if a module returned 'not ok' then 'ok' during week 50, only 'not ok' will be accounted.

Per-service compliance status

This panel present the compliant/not-compliant status aggregated by service.

The aggregation is done on the data cursor filtered in the downmost, unaggregated, view.

It helps answer the following questions:

  • Which are the least compliant services
  • Which are the most compliant services
  • How the compliance ratio of a service evolved in the last year
  • Which services run less than 10 modules
Service column

The service name.

Total column

The number of modules checked for this service.

Ok column

The number of modules passing the compliance checks for this service.

Percent column

100 * Ok / Total.

History column

Week over week plot of ok/not ok/not applicable status returned by modules for the service. The plotted status are the worst case in the week, meaning if a module returned 'not ok' then 'ok' during week 50, only 'not ok' will be accounted.

Per-node compliance status

This panel present the compliant/not-compliant status aggregated by node.

The aggregation is done on the data cursor filtered in the downmost, unaggregated, view.

It helps answer the following questions:

  • Which are the least compliant nodes
  • Which are the most compliant nodes
  • How the compliance ratio of a node evolved in the last year
  • Which servers run less than 10 modules

This view is also used to pilot remediation campaigns, using the action tool on selected servers.

_images/compliance.status.node.png
Node column

The node name.

Total column

The number of modules run on the node.

Ok column

The number of modules passing compliance checks.

Percent column

100 * Ok / Total.

History column

Week over week plot of ok/not ok/not applicable status returned by modules for the node. The plotted status are the worst case in the week, meaning if a module returned 'not ok' then 'ok' during week 50, only 'not ok' will be accounted.

Detailled compliance status

This panel present the compliant/not-compliant status without aggregation. It can be used to filter the dataset aggregated in the above panels.

It helps answer the following questions:

  • Which servers infringe a module's rules
  • Which Linux servers infringe a module's rules
  • Verify a single server compliance to the whole set of rules
  • Verify a single server compliance to a single module's rules
_images/compliance.status.details.png
Date column

The module run date on the node.

Node column

The node name.

Module column

The compliance module name.

Action column

The module action which returned the logged status. Always 'check' in this view.

Status column

The module check run status. Can be 'ok' (0), 'not ok' (1) or 'not applicable' (2).

History column

A run over run status sparkline. This columns present no timeline information.

Logs

This view presents raw logs of the compliance modules runs on every nodes.

It helps answer the following questions:

  • Since when a server is not compliant to a modules' rules
  • What was the compliance state of a server at the date of a crisis situation (post-mortem analysis)
_images/compliance.log.png
Run date column

The module action run date on the node.

Node column

The node name.

Module column

The compliance module name

Action column

The module action which returned the logged status. Can be 'check', 'fixable' or 'fix'.

Status column

The module action run status. Can be 'ok' (0), 'not ok' (1) or 'not applicable' (2).

Log column

The output of the compliance module for the run.

Rules

This tabular view is optimized for browsing and searching the configured compliance rules.

Example searchs:

  • Show all variables of class authkeys
  • Show all variables referencing /etc/sudoers.d/
  • Show all variables changed in the last week
  • Show all variables in the prereq-tomcat ruleset
  • Show all variables exported to Red Hat 6 servers

Some design actions are available from this view, but the preferred view for a compliance design session is Compliance > Designer.

Create an empty ruleset

  • Click 'Create ruleset'
  • Choose a unique ruleset name
  • Choose contextual/explicit
  • Click 'Submit'

The new ruleset now appears in the ruleset list, ready to receive variables.

Add variables

  • Click 'Add variable'
  • Choose a variable name
  • Choose a variable value
  • Click 'Submit'

Edit variables

  • Click either the variable name or the variable value top-right 'edit' icon
  • Edit the input or content
  • Press 'Enter' to save the change

Attach filterset

If the ruleset is contextual, the following procedure attach a filter to the ruleset.

  • Click 'Attach filterset'
  • Choose a pre-existing filterset from the list box
  • Click 'Submit'

Clone ruleset

Cloning a ruleset helps administrators who want their rulesets immutable : when a variable change is needed, the administrator clones the ruleset and apply the change to the clone. This governance policy implies ruleset names are versioned.

  • Click 'Clone ruleset'
  • Choose a pre-existing ruleset from the list box
  • Choose a name for the cloned ruleset
  • Click 'Submit'

Attach rulesets to nodes

This facility is offered by the bottom tables of the ruleset view. The table filters are useful to select the nodes efficiently.

  • Check the nodes in the left-side table
  • Check the rulesets in the right-side table
  • Click 'Attach ruleset'

Filters

The filters view allow compliance administrators to create complex filtersets to limit the ruleset scope to a specific node cursor. All fields from the node asset table can be combined.

A typical filterset would be 'All Red Hat 4 servers whose team responsible is SomeTeam'.

A filterset is a combination of filters or filtersets. Filters are created through the top table and filterset created through the bottom table. Only member of the 'CompManager' group are allowed to create or edit filters.

Create a filter

  • Click 'Create filter'
  • Choose a table name. Available table names: 'nodes'
  • Choose a field name. Available field names: 'warranty_end', 'status', 'role', 'environnement', 'mem_bytes', 'mem_banks', 'mem_slots', 'os_vendor', 'os_name', 'os_kernel', 'os_release', 'os_arch', 'cpu_freq', 'cpu_dies', 'cpu_cores', 'cpu_model', 'cpu_vendor', 'type', 'nodename', 'team_responsible', 'serial', 'model', 'loc_addr', 'loc_city', 'loc_zip', 'loc_rack', 'loc_floor', 'loc_country', 'loc_building', 'loc_room', 'power_supply_nb', 'power_cabinet1', 'power_cabinet2', 'power_protect', 'power_protect_breaker', 'power_breaker1', 'power_breaker2', 'updated'
  • Choose an operator. Available operators: '=', 'LIKE', 'NOT LIKE', '<', '<=', '>', '>=', 'IN', 'NOT IN'
  • Set a filter value. The wildcard character for the 'LIKE' and 'NOT LIKE' operators is '%'. List values for the 'IN' and 'NOT IN' operators are comma-separated.

Create a filterset

Filtersets are created empty, then filters or filtersets are attached to the new filterset.

  • Click 'Create filterset'
  • Set a filterset name
  • Click on 'Submit'

Populate a filterset

  • Click 'Attach filterset' or 'Attach filter'
  • Choose the filterset to attach to in the list box
  • Choose the filterset or filter to attach in the list box
  • Set a logical operator to combine the filter/filterset with. Available logicial operators: 'AND', 'OR'.
  • Optionally set an order. Defaults to '0'. Ordering is important when you mix 'AND' and 'OR' in the same filterset
  • Click on 'Submit'

Best practice

It is recommended for readability to define filtersets combining with only one logical operator (only ANDs or ORs). For example, a filterset implementing 'all Linux or HP-UX servers whose team responsible is SOMETEAM should be implemented as 2 encapsulated filtersets:

  • filter1: 'nodes.os_name = HP-UX'
  • filter2: 'nodes.os_name = Linux'
  • filter3: 'nodes.team_responsible = SOMETEAM'
  • filterset1: filter1 OR filter2
  • filterset2: filterset1 AND filter3

Of course, more explicit filterset names are recommended.

Modules

The modulesets view allow compliance administrators to group modules into modulesets. Only the designer view can render the moduleset encapsulations though. The modulesets can then be attached to nodes through the nodemgr command line:

# nodemgr compliance attach --moduleset modset1

Only attached modulesets' modules are scheduled for a compliance action by the OpenSVC agents.

Only member of the 'CompManager' group are allowed to create or edit modulesets.