Project

General

Profile

Actions

Architecture #24876

closed

Add a compliance-by-feature logic and save compliance in base

Added by François ARMAND 5 months ago. Updated 3 months ago.

Status:
Released
Priority:
N/A
Category:
Web - Compliance & node report
Target version:
Effort required:
Name check:
To do
Fix check:
To do
Regression:
No

Description

Historicaly, we only split node configuration and corresponding compliance in two:
- the system (as in "Rudder itself") configuration/compliance, checking for the well being of the infrastructure (rudder agent configured, etc)
- the user configuration/compliance, ie all the technique/directive/rules configured by user on nodes.

The node configuration are in base for some time now, but the compliane result themselves are pure computation done from configuration and node "runs".

This is too limiting, because we want to be able to differentiate more than just between system/user compliance:
- for system, we have plugin-specific policies that are not really system, but clearly part of the underlying, not-user-exposed things - typicaly, policies for system update campaign. For now, they are marked "system", but that gives surprising effects
- for user compliance, in fact we want to be able to have several user compliance: typicaly, in the case of an hardening set of policies, it will be user-directed and configured, but we don't want it to be merged with main, basic user compliance.

This is also too limiting, because we want to be able to have different compliance validity for different aspect of compliance, and not rely on potentially very heavy computation each time we need them (or keep around extremely big datas to be able to redo the computation if we only have a cache).

So we would like to put these node-compliance-by-feature in base.

The main idea is simple:

- add a tag compliance:namespace on technique/directive/rules that is inherited by aggregation and allows to sort compliance reports,
- when computing compliance, save each shard in base for a node, so that a node has access to its base compliance, system compliance, campaign compliance, etc.

That feature will also use / integrate with the table added for Rudder score in Rudder 8.1.


Subtasks 1 (0 open1 closed)

Rudder plugins - Architecture #24906: Impact on plugin for policyType and yaml rest testRejectedFrançois ARMANDActions

Related issues 2 (2 open0 closed)

Related to Rudder - Architecture #24963: Persist compliance in base to know last state for a long timePending releaseFrançois ARMANDActions
Related to Rudder - Bug #25353: Rollback in event log leads to technique xml deserialization issueNewActions
Actions #1

Updated by François ARMAND 5 months ago

  • Status changed from New to In progress
  • Assignee set to François ARMAND
Actions #2

Updated by François ARMAND 5 months ago

  • Subtask #24906 added
Actions #3

Updated by François ARMAND 4 months ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Vincent MEMBRÉ
  • Pull Request set to https://github.com/Normation/rudder/pull/5703
Actions #4

Updated by François ARMAND 4 months ago

  • Related to Architecture #24963: Persist compliance in base to know last state for a long time added
Actions #5

Updated by Anonymous 4 months ago

  • Status changed from Pending technical review to Pending release
Actions #6

Updated by Anonymous 4 months ago

Actions #7

Updated by Alexis Mousset 3 months ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 8.2.0~alpha1 which was released today.

Actions #8

Updated by Clark ANDRIANASOLO about 2 months ago

  • Related to Bug #25353: Rollback in event log leads to technique xml deserialization issue added
Actions

Also available in: Atom PDF