Controls file format does not prevent using unsupported parameters

[ggbecker]

Description of problem:

Controls file format does not support usage of rule parameter although it's being used by some of the control files in the project:

controls/cis_sle_15.yml:
  1566      status: automated
  1567:     rule:
  1568        - file_groupowner_at_allow

  1749      status: automated
  1750:     rule:
  1751        - sshd_enable_warning_banner

  2199      status: automated
  2200:     rule:
  2201        - group_unique_id

controls/cis_sle12.yml:
  1397      automated: yes
  1398:     rule:
  1399      - file_groupowner_at_allow

  1581      automated: yes
  1582:     rule:
  1583      - sshd_enable_warning_banner

The function below parses the parameters but does not warn the user in case some unsupported parameter is being used:

content/ssg/controls.py

Line 97 in a0f2b1e

def from_control_dict(cls, control_dict, env_yaml=None, default_level=["default"]):

This basically means that the rules under rule will not be processed. The function needs to be extended to restrict which parameters are accepted and throw an error in case something that is not in the list is being used.

[yuumasato]

When loading content that uses classes based on XCCDFEntity, like Rule for example, unparsed data is flagged out during build time:

content/ssg/entities/common.py

Line 175 in a0f2b1e

"Unparsed YAML data in '{yaml_file}': {keys}"

[marcusburghardt]

There are profiles using automated: and maybe other parameter before the definition of the status parameter. Therefore, they are not wrong but just outdated and, for compatibility purposes, should not be restricted now. In fact, the respective control files should be updated before restricting parameters which were used in the past but there is a current replacement.

Instead of restricting this now and triggering a wave of errors, I would recommend to simply alert about this but keep accepting until we are sure all control files are updated.

[ggbecker]

There are profiles using automated: and maybe other parameter before the definition of the status parameter. Therefore, they are not wrong but just outdated and, for compatibility purposes, should not be restricted now. In fact, the respective control files should be updated before restricting parameters which were used in the past but there is a current replacement.

Instead of restricting this now and triggering a wave of errors, I would recommend to simply alert about this but keep accepting until we are sure all control files are updated.

Agree, but in case of rule, the parameter will not get loaded and rules will not be present in the built profile, which is a major issue.