Feature/RFC: Remote Ohai Info

[aaronlippold]

General Goal

Enhance our reporter plugin and add a new core plugin to inspec that will use the new Ohai remote target mode and the existing train connection to the target to populate a new section of the run_data in inspec which will support adding a top-level .target object in the JSON base reporter to collect inventory information about the asset under test.

References

• https://github.com/inspec/inspec/blob/main/dev-docs/plugins.md
• Ohai Target Mode aka Remote Ohai chef/ohai#1503
• https://github.com/chef/chef/blob/7558c414030d082194d0d2b5f74279ce151517e9/lib/chef/client.rb#L574-L609

Approach

Notes from Conversation with @cwolf on topic

This PR should be split into two parts.

1. A PR on the https://github.com/mitre/inspec/tree/remote-ohai branch for adding things to core
2. A simple PR here to update the reporter and adjust the logic of this reporter to account for not using the attestation function and just having the new ohai data

Follow On Work

3. Determin if we should update other core plugins as part of (1) or if they should be follow-on PRs
4. Propose Idea on InSpec project to finish the make all reporters plugins, add a cli-options plug-in type, etc.

Part (1)

• A core plug-in addition to inspec-core, that will use a remote ohai connection ( as the chef-infra client does above with a little hacking ) via the existing transport and update the run_data object for use in other reporters.
• Add two cli flags to thor --without-ohai and --ohai-plugins=<list> to over-ride the default filters.
• Make a default dataset that ohai collects that is close to the core data collected via the automate reporter
• Adds in target specific environment ohai plugins - ec2, docker, etc. where it is applicable if train can tell us we are on an ec2, docker, etc.
• Add a new toplevel json object to the base json reporter called target that holds the new data.

Part (2)

• Either
  (a) Update the hdf reporter to use the new run_data from ohai and its target-specific data
  (b) Merge the hdf reporter into core as an Attestation PR next to waiver and update our technical implemation to follow closely with waiver

This approach would allow us to know which transport we are using and then – if a specific Ohai plugin exists for that target – ec2, vmware, docker etc. – we could active it and pass the information about through to the final report.

Part (3)

• Perhaps update the automate reporter to also consume this data
• perhaps update the cli reporter to display a few useful details from this new data

(Part 4) Longer Tearm Solution

A cli-options plugin type would be the best way to approach this however, @cwolf said things are a bit of mess at the moment so this is likely the only real viable approach at the moment.

Then the HDF reporter or any reporter could just check for the existance of the OHAI data in the run_data object and layer it in if it is there.

Questions / Workflow

• answered here how can I run it 'via bundle' aka locally so I don't have to hack code, rebuild plugin gem, uninstall, install, run again and at the reporter phase,
• answered here - Is is arealdy dead by this time it seems - Is the Train connection already gone at the 'reporter' phase or can I use some form of the Chef client code above to layer a specific Ohio data subset that I want in my final report.

Signed-off-by: Aaron Lippold [email protected]

[rbclark]

Code for setting up an Ohai target to run is as follows:

require 'ohai'
PLUGINS = %w{
cpu
kernel
os
platform}.freeze
ohai_test = Ohai::System.new
Ohai::Config.target_mode.host = 'docker://<somehost>'
if URI.parse(Ohai::Config.target_mode.host).scheme
    train_config = Train.unpack_target_from_uri(Ohai::Config.target_mode.host)
    Ohai::Config.target_mode = train_config
end
Ohai::Config.target_mode.enabled = true
Ohai::Config.node_name = Ohai::Config.target_mode.host unless Ohai::Config.node_name
ohai_test.tap { |o| o.all_plugins(PLUGINS) }.data

This will cause remote ohai to throw a fit since https://github.com/chef/chef/blob/main/chef-config/lib/chef-config/mixin/train_transport.rb#L72-L100 expects a config file to exist. It is very weird that a config file is expected to exist considering inspec uses train without ever requiring a config file. This will need to be reconciled in ohai before integrating it with train (likely by adding the ability for config to be passed in from inspec as a config hash instead of a file).

Inspec handles train credentials as follows: https://github.com/inspec/inspec/blob/7415fc11d000dae1813a14ba12d957851fa999b3/lib/inspec/config.rb#L109-L128

[xee5ch]

It is very weird that a config file is expected to exist considering inspec uses train without ever requiring a config file. This will need to be reconciled in ohai before integrating it with train (likely by adding the ability for config to be passed in from inspec as a config hash instead of a file).

Thanks, that summarizes things nicely. So the inspec client would somehow pass through information and it would be sent over to the remote ohai?

Also, hi Rob. 👋

[aaronlippold]

if URI.parse(Ohai::Config.target_mode.host).scheme
    train_config = Train.unpack_target_from_uri(Ohai::Config.target_mode.host)
    Ohai::Config.target_mode = train_config
end

@rbclark are we sure this is the right block here? It seems to be throwing a new error we didn't see before:

[2] pry(main)> next
Traceback (most recent call last):
	11: from ohai.rb:17:in `<main>'
	10: from ohai.rb:17:in `tap'
	 9: from ohai.rb:17:in `block in <main>'
	 8: from /Users/alippold/.rvm/gems/ruby-2.7.2/gems/ohai-17.9.0/lib/ohai/system.rb:105:in `all_plugins'
	 7: from /Users/alippold/.rvm/gems/ruby-2.7.2/gems/ohai-17.9.0/lib/ohai/system.rb:130:in `run_plugins'
	 6: from /Users/alippold/.rvm/gems/ruby-2.7.2/gems/ohai-17.9.0/lib/ohai/system.rb:130:in `each'
	 5: from /Users/alippold/.rvm/gems/ruby-2.7.2/gems/ohai-17.9.0/lib/ohai/system.rb:131:in `block in run_plugins'
	 4: from /Users/alippold/.rvm/gems/ruby-2.7.2/gems/ohai-17.9.0/lib/ohai/system.rb:83:in `runner'
	 3: from /Users/alippold/.rvm/gems/ruby-2.7.2/gems/ohai-17.9.0/lib/ohai/system.rb:83:in `tap'
	 2: from /Users/alippold/.rvm/gems/ruby-2.7.2/gems/ohai-17.9.0/lib/ohai/system.rb:84:in `block in runner'
	 1: from /Users/alippold/.rvm/gems/ruby-2.7.2/gems/ohai-17.9.0/lib/ohai/system.rb:119:in `transport_connection'
/Users/alippold/.rvm/gems/ruby-2.7.2/gems/chef-config-17.9.52/lib/chef-config/mixin/train_transport.rb:115:in `build_transport': undefined method `[]' for nil:NilClass (NoMethodError)

[aaronlippold]

https://github.com/inspec/inspec/blob/7415fc11d000dae1813a14ba12d957851fa999b3/lib/inspec/config.rb#L182

[aaronlippold]

https://docs.chef.io/workstation/knife_setup/ - chef credentials file

[rbclark]

It is very weird that a config file is expected to exist considering inspec uses train without ever requiring a config file. This will need to be reconciled in ohai before integrating it with train (likely by adding the ability for config to be passed in from inspec as a config hash instead of a file).

Thanks, that summarizes things nicely. So the inspec client would somehow pass through information and it would be sent over to the remote ohai?

Also, hi Rob. 👋

Hey AJ!

Yep, so InSpec already utilizes train. The difference is that ohai borrowed from chef-client instead of inspec with how it sets up it's configuration, and in chef-client a config file is used to configure train. In the code comments they mention how this borrows heavily from knife https://docs.chef.io/workstation/knife_setup/#knife-config

[xee5ch]

@aaronlippold should we catch up this week or next to sync up on this stuff?

[aaronlippold]

Would love to