Molecule: inspec should be run against instances, not on them.

Created on 24 May 2018  路  4Comments  路  Source: ansible-community/molecule

Issue Type

  • Feature request

Desired Behavior

Inspec should be executed on the control machine - the same one that runs Ansible - _against_ the instances. _i.e._
inspec exec -t {{ transport }}://{{ instance }}

where {{ transport }} is the transport mechanism (ssh, local, docker, etc) and {{ instance }} is the instance.

The reason that this would represent a step forward are essentially that Inspec has a pretty big impact on the machine being tested. This is a case of the observer effect. Instead of installing Inspec with it's attendant dependencies, the verifier should probe the instance to determine whether it is compliant with a profile.

I would like to discuss updating the way in which this verifier runs to address this.

Most helpful comment

Again, I understand it's not ideal, but for Inspec to fit into Molecule without a ton of headaches on my end implementing connectivity, this felt like the best win.

Would you accept PR if somebody else implements this? If yes would you prefer replacing current inspec verifier or just adding another named "inspec_local"?

Also, as a side note - it seems like proper way of passing parameters to inspec tests are through attributes, which should come from separate yml files, which is very inconvenient when writing molecule tests. Kitchen allows putting this attributes inside kitchen.yml, it would be great if molecule could handle them in the same way.

All 4 comments

Unfortunately, this is the only way to incorporate it properly into Molecule. Inspec does not support all of the drivers Molecule supports. This also allows us to continue to configure Ansible with the connection properties, and simply piggy back on that when executing inspec tests.

Unfortunately, this way will have to do if you wish to use Inspec. Again, I understand it's not ideal, but for Inspec to fit into Molecule without a ton of headaches on my end implementing connectivity, this felt like the best win.

Another, reason we didn't use inspec's built in transport. Molecule needs to know how to connect, and so do users that use the delegated driver. Using Ansible as the transport was lesser of the evils.

Closing as described above. Thank you for the issue.

Again, I understand it's not ideal, but for Inspec to fit into Molecule without a ton of headaches on my end implementing connectivity, this felt like the best win.

Would you accept PR if somebody else implements this? If yes would you prefer replacing current inspec verifier or just adding another named "inspec_local"?

Also, as a side note - it seems like proper way of passing parameters to inspec tests are through attributes, which should come from separate yml files, which is very inconvenient when writing molecule tests. Kitchen allows putting this attributes inside kitchen.yml, it would be great if molecule could handle them in the same way.

hi @skhoroshavin, did you ever look into that?
It looks like if we can have molecule-inspec understand the ansible inventory file, we could use inspec docker and ssh transport at least. Then for everything else we fallback to the current ansible transport approach.

For docker/ssh transport we can implement passing an attribute file from verifier options.

For now a workaround is to pass ENV to the provisioner(as the inspec verifier never uses the verifier env). You can then retrieve them from the verify.yml and do something with it(like iterate though a list for remote profiles, or pass an input-file)

example:
molecule.yml:

provisioner:
  name: ansible
  env:
    INSPEC_INPUT_FILE: input.yml

verify.yml:

    - name: Execute Inspec tests
      command: "{{ inspec_bin }} exec {{ item }} --chef-license=accept --input-file={{ lookup('env','MOLECULE_VERIFIER_TEST_DIRECTORY') }}/{{ lookup('env','INSPEC_INPUT_FILE') }}"
      register: test_results
      with_items: "{{ test_files.stdout_lines }}"
      ignore_errors: true
Was this page helpful?
0 / 5 - 0 ratings

Related issues

decentral1se picture decentral1se  路  3Comments

dj-wasabi picture dj-wasabi  路  3Comments

ssbarnea picture ssbarnea  路  4Comments

r0ckyte picture r0ckyte  路  4Comments

surfer190 picture surfer190  路  3Comments