work with token and direct compliance server API

[srenatus]

This adds the ability to directly talk to a compliance server, without
passing through a chef-server. To ensure proper authentication, this
needs a user (access) token:

token = '....'

# iterate over all selected profiles
node['audit']['profiles'].each do |owner_profile, enabled|
  next unless enabled
  o, p = owner_profile.split('/')

  compliance_profile p do
    owner o
    server URI.parse('http://192.168.33.1:8080/api/')
    token token
    action [:fetch, :execute]
  end
end

compliance_report 'chef-server' do
  server URI.parse('http://192.168.33.1:8080/api/')
  token token
  organization 'brewinc'
end if node['audit']['profiles'].values.any?

There're two big buts here, though:

1. It's expecting an access token; so to be of real use in automation setups, something surrounding this chef-run needs to exchange a refresh token for an access token and use ENV['ACCESS_TOKEN'] (or similar) to pass it into the recipe.
2. Compliance will only accept reports for users (identified via the token) that are authenticated using an oc_id connector (i.e., coming "from a chef server") -- and thus this doesn't make testing the audit-cookbook <--> compliance interaction that much easier: it still needs a chef server in the mix.

[srenatus]

example recipe

token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6InVQUExHVjFiVDg4YTNnZ0MtQ1hxUDdfTlgzTGZiblZSeHhYUTQwV2l0cXI0Z0pRTGw3T2........'

# iterate over all selected profiles
node['audit']['profiles'].each do |owner_profile, enabled|
  next unless enabled
  o, p = owner_profile.split('/')

  compliance_profile p do
    owner o
    server URI.parse('http://192.168.33.1:8080/api/') # <---
    token token # <---
    action [:fetch, :execute]
  end
end

# report the results
compliance_report 'chef-server' do
  server URI.parse('http://192.168.33.1:8080/api/')
  token token # <---
  direct true # <---
  owner 'admin' # <---
end if node['audit']['profiles'].values.any?

[chris-rock]

could we make it an attribute and set the default to false?

[srenatus]

I'm afraid I don't get it. It's not boolean but a string property that is nil if unset and some string if it was provided.
So currently, it's a property of a resource. You can use attributes to set it in your recipe (see here) -- I haven't had a need to touch the default recipe here.

Having a resource break its interface and reach out into node attributes doesn't seem right to me...

[chris-rock]

@srenatus of course we should not use node attributes directly in a library. I was thinking about making it an option to compliance profile:

compliance_profile p do
    owner o
    server URI.parse(ENV['COMPLIANCE_API'])
    insecure true
    token token
    action [:fetch, :execute]
end

Then we could use an attribute as input. I would like to make insecure to false by default. In insecure is true, we could set the proper openssl string as required.

[chris-rock]

@srenatus very good, I like the improvement. Just some minor questions

[srenatus]

Thanks @alexpop for finding the nasty bug resolved in bfeb004 👍

@chris-rock is this what you had in mind?

[srenatus]

Rebased & refactored.

[chris-rock]

Should this be token = node['audit']['token'] ?

[chris-rock]

Awesome @srenatus, I just found some minor nitpicking things :-)

[chris-rock]

I merge it, once its green

[chris-rock]

Awesome @srenatus

[cjohannsen81]

Hey, just learned that there has to be a slash at the end (URI object). Otherwise it will fail.