goss-org / goss

Quick and Easy server testing/validation
https://goss.rocks
Apache License 2.0
5.57k stars 472 forks source link

INI setting resource #670

Closed wilrodriguez closed 3 years ago

wilrodriguez commented 3 years ago

Describe the feature:

I'd like to see goss provide support for INI files. INI is probably the most common configuration type we see on most systems and not being able to validate individual settings directly is kind of a problem. There is no POSIX compatible solution to figure out how to validate this example

[main]
foo = bar
[agent]
foo = agent_bar

It's definitely easy to provide a pattern to match /foo\s*=\s*bar/, but when you need to validate per section, that approach falls apart.

I know this was already brought up in the past under #341 and #159 but I think it's worth revisiting. Even in the simple use-case where you can use pattern matching with a file resource, it's often the case that we'll need to be able to validate individual settings for different reasons (read: possibly applying different title and meta fields). The file resource doesn't treat multiple patterns as separate tests, so, all my tests get tossed into a single test, and I can't differentiate them in my test results. By having a resource for each test, I can satisfy the need to evidence individual controls without having to explain to my auditors the massive line of regex matches actually corresponds to controls 7.6.11a, 7.7.1b, AND 7.8.1 (note, control numbers are totally made up).

Describe the solution you'd like

I think inspec actually handles this one pretty well, and my approach is somewhat inspired from there.

ini:
  /etc/foo/bar.conf/agent/foo:
    value: bar

My implementation is somewhat inspired by the pathing used by the Augeas tool, which treats config files as extensions of the filesystem. In fact, my current tests for ini settings basically are planning to use Augeas, but it's terribly slow and adds a layer of wonkyness that I think obfuscates my tests more than it helps in simplifying them. I don't know if this is the best implementation option, you could do something like this that more closely mirrors the file, but I think that would be inconsistent with the other checks:

ini:
  /etc/foo/bar.conf:
    settings:
      agent
        foo: bar

I'm really open to feedback on how to implement this, and I'm willing to write it, I just want feedback on what it would look like. We have so many of these in our list of controls that I might end up writing it in my own fork even if this pull request is rejected, so, I figured I might as well try and contribute.

Describe alternatives you've considered

So far the best alternative is calling augeas with the command resource. This isn't a great solution, as it might not be installed everywhere, it's slow, and it's just not easy to learn for a lot of new users. The other viable alternative is the file resource, but as mentioned before there's some limitations here; you can't treat each setting as a separate test, if you're testing a lot of patterns, the name of the test will be hard to read in documentation output, and you also can't do anything about ini files that use sections.

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.