inspec 2.2.61 → 2.2.64

Sign up to get free protection for your applications and to get access to all the features.
Files changed (43) hide show
  1. checksums.yaml +4 -4
  2. data/CHANGELOG.md +22 -15
  3. data/README.md +0 -1
  4. data/docs/dev/plugins.md +321 -0
  5. data/docs/profiles.md +20 -18
  6. data/lib/bundles/inspec-artifact/cli.rb +1 -0
  7. data/lib/bundles/inspec-compliance/cli.rb +1 -0
  8. data/lib/bundles/inspec-habitat/cli.rb +1 -0
  9. data/lib/bundles/inspec-init/cli.rb +1 -0
  10. data/lib/bundles/inspec-supermarket/cli.rb +1 -0
  11. data/lib/inspec.rb +4 -2
  12. data/lib/inspec/base_cli.rb +1 -0
  13. data/lib/inspec/cli.rb +35 -16
  14. data/lib/inspec/control_eval_context.rb +7 -6
  15. data/lib/inspec/dependencies/requirement.rb +0 -1
  16. data/lib/inspec/fetcher.rb +1 -2
  17. data/lib/inspec/library_eval_context.rb +1 -1
  18. data/lib/inspec/plugin/v1.rb +2 -0
  19. data/lib/inspec/{plugins → plugin/v1/plugin_types}/cli.rb +2 -0
  20. data/lib/inspec/{plugins → plugin/v1/plugin_types}/fetcher.rb +1 -1
  21. data/lib/inspec/{plugins → plugin/v1/plugin_types}/resource.rb +0 -0
  22. data/lib/inspec/{plugins → plugin/v1/plugin_types}/secret.rb +1 -1
  23. data/lib/inspec/{plugins → plugin/v1/plugin_types}/source_reader.rb +1 -1
  24. data/lib/inspec/{plugins.rb → plugin/v1/plugins.rb} +7 -5
  25. data/lib/{utils/plugin_registry.rb → inspec/plugin/v1/registry.rb} +0 -0
  26. data/lib/inspec/plugin/v2.rb +30 -0
  27. data/lib/inspec/plugin/v2/activator.rb +16 -0
  28. data/lib/inspec/plugin/v2/loader.rb +204 -0
  29. data/lib/inspec/plugin/v2/plugin_base.rb +98 -0
  30. data/lib/inspec/plugin/v2/plugin_types/cli.rb +27 -0
  31. data/lib/inspec/plugin/v2/plugin_types/mock.rb +12 -0
  32. data/lib/inspec/plugin/v2/registry.rb +76 -0
  33. data/lib/inspec/plugin/v2/status.rb +29 -0
  34. data/lib/inspec/reporters.rb +5 -1
  35. data/lib/inspec/reporters/automate.rb +1 -1
  36. data/lib/inspec/reporters/{json_merged.rb → json_automate.rb} +1 -1
  37. data/lib/inspec/resource.rb +1 -1
  38. data/lib/inspec/rule.rb +14 -8
  39. data/lib/inspec/secrets.rb +1 -2
  40. data/lib/inspec/source_reader.rb +1 -2
  41. data/lib/inspec/version.rb +1 -1
  42. data/lib/resources/apache_conf.rb +1 -1
  43. metadata +20 -10
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: d165544705d8d7d1532d3490b651106922bd12a39bcd086dea86dfa184830939
4
- data.tar.gz: bdb0c2273998ad9dd3bf2846755fa60db0522713f8937f31922a26ba52e98391
3
+ metadata.gz: 8ae8178b1be1a7d13be61e1a281b95fed49be3fae45f26aff9eb435113e5c1f2
4
+ data.tar.gz: 9c224166b801afc788f73bb01a33cbb86e6189d4e0d1edeaf4ea984774185a5a
5
5
  SHA512:
6
- metadata.gz: 0547572d06d433e4c32f68006300aac09a5b37d85110d501a4a4fb73c966c1faec898e078e7ad5f7f69ef2fac034f94881fcb4c4b8a5fb54f8a0fc6c2c0a6817
7
- data.tar.gz: a1d656a0ebd2288ecdbf4f8060bededba27a6af94d17fe0643f803456739370b1399f4ed7ccd3fac9fd48181b65d5f3d7d89467e0166db42a097fbb48cb1d806
6
+ metadata.gz: 7e3fe1c9405ad49d9f06f478b6bfbd954cc2cb7256eff64d8f79ff09319a4bcb50e86d7a020562abec492be7d8423372e4f3ca2317ae84bc73de8b31ed8f8c46
7
+ data.tar.gz: 74eea6f7ada2d8b4f0492a450ed7243b7b9b590acd186bdda472e0c436bb7d6ed5cc4bba6f9f2955f6f077760fbd7c1b0a08492a33b340da8bc45b7eb50c9845
@@ -1,36 +1,43 @@
1
1
  # Change Log
2
2
  <!-- usage documentation: http://expeditor-docs.es.chef.io/configuration/changelog/ -->
3
- <!-- latest_release 2.2.61 -->
4
- ## [v2.2.61](https://github.com/inspec/inspec/tree/v2.2.61) (2018-08-09)
3
+ <!-- latest_release 2.2.64 -->
4
+ ## [v2.2.64](https://github.com/inspec/inspec/tree/v2.2.64) (2018-08-17)
5
5
 
6
- #### New Resources
7
- - add iis_app_pool resource [#2400](https://github.com/inspec/inspec/pull/2400) ([strocknar](https://github.com/strocknar))
6
+ #### Merged Pull Requests
7
+ - Dummy PR to bump expeditor version. [#3298](https://github.com/inspec/inspec/pull/3298) ([jquick](https://github.com/jquick))
8
8
  <!-- latest_release -->
9
9
 
10
- <!-- release_rollup since=2.2.55 -->
11
- ### Changes since 2.2.55 release
10
+ <!-- release_rollup since=2.2.61 -->
11
+ ### Changes since 2.2.61 release
12
+
13
+ #### Merged Pull Requests
14
+ - Dummy PR to bump expeditor version. [#3298](https://github.com/inspec/inspec/pull/3298) ([jquick](https://github.com/jquick)) <!-- 2.2.64 -->
15
+ - Allow the jsonAutomate report to be executed from cli [#3285](https://github.com/inspec/inspec/pull/3285) ([jquick](https://github.com/jquick)) <!-- 2.2.63 -->
16
+ - Update `only_if` to allow user specified messages. [#3267](https://github.com/inspec/inspec/pull/3267) ([miah](https://github.com/miah)) <!-- 2.2.62 -->
17
+ <!-- release_rollup -->
18
+
19
+ <!-- latest_stable_release -->
20
+ ## [v2.2.61](https://github.com/inspec/inspec/tree/v2.2.61) (2018-08-09)
12
21
 
13
22
  #### New Resources
14
- - add iis_app_pool resource [#2400](https://github.com/inspec/inspec/pull/2400) ([strocknar](https://github.com/strocknar)) <!-- 2.2.61 -->
15
- - Add new resource: aws_ecs_cluster [#3213](https://github.com/inspec/inspec/pull/3213) ([meringu](https://github.com/meringu)) <!-- 2.2.60 -->
23
+ - Add new resource: aws_ecs_cluster [#3213](https://github.com/inspec/inspec/pull/3213) ([meringu](https://github.com/meringu))
24
+ - add iis_app_pool resource [#2400](https://github.com/inspec/inspec/pull/2400) ([strocknar](https://github.com/strocknar))
16
25
 
17
26
  #### Enhancements
18
- - Adding docker plugin support [#3074](https://github.com/inspec/inspec/pull/3074) ([frezbo](https://github.com/frezbo)) <!-- 2.2.58 -->
27
+ - Adding docker plugin support [#3074](https://github.com/inspec/inspec/pull/3074) ([frezbo](https://github.com/frezbo))
19
28
 
20
29
  #### Bug Fixes
21
- - Error cleanly if a reporter errors while rendering [#3280](https://github.com/inspec/inspec/pull/3280) ([jquick](https://github.com/jquick)) <!-- 2.2.59 -->
22
- - Add support in aws_route_table to allow 17 hexadecimal characters [#3277](https://github.com/inspec/inspec/pull/3277) ([kchistova](https://github.com/kchistova)) <!-- 2.2.57 -->
30
+ - Add support in aws_route_table to allow 17 hexadecimal characters [#3277](https://github.com/inspec/inspec/pull/3277) ([kchistova](https://github.com/kchistova))
31
+ - Error cleanly if a reporter errors while rendering [#3280](https://github.com/inspec/inspec/pull/3280) ([jquick](https://github.com/jquick))
23
32
 
24
33
  #### Merged Pull Requests
25
- - Enable inspec archive, check, and json to run as unpriveleged user [#3263](https://github.com/inspec/inspec/pull/3263) ([phiggins](https://github.com/phiggins)) <!-- 2.2.56 -->
26
- <!-- release_rollup -->
27
-
34
+ - Enable inspec archive, check, and json to run as unpriveleged user [#3263](https://github.com/inspec/inspec/pull/3263) ([phiggins](https://github.com/phiggins))
28
35
  <!-- latest_stable_release -->
36
+
29
37
  ## [v2.2.55](https://github.com/inspec/inspec/tree/v2.2.55) (2018-08-03)
30
38
 
31
39
  #### Enhancements
32
40
  - Add a merged json report for A2 [#3261](https://github.com/inspec/inspec/pull/3261) ([jquick](https://github.com/jquick))
33
- <!-- latest_stable_release -->
34
41
 
35
42
  ## [v2.2.54](https://github.com/inspec/inspec/tree/v2.2.54) (2018-08-02)
36
43
 
data/README.md CHANGED
@@ -453,4 +453,3 @@ distributed under the License is distributed on an "AS IS" BASIS,
453
453
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
454
454
  See the License for the specific language governing permissions and
455
455
  limitations under the License.
456
-
@@ -0,0 +1,321 @@
1
+ # Developing InSpec Plugins for the v2 plugin API
2
+
3
+ ## Introduction
4
+
5
+ ### Inspiration
6
+
7
+ The software design of the InSpec Plugin v2 API is deeply inspired by the Vagrant plugin v2 system. While the InSpec Plugin v2 system is an independent implementation, acknowledgements are due to the Hashicorp team for such a well-thought-out design.
8
+
9
+ ### Note About versions
10
+
11
+ "v2" refers to the second major version of the Plugin API. It doesn't refer to the InSpec release number.
12
+
13
+ ### Design Goals
14
+
15
+ * Load-on-demand. Improve `inspec` startup time by making plugins load heavy libraries only if they are being used.
16
+ * Independent velocity. Enable passionate community members to contribute at their own pace by shifting core development into plugin development
17
+ * Increase dogfooding. Convert internal components into plugins to reduce core complexity and allow testing in isolation
18
+
19
+ ### Design Anti-goals
20
+
21
+ * Don't implement resources in plugins; use resource packs for that.
22
+
23
+ ## How Plugins are Located and Loaded
24
+
25
+ ### Plugins are usually gems
26
+
27
+ The normal distribution and installation method is via gems, handled by the `inspec plugin` command.
28
+
29
+ TODO: give basic overview of `inspec plugin` and link to docs
30
+
31
+ ### Plugins may also be found by path
32
+
33
+ For local development or site-specific installations, you can also 'install' a plugin by path using `inspec plugin`, or edit `~/.inspec/plugins.json` directly to add a plugin.
34
+
35
+ ### The plugins.json file
36
+
37
+ InSpec stores its list of known plugins in a file, `~/.inspec/plugins.json`. The purpose of this file is avoid having to do a gem path filesystem scan to locate plugins. When you install, update, or uninstall a plugin using `inspec plugin`, InSpec updates this file.
38
+
39
+ You can tell inspec to use a different config directory using the INSPEC_CONFIG_DIR environment variable.
40
+
41
+ Top-level entries in the JSON file:
42
+
43
+ * `plugins_config_version` - must have the value "1.0.0". Reserved for future format changes.
44
+ * `plugins` - an Array of Hashes, each containing information about plugins that are expected to be installed
45
+
46
+ Each plugin entry may have the following keys:
47
+
48
+ * `name` - Required. String name of the plugin. Internal machine name of the plugin. Must match `plugin_name` DSL call (see Plugin class below).
49
+ * `installation_type` - Optional, default "gem". Selects a loading mechanism, may be either "path" or "gem"
50
+ * `installation_path` - Required if installation_type is "path". A `require` will be attempted against this path. It may be absolute or relative; InSpec adds both the process current working directory as well as the InSpec installation root to the load path.
51
+
52
+ TODO: keys for gem installations
53
+
54
+ Putting this all together, here is a plugins.json file from the InSpec test suite:
55
+
56
+ ```json
57
+ {
58
+ "plugins_config_version" : "1.0.0",
59
+ "plugins": [
60
+ {
61
+ "name": "inspec-meaning-of-life",
62
+ "installation_type": "path",
63
+ "installation_path": "test/unit/mock/plugins/meaning_of_life_path_mode/inspec-meaning-of-life"
64
+ }
65
+ ]
66
+ }
67
+ ```
68
+
69
+ ## Plugin Parts
70
+
71
+ ### A Typical Plugin File Layout
72
+
73
+ ```
74
+ inspec-my-plugin.gemspec
75
+ lib/
76
+ inspec-my-plugin.rb # Entry point
77
+ inspec-my-plugin/
78
+ cli.rb # An implementation file
79
+ plugin.rb # Plugin definition file
80
+ heavyweight.rb # A support file
81
+ ```
82
+
83
+ Generally, except for the entry point, you may name these files anything you like; however, the above example is the typical convention.
84
+
85
+ ### Gemspec and Plugin Dependencies
86
+
87
+ This is a normal Gem specification file. When you release your plugin as a gem, you can declare dependencies here, and InSpec will automatically install them along with your plugin.
88
+
89
+ If you are using a path-based install, InSpec will not manage your dependencies.
90
+
91
+ ### Entry Point
92
+
93
+ The entry point is the file that will be `require`d at load time (*not* activation time; see Plugin Lifecycle, below). You should load the bare minimum here - only the plugin definition file. Do not load any plugin dependencies in this file.
94
+
95
+ ```ruby
96
+ # lib/inspec-my-plugin.rb
97
+ require_relative 'inspec-my-plugin/plugin'
98
+ ```
99
+
100
+ ### Plugin Definition File
101
+
102
+ The plugin definition file uses the plugin DSL to declare a small amount of metadata, followed by as many activation hooks as your plugin needs.
103
+
104
+ While you may use any valid Ruby module name, we encourage you to namespace your plugin under `InspecPlugins::YOUR_PLUGIN`.
105
+
106
+ ```ruby
107
+ # lib/inspec-my-plugin/plugin.rb
108
+ module InspecPlugins
109
+ module MyPlugin
110
+ # Class name doesn't matter, but this is a reasonable default name
111
+ class PluginDefinition < Inspec.plugin(2)
112
+
113
+ # Metadata
114
+ # Must match entry in plugins.json
115
+ plugin_name :'inspec-my-plugin'
116
+
117
+ # Activation hooks (CliCommand as an example)
118
+ cli_command :'my-command' do
119
+ require_relative 'cli'
120
+ InspecPlugins::MyPlugin::CliCommand
121
+ end
122
+
123
+ end
124
+ end
125
+ end
126
+ ```
127
+
128
+ Note that the block passed to `cli_command` is not executed when the plugin definition is loaded. It will only be executed if inspec decides it needs to activate that plugin component.
129
+
130
+ Every activation hook is expected to return a `Class` which will be used in post-activation or execution phases. The behavior, duck typing, and superclass of that Class vary depending on the plugin type; see below for details.
131
+
132
+ ### Implementation Files
133
+
134
+ Inside the implementation files, you should be sure to do three things:
135
+
136
+ 1. Load any heavyweight libraries your plugin needs
137
+ 2. Create a class (which you will return from the activator hook)
138
+ 3. Within the class, implement your functionality, as dictated by the plugin type API
139
+
140
+ ```ruby
141
+ # lib/inspec-my-plugin/cli.rb
142
+
143
+ # Load enormous dependencies
144
+ require_relative 'heavyweight'
145
+
146
+ module InspecPlugin::MyPlugin
147
+ # Class name doesn't matter, but this is a reasonable default name
148
+ class CliCommand < Inspec.plugin(2, :cli_command) # Note two-arg form
149
+ # Implement API or use DSL as dictated by cli_command plugin type
150
+ # ...
151
+ end
152
+ end
153
+ ```
154
+
155
+ ## Plugin Lifecycle
156
+
157
+ All queries regarding plugin state should be directed to `Inspec::Plugin::V2::Registry.instance`, a singleton object.
158
+
159
+ ```ruby
160
+ registry = Inspec::Plugin::V2::Registry.instance
161
+ plugin_status = registry[:'inspec-meaning-of-life']
162
+ ```
163
+
164
+ ### Discovery (Known Plugins)
165
+
166
+ If a plugin is mentioned in `plugins.json` or is a plugin distributed with InSpec itself, it is *known*. You can get its status, a `Inspec::Plugin::V2::Status` object.
167
+
168
+ Reading the plugins.json file is handled by the Loader when Loader.new is called; at that point the registry should know about plugins.
169
+
170
+ ### Loading
171
+
172
+ Next, we load plugins. Loading means that we `require` the entry point determined from the plugins.json. Your plugin definition file will thus execute.
173
+
174
+ If things go right, the Status now has a bunch of Activators, each with a block that has not yet executed.
175
+
176
+ If things go wrong, have a look at `status.load_exception`.
177
+
178
+ ### Activation and Execution
179
+
180
+ Depending on the plugin type, activation may be triggered by a number of different events. For example, CliCommand plugin types are activated when their activation name is mentioned in the command line arguments.
181
+
182
+ After activation, code for that aspect of the plugin is loaded and ready to execute. Execution may be triggered by a number of different events. For example, the CliCommand plugin types are implicitly executed by Thor when `Inspec::CLI` calls `start()`.
183
+
184
+ Refer to the sections below for details about activation and execution timing.
185
+
186
+ ## Implementing a CLI Command Plugin
187
+
188
+ The CliCommand plugin_type allows you to extend the InSpec command line interface by adding a namespace of new commands. InSpec is based on [Thor](http://whatisthor.com/) ([docs](https://www.rubydoc.info/github/wycats/thor/Thor)), and the plugin system exposes Thor directly.
189
+
190
+ CliCommand can do things like:
191
+
192
+ ```bash
193
+ # A namespaced custom command with options
194
+ you@machine$ inspec sweeten add --kind sugar --teaspoons 2
195
+ # A namespaced custom command with short options
196
+ you@machine$ inspec sweeten add -k agave
197
+ # Mix global and namespace options
198
+ you@machine$ inspec --debug sweeten add -k aspartame
199
+ # Namespace included in help
200
+ you@machine$ inspec help
201
+ Commands:
202
+ inspec archive PATH # archive a profile to tar.gz (default) or zip
203
+ inspec sweeten ... # Add spoonfuls til the medicine goes down
204
+ # Detailed help
205
+ [cwolfe@lodi inspec-plugins]$ inspec help sweeten
206
+ Commands:
207
+ inspec sweeten add [opts] # Adds sweetener to your beverage
208
+ inspec sweeten count # Reports on teaspoons in your beverage, always bad news
209
+ ```
210
+
211
+ Currently, it cannot create a direct (non-namespaced) command, such as `inspec mycommand` with no subcommands.
212
+
213
+ ### Declare your plugin activators
214
+
215
+ In your `plugin.rb`, include one or more `cli_command` activation blocks. The activation block name will be matched against the command line arguments; if the name is present, your activator will fire (in which case it should load any needed libraries) and should return your implementation class.
216
+
217
+ #### CliCommand Activator Example
218
+
219
+ ```ruby
220
+
221
+ # In plugin.rb
222
+ module InspecPlugins::Sweeten
223
+ class Plugin < Inspec.plugin(2)
224
+ # ... other plugin stuff
225
+
226
+ cli_command :sweeten do
227
+ require_relative 'cli.rb'
228
+ InspecPlugins::Sweeten::CliCommand
229
+ end
230
+ end
231
+ end
232
+ ```
233
+
234
+ Like any activator, the block above will only be called if needed. For CliCommand plugins, the plugin system naively scans through ARGV, looking for the activation name as a whole element. Multiple CliCommand activations may occur if several different names match, though each activation will only occur once.
235
+
236
+ ```bash
237
+ you@machine $ inspec sweeten ... # Your CliCommand implementation is activated and executed
238
+ you@machine $ inspec exec ... # Your CliCommand implementation is not activated
239
+ ```
240
+
241
+ Execution occurs implicitly via `Thor.start()`, which is handled by `bin/inspec`. Keep reading.
242
+
243
+ You should also be aware of one other activation event: if the CLI is invoked as `inspec help`, *all* CliCommand plugins will activate (but will not be executed). This is so that each plugin's help information can be registered with Thor.
244
+
245
+ ### Implementation class for CLI Commands
246
+
247
+ In your `cli.rb`, you should begin by requesting the superclass from `Inspec.plugin`:
248
+
249
+ ```ruby
250
+ module InspecPlugins::Sweeten
251
+ class CliCommand < Inspec.plugin(2, :cli_command)
252
+ # ...
253
+ end
254
+ end
255
+ ```
256
+
257
+ The Inspec plugin v2 system promises the following:
258
+
259
+ * The superclass will be an (indirect) subclass of Thor
260
+ * The plugin system will handle registering the subcommand with Thor for you
261
+ * The plugin system will handle setup of the subcommand help message for you
262
+
263
+ ### Implementing your command
264
+
265
+ Within your `cli.rb`, you need to do two things:
266
+
267
+ * Inform Inspec of your subcommand's usage and description, so the `help` commands will work properly
268
+ * Implement your subcommands and options using the Thor DSL
269
+
270
+ See also: [Thor homepage](http://whatisthor.com/) and [Thor docs](https://www.rubydoc.info/github/wycats/thor/Thor).
271
+
272
+ #### Call subcommand_desc
273
+
274
+ Within your implementation, make a call like this:
275
+
276
+ ```ruby
277
+ # Class declaration as above
278
+ subcommand_desc 'sweeten ...', 'Add spoonfuls til the medicine goes down'
279
+ ```
280
+
281
+ The first argument is the usage message; it will be displayed whenever you execute `inspec help`, or when Thor tries to parse a malformed `inspec sweeten ...` command.
282
+
283
+ The second is the command groups description, and is displayed with `inspec help`.
284
+
285
+ Both arguments are free-form Strings intended for humans; the usage message should begin with your subcommand name to prevent user confusion.
286
+
287
+ If you neglect to call this DSL method, Thor will not register your command.
288
+
289
+ #### Adding Subcommands
290
+
291
+ The minimum needed for a command is a call to `desc` to set the help message, and a method definition named after the command.
292
+
293
+ ```ruby
294
+ desc 'Reports on teaspoons in your beverage, always bad news'
295
+ def count
296
+ # Someone has executed `inspec sweeten count` - do whatever that entails
297
+ case beverage_type
298
+ when :soda
299
+ puts 12
300
+ when :tea_two_lumps
301
+ puts 2
302
+ end
303
+ end
304
+ ```
305
+
306
+ There is a great deal more you can do with Thor, especially concerning handling options. Refer to the Thor docs for more examples and details.
307
+
308
+ #### Using no_command
309
+
310
+ One common surprise seen with Thor is that every public instance method of your CliCommand implementation class is expected to be a CLI command definition. Thor will issue a warning if it encounters a public method definition without a `desc` call preceding it. Two ways around this include:
311
+
312
+ * Make your helper methods private
313
+ * Enclose your non-command methods in a no_command block (a feature of Thor just for this circumstance)
314
+
315
+ ```ruby
316
+ no_command do
317
+ def beverage_type
318
+ @bevvy
319
+ end
320
+ end
321
+ ```
@@ -81,12 +81,23 @@ $ inspec check examples/profile
81
81
 
82
82
  # Platform Support
83
83
 
84
- Use the `supports` setting in the `inspec.yml` file to specify one (or more) platforms for which a profile is targeting. The list of supported platforms may contain simple names, names and versions, or detailed flags, and may be combined arbitrarily. For example, to target anything running Debian Linux:
84
+ Use the `supports` setting in the `inspec.yml` file to specify one (or more) platforms for which a profile is targeting. The list of supported platforms may contain the following:
85
+
86
+ * Use `platform-family` to restrict to a specific platform family.
87
+ * Use `platform-name` to restrict on a specific platform name.
88
+ * Use `release` to restrict to a specific platform version (used with platform-name).
89
+ * Use `platform` to restrict on either platform-name or platform-family.
90
+
91
+ For compatibility we support `os-name` and `os-family`. We recommend all users to change `os-name` to `platform-name` and `os-family` to `platform-family`.
92
+
93
+ With InSpec 2.0, we introduced new families to help distinguish the cloud platforms. The new families can restrict the platform family to `os`, `aws`, `azure` or `gcp`.
94
+
95
+ For example, to target anything running Debian Linux:
85
96
 
86
97
  ```YAML
87
98
  name: ssh
88
99
  supports:
89
- - os-name: debian
100
+ - platform-name: debian
90
101
  ```
91
102
 
92
103
  and to target only Ubuntu version 14.04
@@ -94,7 +105,7 @@ and to target only Ubuntu version 14.04
94
105
  ```YAML
95
106
  name: ssh
96
107
  supports:
97
- - os-name: ubuntu
108
+ - platform-name: ubuntu
98
109
  release: 14.04
99
110
  ```
100
111
 
@@ -103,7 +114,7 @@ and to target the entire RedHat platform (including CentOS and Oracle Linux):
103
114
  ```YAML
104
115
  name: ssh
105
116
  supports:
106
- - os-family: redhat
117
+ - platform-family: redhat
107
118
  ```
108
119
 
109
120
  and to target anything running on Amazon AWS:
@@ -119,10 +130,10 @@ and to target all of these examples in a single `inspec.yml` file:
119
130
  ```YAML
120
131
  name: ssh
121
132
  supports:
122
- - os-name: debian
123
- - os-name: ubuntu
133
+ - platform-name: debian
134
+ - platform-name: ubuntu
124
135
  release: 14.04
125
- - os-family: redhat
136
+ - platform-family: redhat
126
137
  - platform: aws
127
138
  ```
128
139
 
@@ -226,9 +237,7 @@ Once defined in the `inspec.yml`, controls from the included profiles can be use
226
237
 
227
238
  With the `include_controls` command in a profile, all controls from the named profile will be executed every time the including profile is executed.
228
239
 
229
- ```YAML
230
240
  ![Include Controls](/images/profile_inheritance/include_controls.png)
231
- ```
232
241
 
233
242
  In the example above, every time `my-app-profile` is executed, all the controls from `my-baseline` are also executed. Therefore, the following controls would be executed:
234
243
 
@@ -245,9 +254,8 @@ including controls from other profiles!
245
254
 
246
255
  What if one of the controls from the included profile does not apply to your environment? Luckily, it is not necessary to maintain a slightly-modified copy of the included profile just to delete a control. The `skip_control` command tells InSpec to not run a particular control.
247
256
 
248
- ```YAML
249
257
  ![Include Controls with Skip](/images/profile_inheritance/include_controls_with_skip.png)
250
- ```
258
+
251
259
 
252
260
  In the above example, all controls from `my-app-profile` and `my-baseline` profile will be executed every time `my-app-profile` is executed **except** for control `baseline-2` from the `my-baseline` profile.
253
261
 
@@ -257,9 +265,7 @@ Let's say a particular control from an included profile should still be run, but
257
265
 
258
266
  When a control is included, it can also be modified!
259
267
 
260
- ```YAML
261
268
  ![Include Controls with Modification](/images/profile_inheritance/include_controls_with_mod.png)
262
- ```
263
269
 
264
270
  In the above example, all controls from `my-baseline` are executed along with all the controls from the including profile, `my-app-profile`. However, should control `baseline-1` fail, it will be raised with an impact of `0.5` instead of the originally-intended impact of `1.0`.
265
271
 
@@ -267,9 +273,7 @@ In the above example, all controls from `my-baseline` are executed along with al
267
273
 
268
274
  If there are only a handful of controls that should be executed from an included profile, it's not necessarily to skip all the unneeded controls, or worse, copy/paste those controls bit-for-bit into your profile. Instead, use the `require_controls` command.
269
275
 
270
- ```YAML
271
276
  ![Require Controls](/images/profile_inheritance/require_controls.png)
272
- ```
273
277
 
274
278
  Whenever `my-app-profile` is executed, in addition to its own controls, it will run only the controls specified in the `require_controls` block. In the case, the following controls would be executed:
275
279
 
@@ -283,9 +287,7 @@ Controls `baseline-1`, `baseline-3`, and `baseline-5` would not be run, just as
283
287
 
284
288
  And, just the way its possible to modify controls when using `include_controls`, controls can be modified as well.
285
289
 
286
- ```YAML
287
290
  ![Require Controls with Modification](/images/profile_inheritance/require_controls_with_mod.png)
288
- ```
289
291
 
290
292
  As with the prior example, only `baseline-2` and `baseline-4` are executed, but if `baseline-2` fails, it will report with an impact of `0.5` instead of the originally-intended `1.0` impact.
291
293
 
@@ -436,4 +438,4 @@ end
436
438
  ```text
437
439
  test file
438
440
  ✔ should be a file
439
- ```
441
+ ```