mirror of
https://github.com/inspec/inspec
synced 2024-11-10 15:14:23 +00:00
Merge pull request #5746 from inspec/vasundhara/update-docs-for-resource-properties
Fix docs to make property listing in the website docs more useful.
This commit is contained in:
commit
a09690fde6
29 changed files with 575 additions and 603 deletions
|
@ -170,8 +170,6 @@ Beginning with Chef InSpec 1.41, you can enable the ability to have the HTTP tes
|
|||
|
||||
## Properties
|
||||
|
||||
- `body`, `headers`, `http_method`, `status`
|
||||
|
||||
### body
|
||||
|
||||
The `body` property tests body content of http response:
|
||||
|
|
|
@ -54,8 +54,6 @@ For example:
|
|||
|
||||
## Properties
|
||||
|
||||
## Examples
|
||||
|
||||
### application pool
|
||||
|
||||
`application_pool` property returns the name of the application pool in which the site's root application is run, such as `DefaultAppPool`.
|
||||
|
|
|
@ -40,10 +40,6 @@ An `interface` resource block declares network interface properties to be tested
|
|||
|
||||
## Properties
|
||||
|
||||
`ipv4_address`, `ipv4_addresses`, `ipv4_addresses_netmask`, `ipv4_cidrs`, `ipv6_addresses`, `ipv6_cidrs`, `name`, `speed`
|
||||
|
||||
## Resource Property Examples
|
||||
|
||||
### ipv4_address
|
||||
|
||||
Returns the first `ipv4_addresses` entry as a String. Note: this property is incompatible with ServerSpec, which returns the value including the CIDR range, such as '10.0.0.5/32'.
|
||||
|
|
|
@ -44,10 +44,6 @@ You can use an optional passphrase with `key_rsa`
|
|||
|
||||
## Properties
|
||||
|
||||
- `public_key`, `private_key`, `key_length`
|
||||
|
||||
## Property Examples
|
||||
|
||||
### public_key (String)
|
||||
|
||||
The `public_key` property returns the public part of the RSA key pair
|
||||
|
|
|
@ -53,19 +53,13 @@ where
|
|||
|
||||
## Properties
|
||||
|
||||
- `domain`
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
||||
### domain
|
||||
|
||||
The `domain` property tests the domain in the `limits.conf` file, along with associated type, item, and value:
|
||||
|
||||
its('domain') { should include ['type', 'item', 'value'] }
|
||||
|
||||
`
|
||||
|
||||
For example:
|
||||
|
||||
its('grantmc') { should include ['hard', 'nofile', '63536'] }
|
||||
|
|
|
@ -48,6 +48,12 @@ where
|
|||
- `('path')` is the non-default path to the `my.cnf` file
|
||||
- `should eq 'value'` is the value that is expected
|
||||
|
||||
## Properties
|
||||
|
||||
This resource supports any settings listed in a `my.cnf` file as properties. For example, `max_connections`.
|
||||
|
||||
its('max_connections') { should eq '505' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -99,11 +105,3 @@ The following examples show how to use this Chef InSpec audit resource.
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
### setting
|
||||
|
||||
The `setting` matcher tests specific, named settings in the `my.cnf` file:
|
||||
|
||||
its('setting') { should eq 'value' }
|
||||
|
||||
Use a `setting` matcher for each setting to be tested.
|
||||
|
|
|
@ -37,9 +37,18 @@ where
|
|||
- `('path')` is the non-default path to the `ntp.conf` file
|
||||
- `{ should eq 'value' }` is the value that is expected
|
||||
|
||||
## Properties
|
||||
|
||||
This resource supports any of the settings listed in an `ntp.conf` file as properties.
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
The following examples show how to use this Chef InSpec audit resource
|
||||
|
||||
describe ntp_conf do
|
||||
its('server') { should_not eq nil }
|
||||
its('restrict') { should include '-4 default kod notrap nomodify nopeer noquery'}
|
||||
end
|
||||
|
||||
### Test for clock drift against named servers
|
||||
|
||||
|
@ -56,17 +65,5 @@ The following examples show how to use this Chef InSpec audit resource.
|
|||
|
||||
## Matchers
|
||||
|
||||
This resource matches any service that is listed in the `ntp.conf` file. For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
its('server') { should_not eq nil }
|
||||
|
||||
or:
|
||||
|
||||
its('restrict') { should include '-4 default kod notrap nomodify nopeer noquery'}
|
||||
|
||||
For example:
|
||||
|
||||
describe ntp_conf do
|
||||
its('server') { should_not eq nil }
|
||||
its('restrict') { should include '-4 default kod notrap nomodify nopeer noquery'}
|
||||
end
|
||||
|
|
|
@ -36,6 +36,14 @@ where
|
|||
- `('name')` must specify the name of a package, such as `'VLC'`
|
||||
- `be_installed` is a valid matcher for this resource
|
||||
|
||||
## Properties
|
||||
|
||||
### version
|
||||
|
||||
The `version` property tests if the named package version is on the system:
|
||||
|
||||
its('version') { should eq '1.2.3' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -56,8 +64,3 @@ The `be_installed` matcher tests if the named package is installed on the system
|
|||
|
||||
it { should be_installed }
|
||||
|
||||
### version
|
||||
|
||||
The `version` matcher tests if the named package version is on the system:
|
||||
|
||||
its('version') { should eq '1.2.3' }
|
||||
|
|
|
@ -45,6 +45,20 @@ The URL of the OPA API server.
|
|||
|
||||
An OPA query as a JSON data file or a string in JSON format.
|
||||
|
||||
## Properties
|
||||
|
||||
### result
|
||||
|
||||
The `result` property checks whether the resource query returns an empty result.
|
||||
|
||||
its('result') { should be nil }
|
||||
|
||||
### allow
|
||||
|
||||
The `allow` property checks if a specific input matches the policy defined in OPA. This matcher will not work if `allow` is not defined in the policy file.
|
||||
|
||||
its('allow') { should eq 'value' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -60,17 +74,3 @@ The above example shows how the `allow` value can be fetched in two ways.
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
## Properties
|
||||
|
||||
### result
|
||||
|
||||
The `result` property checks whether the resource query returns an empty result.
|
||||
|
||||
its('result') { should be nil }
|
||||
|
||||
### allow
|
||||
|
||||
The `allow` property checks if specific input is as per the policy defined in OPA. If `allow` is not defined in the policy file then this matcher will not work.
|
||||
|
||||
its('allow') { should eq 'value' }
|
||||
|
|
|
@ -54,6 +54,20 @@ The query to be evaluated against policy and input data.
|
|||
|
||||
This is the full path to the OPA binary or EXE file used for running the OPA CLI or OPA commands. By default it will consider that the path is added in PATH variable.
|
||||
|
||||
## Properties
|
||||
|
||||
### result
|
||||
|
||||
The `result` property checks whether the resource query returns an empty result.
|
||||
|
||||
its('result') { should be nil }
|
||||
|
||||
### allow
|
||||
|
||||
The `allow` property checks if specific input matches the policy defined in OPA. This matcher will not work if `allow` is not defined in the policy file.
|
||||
|
||||
its('allow') { should eq 'value' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource:
|
||||
|
@ -69,17 +83,3 @@ The above example shows how the `allow` value can be fetched in two ways.
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
## Properties
|
||||
|
||||
### result
|
||||
|
||||
The `result` property checks whether the resource query returns an empty result.
|
||||
|
||||
its('result') { should be nil }
|
||||
|
||||
### allow
|
||||
|
||||
The `allow` property checks if specific input is as per the policy defined in OPA. If `allow` is not defined in the policy file then this matcher will not work.
|
||||
|
||||
its('allow') { should eq 'value' }
|
||||
|
|
|
@ -36,6 +36,21 @@ where
|
|||
- `('name')` must specify the name of a package, such as `'nginx'`
|
||||
- `be_installed` is a valid matcher for this resource
|
||||
|
||||
## Properties
|
||||
|
||||
### version
|
||||
|
||||
The `version` property tests if the named package version is on the system:
|
||||
|
||||
its('version') { should eq '1.2.3' }
|
||||
|
||||
You can also use the `cmp` matcher to perform comparisons using the version attribute:
|
||||
|
||||
its('version') { should cmp >= '7.35.0-1ubuntu3.10' }
|
||||
|
||||
`cmp` understands version numbers using Gem::Version, and can use the operators `==, <, <=, >=, and >`. It will compare versions by each segment, not as a string - so '7.4' is smaller than '7.30', for example.
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -116,15 +131,3 @@ will not be upgraded to a later version.
|
|||
The `be_installed` matcher tests if the named package is installed on the system:
|
||||
|
||||
it { should be_installed }
|
||||
|
||||
### version
|
||||
|
||||
The `version` matcher tests if the named package version is on the system:
|
||||
|
||||
its('version') { should eq '1.2.3' }
|
||||
|
||||
You can also use the `cmp OPERATOR` matcher to perform comparisons using the version attribute:
|
||||
|
||||
its('version') { should cmp >= '7.35.0-1ubuntu3.10' }
|
||||
|
||||
`cmp` understands version numbers using Gem::Version, and can use the operators `==, <, <=, >=, and >`. It will compare versions by each segment, not as a string - so '7.4' is smaller than '7.30', for example.
|
||||
|
|
|
@ -31,6 +31,26 @@ A `packages` resource block declares a regular expression search to select packa
|
|||
its('statuses') { should cmp 'installed' }
|
||||
end
|
||||
|
||||
## Properties
|
||||
|
||||
### statuses
|
||||
|
||||
The `statuses` property tests if packages are installed on the system:
|
||||
|
||||
its('statuses') { should cmp 'installed' }
|
||||
|
||||
### versions
|
||||
|
||||
The `versions` property tests the versions of the packages installed on the system
|
||||
|
||||
its('versions') { should cmp '3.4.0.2-4.el7' }
|
||||
|
||||
### architectures
|
||||
|
||||
The `architectures` property tests the architecture of packages installed on the system
|
||||
|
||||
its('architectures') { should include 'i686' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -57,21 +77,3 @@ The following examples show how to use this Chef InSpec audit resource.
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
### statuses
|
||||
|
||||
The `statuses` matcher tests if packages are installed on the system
|
||||
|
||||
its('statuses') { should cmp 'installed' }
|
||||
|
||||
### versions
|
||||
|
||||
The `versions` matcher tests the versions of the packages installed on the system
|
||||
|
||||
its('versions') { should cmp '3.4.0.2-4.el7' }
|
||||
|
||||
### architectures
|
||||
|
||||
The `architectures` matcher tests the architecture of packages installed on the system
|
||||
|
||||
its('architectures') { should include 'i686' }
|
||||
|
|
|
@ -54,6 +54,77 @@ where
|
|||
- `filter` one (or more) arguments, for example: `passwd.users(/name/)` used to define filtering
|
||||
- `filter` may take any of the following arguments: `count` (retrieves the number of entries), `lines` (provides raw `passwd` lines), and `params` (returns an array of maps for all entries)
|
||||
|
||||
## Properties
|
||||
|
||||
### gids
|
||||
|
||||
The `gids` property tests if the group indentifiers in the test match group identifiers in `/etc/passwd`:
|
||||
|
||||
its('gids') { should include 1234 }
|
||||
its('gids') { should cmp 0 }
|
||||
|
||||
### homes
|
||||
|
||||
The `homes` property tests the absolute path to a user's home directory:
|
||||
|
||||
its('home') { should eq '/' }
|
||||
|
||||
### length
|
||||
|
||||
The `length` property tests the length of a password that appears in `/etc/passwd`:
|
||||
|
||||
its('length') { should be <= 32 }
|
||||
|
||||
This matcher is best used in conjunction with filters. For example:
|
||||
|
||||
describe passwd.users('highlander') do
|
||||
its('length') { should_not be < 16 }
|
||||
end
|
||||
|
||||
### passwords
|
||||
|
||||
The `passwords` property tests if passwords are
|
||||
|
||||
- Encrypted
|
||||
- Have direct logins disabled, as indicated by an asterisk (`*`)
|
||||
- In the `/etc/shadow` file, as indicated by the letter x (`x`)
|
||||
|
||||
For example:
|
||||
|
||||
its('passwords') { should eq ['x'] }
|
||||
its('passwords') { should cmp '*' }
|
||||
|
||||
### shells
|
||||
|
||||
The `shells` property tests the absolute path of a shell (or command) to which a user has access:
|
||||
|
||||
its('shells') { should_not include 'user' }
|
||||
|
||||
or to find all users with the nologin shell:
|
||||
|
||||
describe passwd.shells(/nologin/) do
|
||||
its('users') { should_not include 'my_login_user' }
|
||||
end
|
||||
|
||||
### uids
|
||||
|
||||
The `uids` property tests if the user identifiers in the test match user identifiers in `/etc/passwd`:
|
||||
|
||||
its('uids') { should eq ['1234', '1235'] }
|
||||
|
||||
or:
|
||||
|
||||
describe passwd.uids(0) do
|
||||
its('users') { should cmp 'root' }
|
||||
its('count') { should eq 1 }
|
||||
end
|
||||
|
||||
### users
|
||||
|
||||
The `users` property tests if the user names in the test match user names in `/etc/passwd`:
|
||||
|
||||
its('users') { should eq ['root', 'www-data'] }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -80,72 +151,3 @@ The following examples show how to use this Chef InSpec audit resource.
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
### gids
|
||||
|
||||
The `gids` matcher tests if the group indentifiers in the test match group identifiers in `/etc/passwd`:
|
||||
|
||||
its('gids') { should include 1234 }
|
||||
its('gids') { should cmp 0 }
|
||||
|
||||
### homes
|
||||
|
||||
The `homes` matcher tests the absolute path to a user's home directory:
|
||||
|
||||
its('home') { should eq '/' }
|
||||
|
||||
### length
|
||||
|
||||
The `length` matcher tests the length of a password that appears in `/etc/passwd`:
|
||||
|
||||
its('length') { should be <= 32 }
|
||||
|
||||
This matcher is best used in conjunction with filters. For example:
|
||||
|
||||
describe passwd.users('highlander') do
|
||||
its('length') { should_not be < 16 }
|
||||
end
|
||||
|
||||
### passwords
|
||||
|
||||
The `passwords` matcher tests if passwords are
|
||||
|
||||
- Encrypted
|
||||
- Have direct logins disabled, as indicated by an asterisk (`*`)
|
||||
- In the `/etc/shadow` file, as indicated by the letter x (`x`)
|
||||
|
||||
For example:
|
||||
|
||||
its('passwords') { should eq ['x'] }
|
||||
its('passwords') { should cmp '*' }
|
||||
|
||||
### shells
|
||||
|
||||
The `shells` matcher tests the absolute path of a shell (or command) to which a user has access:
|
||||
|
||||
its('shells') { should_not include 'user' }
|
||||
|
||||
or to find all users with the nologin shell:
|
||||
|
||||
describe passwd.shells(/nologin/) do
|
||||
its('users') { should_not include 'my_login_user' }
|
||||
end
|
||||
|
||||
### uids
|
||||
|
||||
The `uids` matcher tests if the user identifiers in the test match user identifiers in `/etc/passwd`:
|
||||
|
||||
its('uids') { should eq ['1234', '1235'] }
|
||||
|
||||
or:
|
||||
|
||||
describe passwd.uids(0) do
|
||||
its('users') { should cmp 'root' }
|
||||
its('count') { should eq 1 }
|
||||
end
|
||||
|
||||
### users
|
||||
|
||||
The `users` matcher tests if the user names in the test match user names in `/etc/passwd`:
|
||||
|
||||
its('users') { should eq ['root', 'www-data'] }
|
||||
|
|
|
@ -36,6 +36,14 @@ where
|
|||
- `'package_name'` is the name of the package, such as `'Jinja2'`
|
||||
- `be_installed` tests to see if the package described above is installed
|
||||
|
||||
## Properties
|
||||
|
||||
### version
|
||||
|
||||
The `version` property tests if the named package version is on the system:
|
||||
|
||||
its('version') { should eq '1.2.3' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -70,8 +78,3 @@ The `be_installed` matcher tests if the named package is installed on the system
|
|||
|
||||
it { should be_installed }
|
||||
|
||||
### version
|
||||
|
||||
The `version` matcher tests if the named package version is on the system:
|
||||
|
||||
its('version') { should eq '1.2.3' }
|
||||
|
|
|
@ -52,6 +52,42 @@ For example, to test if the SSH daemon is available on a Linux machine via the d
|
|||
its('addresses') { should include '0.0.0.0' }
|
||||
end
|
||||
|
||||
## Properties
|
||||
|
||||
### address
|
||||
|
||||
The `addresses` property tests if the specified address is associated with a port:
|
||||
|
||||
its('addresses') { should include '0.0.0.0' }
|
||||
|
||||
### be_listening
|
||||
|
||||
The `be_listening` property tests if the port is listening for traffic:
|
||||
|
||||
it { should be_listening }
|
||||
|
||||
### pids
|
||||
|
||||
The `pids` property tests the process identifiers (PIDs):
|
||||
|
||||
its('pids') { should cmp 27808 }
|
||||
|
||||
### processes
|
||||
|
||||
The `processes` property tests if the named process is running on the system:
|
||||
|
||||
its('processes') { should cmp 'syslog' }
|
||||
|
||||
### protocols
|
||||
|
||||
The `protocols` property tests the Internet protocol: ICMP (`'icmp'`), TCP (`'tcp'` or `'tcp6'`), or UDP (`'udp'` or `'udp6'`):
|
||||
|
||||
its('protocols') { should include 'tcp' }
|
||||
|
||||
or for the IPv6 protocol:
|
||||
|
||||
its('protocols') { should include 'tcp6' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -111,37 +147,3 @@ or:
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
### address
|
||||
|
||||
The `addresses` matcher tests if the specified address is associated with a port:
|
||||
|
||||
its('addresses') { should include '0.0.0.0' }
|
||||
|
||||
### be_listening
|
||||
|
||||
The `be_listening` matcher tests if the port is listening for traffic:
|
||||
|
||||
it { should be_listening }
|
||||
|
||||
### pids
|
||||
|
||||
The `pids` matcher tests the process identifiers (PIDs):
|
||||
|
||||
its('pids') { should cmp 27808 }
|
||||
|
||||
### processes
|
||||
|
||||
The `processes` matcher tests if the named process is running on the system:
|
||||
|
||||
its('processes') { should cmp 'syslog' }
|
||||
|
||||
### protocols
|
||||
|
||||
The `protocols` matcher tests the Internet protocol: ICMP (`'icmp'`), TCP (`'tcp'` or `'tcp6'`), or UDP (`'udp'` or `'udp6'`):
|
||||
|
||||
its('protocols') { should include 'tcp' }
|
||||
|
||||
or for the IPv6 protocol:
|
||||
|
||||
its('protocols') { should include 'tcp6' }
|
||||
|
|
|
@ -37,6 +37,12 @@ where
|
|||
- `('path')` is the non-default path to the `postgresql.conf` file (optional)
|
||||
- `should eq 'value'` is the value that is expected
|
||||
|
||||
## Properties
|
||||
|
||||
This resource supports any of the settings listed in an postgresql.conf file as properties for e.g. max_connections
|
||||
|
||||
its('max_connections') { should eq '5' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -78,11 +84,3 @@ where `unix_socket_group` is set to the PostgreSQL default setting (the group to
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
### setting
|
||||
|
||||
The `setting` matcher tests specific, named settings in the `postgresql.conf` file:
|
||||
|
||||
its('setting') { should eq 'value' }
|
||||
|
||||
Use a `setting` matcher for each setting to be tested.
|
||||
|
|
|
@ -39,10 +39,6 @@ where
|
|||
|
||||
## Properties
|
||||
|
||||
'address', 'auth_method', 'auth_params', 'conf_dir' , 'conf_file' , 'database', 'params' ,'type', 'user'
|
||||
|
||||
## Property Examples
|
||||
|
||||
### address([String])
|
||||
|
||||
`address` returns a an array of strings that matches the where condition of the filter table
|
||||
|
@ -85,17 +81,4 @@ where
|
|||
|
||||
## Matchers
|
||||
|
||||
This Chef InSpec audit resource matches any service that is listed in the HBA configuration file. For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
its('auth_method') { should_not cmp 'peer' }
|
||||
|
||||
or:
|
||||
|
||||
its('auth_method') { should cmp 'peer' }
|
||||
|
||||
For example:
|
||||
|
||||
describe postgres_hba_conf.where { type == 'type' } do
|
||||
its('auth_method') { should cmp 'value' }
|
||||
its('user') { should cmp 'value' }
|
||||
end
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
|
|
@ -39,13 +39,9 @@ where
|
|||
|
||||
## Properties
|
||||
|
||||
'conf_file', 'map_name', 'params', 'pg_username', 'system_username'
|
||||
|
||||
## Property Examples
|
||||
|
||||
### map_name([String])
|
||||
|
||||
`address` returns a an array of strings that matches the where condition of the filter table
|
||||
`map_name` returns a an array of strings that matches the where condition of the filter table
|
||||
|
||||
describe postgres_ident_conf.where { pg_username == 'name' } do
|
||||
its('map_name') { should eq ['value'] }
|
||||
|
@ -69,17 +65,4 @@ where
|
|||
|
||||
## Matchers
|
||||
|
||||
This Chef InSpec audit resource matches any service that is listed in the pg ident configuration file. For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
its('pg_username') { should_not eq ['peer'] }
|
||||
|
||||
or:
|
||||
|
||||
its('map_name') { should eq ['value'] }
|
||||
|
||||
For example:
|
||||
|
||||
describe postgres_ident_conf.where { pg_username == 'name' } do
|
||||
its('system_username') { should eq ['value'] }
|
||||
its('map_name') { should eq ['value'] }
|
||||
end
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
|
|
@ -50,6 +50,14 @@ where
|
|||
- `its('output') { should eq '' }` compares the results of the query against the expected result in the test
|
||||
- `socketpath` is an optional parameter. Use `socketpath` to establish a socket connection with Postgres by specifying one of the Postgres Unix domain socket paths. Only supported on Unix-based platforms.
|
||||
|
||||
## Properties
|
||||
|
||||
### output
|
||||
|
||||
The `output` property tests the results of the query:
|
||||
|
||||
its('output') { should eq(/^0/) }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -75,9 +83,3 @@ The following examples show how to use this Chef InSpec audit resource.
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
### output
|
||||
|
||||
The `output` matcher tests the results of the query:
|
||||
|
||||
its('output') { should eq(/^0/) }
|
||||
|
|
|
@ -41,6 +41,26 @@ where
|
|||
- `'matcher'` is one of `exit_status`, `stderr`, or `stdout`
|
||||
- `'output'` tests the output of the command run on the system versus the output value stated in the test
|
||||
|
||||
## Properties
|
||||
|
||||
### exit_status
|
||||
|
||||
The `exit_status` property tests the exit status for the command:
|
||||
|
||||
its('exit_status') { should eq 123 }
|
||||
|
||||
### stderr
|
||||
|
||||
The `stderr` property tests results of the command as returned in standard error (stderr):
|
||||
|
||||
its('stderr') { should eq 'error' }
|
||||
|
||||
### stdout
|
||||
|
||||
The `stdout` property tests results of the command as returned in standard output (stdout):
|
||||
|
||||
its('stdout') { should eq '/^1$/' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -92,21 +112,3 @@ No newline:
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
### exit_status
|
||||
|
||||
The `exit_status` matcher tests the exit status for the command:
|
||||
|
||||
its('exit_status') { should eq 123 }
|
||||
|
||||
### stderr
|
||||
|
||||
The `stderr` matcher tests results of the command as returned in standard error (stderr):
|
||||
|
||||
its('stderr') { should eq 'error' }
|
||||
|
||||
### stdout
|
||||
|
||||
The `stdout` matcher tests results of the command as returned in standard output (stdout):
|
||||
|
||||
its('stdout') { should eq '/^1$/' }
|
||||
|
|
|
@ -56,10 +56,6 @@ The following examples show how to use this Chef InSpec resource.
|
|||
|
||||
## Properties
|
||||
|
||||
- `sid`
|
||||
|
||||
## Property Examples
|
||||
|
||||
### sid
|
||||
|
||||
describe security_identifier(group: 'Everyone') do
|
||||
|
|
|
@ -41,6 +41,12 @@ where
|
|||
- `{ should eq 'value' }` tests the value of `policy_name` against the value declared in the test
|
||||
- `translate_sid` converts the security identifier (SID) into a human readable SID name if `true`. Default value is `false`.
|
||||
|
||||
## Properties
|
||||
|
||||
This resource supports any of the security policy name as properties for e.g. `SeNetworkLogonRigth`, `SeRemoteInteractiveLogonRight` etc.
|
||||
|
||||
its('SeNetworkLogonRight') { should eq '*S-1-5-11' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -54,9 +60,3 @@ The following examples show how to use this Chef InSpec audit resource.
|
|||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
||||
### policy_name
|
||||
|
||||
The `policy_name` matcher must be the name of a security policy:
|
||||
|
||||
its('SeNetworkLogonRight') { should eq '*S-1-5-11' }
|
||||
|
|
|
@ -42,6 +42,32 @@ where
|
|||
- `ssl(port: #)` is the port number, such as `ssl(port: 443)`
|
||||
- `filter` may take any of the following arguments: `ciphers`, `protocols`, and `handshake`
|
||||
|
||||
## Properties
|
||||
|
||||
### ciphers
|
||||
|
||||
The `ciphers` property tests the named cipher:
|
||||
|
||||
its('ciphers') { should_not eq '/rc4/i' }
|
||||
|
||||
or:
|
||||
|
||||
describe ssl(port: 443).ciphers(/rc4/i) do
|
||||
it { should_not be_enabled }
|
||||
end
|
||||
|
||||
### protocols
|
||||
|
||||
The `protocols` property tests what protocol versions (SSLv3, TLSv1.1, etc) are enabled:
|
||||
|
||||
its('protocols') { should eq 'ssl2' }
|
||||
|
||||
or:
|
||||
|
||||
describe ssl(port: 443).protocols('ssl2') do
|
||||
it { should_not be_enabled }
|
||||
end
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -103,27 +129,3 @@ For a full list of available matchers, please visit our [matchers page](/inspec/
|
|||
The `be_enabled` matcher tests if SSL is enabled:
|
||||
|
||||
it { should be_enabled }
|
||||
|
||||
### ciphers
|
||||
|
||||
The `ciphers` matcher tests the named cipher:
|
||||
|
||||
its('ciphers') { should_not eq '/rc4/i' }
|
||||
|
||||
or:
|
||||
|
||||
describe ssl(port: 443).ciphers(/rc4/i) do
|
||||
it { should_not be_enabled }
|
||||
end
|
||||
|
||||
### protocols
|
||||
|
||||
The `protocols` matcher tests what protocol versions (SSLv3, TLSv1.1, etc) are enabled:
|
||||
|
||||
its('protocols') { should eq 'ssl2' }
|
||||
|
||||
or:
|
||||
|
||||
describe ssl(port: 443).protocols('ssl2') do
|
||||
it { should_not be_enabled }
|
||||
end
|
||||
|
|
|
@ -31,37 +31,11 @@ An `sys_info` resource block declares the hostname to be tested:
|
|||
its('hostname') { should eq 'value' }
|
||||
end
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
||||
### Get system information for example.com
|
||||
|
||||
describe sys_info do
|
||||
its('hostname') { should eq 'example.com' }
|
||||
end
|
||||
|
||||
### Compare content to hostname
|
||||
|
||||
describe file('/path/to/some/file') do
|
||||
its('content') { should match sys_info.hostname }
|
||||
end
|
||||
|
||||
Options can be passed as arguments to hostname as well.
|
||||
|
||||
describe file('/path/to/some/file') do
|
||||
its('content') { should match sys_info.hostname('full') }
|
||||
end
|
||||
|
||||
Currently supported arguments to `hostname` on Linux platforms are 'full'|'f'|'fqdn'|'long', 'domain'|'d', 'ip_address'|'i', and 'short'|'s'. Mac currently supports 'full'|'f'|'fqdn'|'long' and 'short'|'s'
|
||||
|
||||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
## Properties
|
||||
|
||||
### hostname
|
||||
|
||||
The `hostname` matcher tests the host for which standard output is returned:
|
||||
The `hostname` property tests the host for which standard output is returned:
|
||||
|
||||
its('hostname') { should eq 'value' }
|
||||
|
||||
|
@ -91,12 +65,40 @@ The `short` property tests the host name cut at the first dot:
|
|||
|
||||
### manufacturer
|
||||
|
||||
The `manufacturer` matcher tests the host for which standard output is returned:
|
||||
The `manufacturer` property tests the host for which standard output is returned:
|
||||
|
||||
its('manufacturer') { should eq 'ACME Corp.' }
|
||||
|
||||
### model
|
||||
|
||||
The `model` matcher tests the host for which standard output is returned:
|
||||
The `model` property tests the host for which standard output is returned:
|
||||
|
||||
its('model') { should eq 'Flux Capacitor' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
||||
### Get system information for example.com
|
||||
|
||||
describe sys_info do
|
||||
its('hostname') { should eq 'example.com' }
|
||||
end
|
||||
|
||||
### Compare content to hostname
|
||||
|
||||
describe file('/path/to/some/file') do
|
||||
its('content') { should match sys_info.hostname }
|
||||
end
|
||||
|
||||
Options can be passed as arguments to hostname as well.
|
||||
|
||||
describe file('/path/to/some/file') do
|
||||
its('content') { should match sys_info.hostname('full') }
|
||||
end
|
||||
|
||||
Currently supported arguments to `hostname` on Linux platforms are 'full'|'f'|'fqdn'|'long', 'domain'|'d', 'ip_address'|'i', and 'short'|'s'. Mac currently supports 'full'|'f'|'fqdn'|'long' and 'short'|'s'
|
||||
|
||||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
|
|
@ -39,6 +39,11 @@ where:
|
|||
- `('path')` is the path to the TOML file.
|
||||
- `{ should eq 'value' }` is the value that is expected.
|
||||
|
||||
|
||||
## Properties
|
||||
|
||||
This resource supports any of the settings listed in a TOML file as properties.
|
||||
|
||||
## Examples
|
||||
|
||||
In the examples below, the `example.toml` file contains the following data:
|
||||
|
@ -75,11 +80,6 @@ describe toml('path/to/example.toml') do
|
|||
end
|
||||
```
|
||||
|
||||
|
||||
## Properties
|
||||
|
||||
This resource supports any of the settings listed in a TOML file as properties.
|
||||
|
||||
## Matchers
|
||||
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
|
|
@ -50,6 +50,110 @@ where
|
|||
- `it { should exist }` tests if the user exists
|
||||
- `gid`, `group`, `groups`, `home`, `maxdays`, `mindays`, `shell`, `uid`, `warndays`´, `passwordage`, `maxbadpasswords`, `badpasswordattempts` and `lastlogin` are valid matchers for this resource
|
||||
|
||||
## Properties
|
||||
|
||||
### gid
|
||||
|
||||
The `gid` property tests the group identifier:
|
||||
|
||||
its('gid') { should eq 1234 }
|
||||
|
||||
where `1234` represents the user identifier.
|
||||
The `gid` option is only available on Linux and will return `nil` for Windows os.
|
||||
|
||||
### group
|
||||
|
||||
The `group` property tests the group to which the user belongs:
|
||||
|
||||
its('group') { should eq 'root' }
|
||||
|
||||
where `root` represents the group.
|
||||
The `group` option is only available on Linux and will return `nil` for Windows os.
|
||||
|
||||
### groups
|
||||
|
||||
The `groups` property tests two (or more) groups to which the user belongs:
|
||||
|
||||
its('groups') { should eq ['root', 'other'] }
|
||||
|
||||
### home
|
||||
|
||||
The `home` property tests the home directory path for the user:
|
||||
|
||||
its('home') { should eq '/root' }
|
||||
|
||||
### maxdays
|
||||
|
||||
The `maxdays` property tests the maximum number of days between password changes:
|
||||
|
||||
its('maxdays') { should eq 99 }
|
||||
|
||||
where `99` represents the maximum number of days.
|
||||
|
||||
### mindays
|
||||
|
||||
The `mindays` property tests the minimum number of days between password changes:
|
||||
|
||||
its('mindays') { should eq 0 }
|
||||
|
||||
where `0` represents the maximum number of days.
|
||||
|
||||
### shell
|
||||
|
||||
The `shell` property tests the path to the default shell for the user:
|
||||
|
||||
its('shell') { should eq '/bin/bash' }
|
||||
|
||||
### uid
|
||||
|
||||
The `uid` property tests the user identifier:
|
||||
|
||||
its('uid') { should eq 1234 }
|
||||
|
||||
where `1234` represents the user identifier.
|
||||
|
||||
### warndays
|
||||
|
||||
The `warndays` property tests the number of days a user is warned before a password must be changed:
|
||||
|
||||
its('warndays') { should eq 5 }
|
||||
|
||||
where `5` represents the number of days a user is warned.
|
||||
|
||||
### passwordage
|
||||
|
||||
The `passwordage` property tests the number of days a user changed its password:
|
||||
|
||||
its('passwordage') { should_be <= 365 }
|
||||
|
||||
where `365` represents the number of days since the last password change.
|
||||
|
||||
### maxbadpasswords
|
||||
|
||||
The `maxbadpasswords` property tests the count of max badpassword settings for a specific user.
|
||||
|
||||
its('maxbadpasswords') { should eq 7 }
|
||||
|
||||
where `7` is the count of maximum bad password attempts.
|
||||
|
||||
### badpasswordattempts
|
||||
|
||||
The `badpasswordattempts` property tests the count of bad password attempts for a user.
|
||||
|
||||
its('badpasswordattempts') { should eq 0 }
|
||||
|
||||
where `0` is the count of bad passwords for a user.
|
||||
On Linux based operating systems it relies on `lastb` and for Windows it uses information stored for the user object.
|
||||
These settings will be reset to `0` depending on your operating system configuration.
|
||||
|
||||
### lastlogin
|
||||
|
||||
The `lastlogin` property tests the last login date for a specific user.
|
||||
|
||||
its('lastlogin') { should eq nil }
|
||||
|
||||
The `nil` value means this user has never logged in.
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -86,105 +190,3 @@ For a full list of available matchers, please visit our [matchers page](/inspec/
|
|||
The `exist` matcher tests if the named user exists:
|
||||
|
||||
it { should exist }
|
||||
|
||||
### gid
|
||||
|
||||
The `gid` matcher tests the group identifier:
|
||||
|
||||
its('gid') { should eq 1234 }
|
||||
|
||||
where `1234` represents the user identifier.
|
||||
The `gid` option is only available on Linux and will return `nil` for Windows os.
|
||||
|
||||
### group
|
||||
|
||||
The `group` matcher tests the group to which the user belongs:
|
||||
|
||||
its('group') { should eq 'root' }
|
||||
|
||||
where `root` represents the group.
|
||||
The `group` option is only available on Linux and will return `nil` for Windows os.
|
||||
|
||||
### groups
|
||||
|
||||
The `groups` matcher tests two (or more) groups to which the user belongs:
|
||||
|
||||
its('groups') { should eq ['root', 'other'] }
|
||||
|
||||
### home
|
||||
|
||||
The `home` matcher tests the home directory path for the user:
|
||||
|
||||
its('home') { should eq '/root' }
|
||||
|
||||
### maxdays
|
||||
|
||||
The `maxdays` matcher tests the maximum number of days between password changes:
|
||||
|
||||
its('maxdays') { should eq 99 }
|
||||
|
||||
where `99` represents the maximum number of days.
|
||||
|
||||
### mindays
|
||||
|
||||
The `mindays` matcher tests the minimum number of days between password changes:
|
||||
|
||||
its('mindays') { should eq 0 }
|
||||
|
||||
where `0` represents the maximum number of days.
|
||||
|
||||
### shell
|
||||
|
||||
The `shell` matcher tests the path to the default shell for the user:
|
||||
|
||||
its('shell') { should eq '/bin/bash' }
|
||||
|
||||
### uid
|
||||
|
||||
The `uid` matcher tests the user identifier:
|
||||
|
||||
its('uid') { should eq 1234 }
|
||||
|
||||
where `1234` represents the user identifier.
|
||||
|
||||
### warndays
|
||||
|
||||
The `warndays` matcher tests the number of days a user is warned before a password must be changed:
|
||||
|
||||
its('warndays') { should eq 5 }
|
||||
|
||||
where `5` represents the number of days a user is warned.
|
||||
|
||||
### passwordage
|
||||
|
||||
The `passwordage` matcher tests the number of days a user changed its password:
|
||||
|
||||
its('passwordage') { should_be <= 365 }
|
||||
|
||||
where `365` represents the number of days since the last password change.
|
||||
|
||||
### maxbadpasswords
|
||||
|
||||
The `maxbadpasswords` matcher tests the count of max badpassword settings for a specific user.
|
||||
|
||||
its('maxbadpasswords') { should eq 7 }
|
||||
|
||||
where `7` is the count of maximum bad password attempts.
|
||||
|
||||
### badpasswordattempts
|
||||
|
||||
The `badpasswordattempts` matcher tests the count of bad password attempts for a user.
|
||||
|
||||
its('badpasswordattempts') { should eq 0 }
|
||||
|
||||
where `0` is the count of bad passwords for a user.
|
||||
On Linux based operating systems it relies on `lastb` and for Windows it uses information stored for the user object.
|
||||
These settings will be reset to `0` depending on your operating system configuration.
|
||||
|
||||
### lastlogin
|
||||
|
||||
The `lastlogin` matcher tests the last login date for a specific user.
|
||||
|
||||
its('lastlogin') { should eq nil }
|
||||
|
||||
The `nil` value means this user has never logged in.
|
||||
|
|
|
@ -50,17 +50,111 @@ or:
|
|||
it { should exist }
|
||||
end
|
||||
|
||||
## Properties
|
||||
|
||||
### gid
|
||||
|
||||
The `gid` property tests the group identifier:
|
||||
|
||||
its('gid') { should eq 1234 } }
|
||||
|
||||
where `1234` represents the user identifier.
|
||||
|
||||
### group
|
||||
|
||||
The `group` property tests the group to which the user belongs:
|
||||
|
||||
its('group') { should eq 'root' }
|
||||
|
||||
where `root` represents the group.
|
||||
|
||||
### groups
|
||||
|
||||
The `groups` property tests two (or more) groups to which the user belongs:
|
||||
|
||||
its('groups') { should eq ['root', 'other']}
|
||||
|
||||
### home
|
||||
|
||||
The `home` property tests the home directory path for the user:
|
||||
|
||||
its('home') { should eq '/root' }
|
||||
|
||||
### maxdays
|
||||
|
||||
The `maxdays` property tests the maximum number of days between password changes:
|
||||
|
||||
its('maxdays') { should eq 99 }
|
||||
|
||||
where `99` represents the maximum number of days.
|
||||
|
||||
### mindays
|
||||
|
||||
The `mindays` property tests the minimum number of days between password changes:
|
||||
|
||||
its('mindays') { should eq 0 }
|
||||
|
||||
where `0` represents the maximum number of days.
|
||||
|
||||
### shell
|
||||
|
||||
The `shell` property tests the path to the default shell for the user:
|
||||
|
||||
its('shells') { should eq ['/bin/bash'] }
|
||||
|
||||
### uid
|
||||
|
||||
The `uid` property tests the user identifier:
|
||||
|
||||
its('uid') { should eq 1234 } }
|
||||
|
||||
where `1234` represents the user identifier.
|
||||
|
||||
### warndays
|
||||
|
||||
The `warndays` property tests the number of days a user is warned before a password must be changed:
|
||||
|
||||
its('warndays') { should eq 5 }
|
||||
|
||||
where `5` represents the number of days a user is warned.
|
||||
|
||||
### passwordage
|
||||
|
||||
The `passwordage` property tests the number of days a user changed its password:
|
||||
|
||||
its('passwordage') { should_be <= 365 }
|
||||
|
||||
where `365` represents the number of days since the last password change.
|
||||
|
||||
### maxbadpasswords
|
||||
|
||||
The `maxbadpasswords` property tests the count of max badpassword settings for a specific user.
|
||||
|
||||
its('maxbadpasswords') { should eq 7 }
|
||||
|
||||
where `7` is the count of maximum bad password attempts.
|
||||
|
||||
### badpasswordattempts
|
||||
|
||||
The `badpasswordattempts` property tests the count of bad password attempts for a user.
|
||||
|
||||
its('badpasswordattempts') { should eq 0 }
|
||||
|
||||
where `0` is the count of bad passwords for a user.
|
||||
On Linux based operating systems it relies on `lastb` and for Windows it uses information stored for the user object.
|
||||
These settings will be resetted to `0` depending on your operating system configuration.
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
||||
### Use a regular expression to find users
|
||||
### Use a regular expression to find users:
|
||||
|
||||
describe users.where { uid =~ /S\-1\-5\-21\-\d+\-\d+\-\d+\-500/ } do
|
||||
it { should exist }
|
||||
end
|
||||
|
||||
### Test only allowed users exist
|
||||
### Test that only allowed users exist:
|
||||
|
||||
allowed_users = %w(user1 user2 user3)
|
||||
|
||||
|
@ -83,95 +177,3 @@ For a full list of available matchers, please visit our [matchers page](/inspec/
|
|||
The `exist` matcher tests if the named user exists:
|
||||
|
||||
it { should exist }
|
||||
|
||||
### gid
|
||||
|
||||
The `gid` matcher tests the group identifier:
|
||||
|
||||
its('gid') { should eq 1234 } }
|
||||
|
||||
where `1234` represents the user identifier.
|
||||
|
||||
### group
|
||||
|
||||
The `group` matcher tests the group to which the user belongs:
|
||||
|
||||
its('group') { should eq 'root' }
|
||||
|
||||
where `root` represents the group.
|
||||
|
||||
### groups
|
||||
|
||||
The `groups` matcher tests two (or more) groups to which the user belongs:
|
||||
|
||||
its('groups') { should eq ['root', 'other']}
|
||||
|
||||
### home
|
||||
|
||||
The `home` matcher tests the home directory path for the user:
|
||||
|
||||
its('home') { should eq '/root' }
|
||||
|
||||
### maxdays
|
||||
|
||||
The `maxdays` matcher tests the maximum number of days between password changes:
|
||||
|
||||
its('maxdays') { should eq 99 }
|
||||
|
||||
where `99` represents the maximum number of days.
|
||||
|
||||
### mindays
|
||||
|
||||
The `mindays` matcher tests the minimum number of days between password changes:
|
||||
|
||||
its('mindays') { should eq 0 }
|
||||
|
||||
where `0` represents the maximum number of days.
|
||||
|
||||
### shell
|
||||
|
||||
The `shell` matcher tests the path to the default shell for the user:
|
||||
|
||||
its('shells') { should eq ['/bin/bash'] }
|
||||
|
||||
### uid
|
||||
|
||||
The `uid` matcher tests the user identifier:
|
||||
|
||||
its('uid') { should eq 1234 } }
|
||||
|
||||
where `1234` represents the user identifier.
|
||||
|
||||
### warndays
|
||||
|
||||
The `warndays` matcher tests the number of days a user is warned before a password must be changed:
|
||||
|
||||
its('warndays') { should eq 5 }
|
||||
|
||||
where `5` represents the number of days a user is warned.
|
||||
|
||||
### passwordage
|
||||
|
||||
The `passwordage` matcher tests the number of days a user changed its password:
|
||||
|
||||
its('passwordage') { should_be <= 365 }
|
||||
|
||||
where `365` represents the number of days since the last password change.
|
||||
|
||||
### maxbadpasswords
|
||||
|
||||
The `maxbadpasswords` matcher tests the count of max badpassword settings for a specific user.
|
||||
|
||||
its('maxbadpasswords') { should eq 7 }
|
||||
|
||||
where `7` is the count of maximum bad password attempts.
|
||||
|
||||
### badpasswordattempts
|
||||
|
||||
The `badpasswordattempts` matcher tests the count of bad password attempts for a user.
|
||||
|
||||
its('badpasswordattempts') { should eq 0 }
|
||||
|
||||
where `0` is the count of bad passwords for a user.
|
||||
On Linux based operating systems it relies on `lastb` and for Windows it uses information stored for the user object.
|
||||
These settings will be resetted to `0` depending on your operating system configuration.
|
||||
|
|
|
@ -38,6 +38,66 @@ where
|
|||
- `('setting')` is a setting in the `xinetd.conf` file
|
||||
- `should eq 'value'` is the value that is expected
|
||||
|
||||
## Properties
|
||||
|
||||
### ids
|
||||
|
||||
The `ids` property tests if the named service is located under `/etc/xinet.d`:
|
||||
|
||||
its('ids') { should include 'service_name' }
|
||||
|
||||
For example:
|
||||
|
||||
its('ids') { should include 'chargen-stream chargen-dgram'}
|
||||
|
||||
### services
|
||||
|
||||
The `services` property tests if the named service is listed under `/etc/xinet.d`:
|
||||
|
||||
its('services') { should include 'service_name' }
|
||||
|
||||
### socket_types
|
||||
|
||||
The `socket_types` property tests if a service listed under `/etc/xinet.d` is configured to use the named socket type.
|
||||
|
||||
Use `socket` if the socket type is `dgram`, `raw`, or `stream`:
|
||||
|
||||
its('socket_types') { should eq 'socket' }
|
||||
|
||||
For a UDP-based service:
|
||||
|
||||
its('socket_types') { should eq 'dgram' }
|
||||
|
||||
For a raw socket (such as a service using a non-standard protocol or a service that requires direct access to IP):
|
||||
|
||||
its('socket_types') { should eq 'raw' }
|
||||
|
||||
For a TCP-based service:
|
||||
|
||||
its('socket_types') { should eq 'stream' }
|
||||
|
||||
### types
|
||||
|
||||
The `types` property tests the service type:
|
||||
|
||||
its('type') { should eq 'TYPE' }
|
||||
|
||||
where `'TYPE'` is `INTERNAL` (for a service provided by xinetd), `RPC` (for a service based on remote procedure call), or `UNLISTED` (for services not under `/etc/services` or `/etc/rpc`).
|
||||
|
||||
### wait
|
||||
|
||||
The `wait` property tests how a service handles incoming connections.
|
||||
|
||||
For UDP (`dgram`) socket types, the `wait` property should test for `yes`:
|
||||
|
||||
its('socket_types') { should eq 'dgram' }
|
||||
its('wait') { should eq 'yes' }
|
||||
|
||||
For TCP (`stream`) socket types, the `wait` property should test for `no`:
|
||||
|
||||
its('socket_types') { should eq 'stream' }
|
||||
its('wait') { should eq 'no' }
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -108,59 +168,3 @@ For a full list of available matchers, please visit our [matchers page](/inspec/
|
|||
The `be_enabled` matcher tests if a service listed under `/etc/xinet.d` is enabled:
|
||||
|
||||
it { should be_enabled }
|
||||
|
||||
### ids
|
||||
|
||||
The `ids` matcher tests if the named service is located under `/etc/xinet.d`:
|
||||
|
||||
its('ids') { should include 'service_name' }
|
||||
|
||||
For example:
|
||||
|
||||
its('ids') { should include 'chargen-stream chargen-dgram'}
|
||||
|
||||
### services
|
||||
|
||||
The `services` matcher tests if the named service is listed under `/etc/xinet.d`:
|
||||
|
||||
its('services') { should include 'service_name' }
|
||||
|
||||
### socket_types
|
||||
|
||||
The `socket_types` matcher tests if a service listed under `/etc/xinet.d` is configured to use the named socket type:
|
||||
|
||||
its('socket_types') { should eq 'socket' }
|
||||
|
||||
where `socket` is one of `dgram`, `raw`, or `stream`. For a UDP-based service:
|
||||
|
||||
its('socket_types') { should eq 'dgram' }
|
||||
|
||||
For a raw socket (such as a service using a non-standard protocol or a service that requires direct access to IP):
|
||||
|
||||
its('socket_types') { should eq 'raw' }
|
||||
|
||||
For a TCP-based service:
|
||||
|
||||
its('socket_types') { should eq 'stream' }
|
||||
|
||||
### types
|
||||
|
||||
The `types` matcher tests the service type:
|
||||
|
||||
its('type') { should eq 'TYPE' }
|
||||
|
||||
where `'TYPE'` is `INTERNAL` (for a service provided by xinetd), `RPC` (for a service based on remote procedure call), or `UNLISTED` (for services not under `/etc/services` or `/etc/rpc`).
|
||||
|
||||
### wait
|
||||
|
||||
The `wait` matcher tests how a service handles incoming connections.
|
||||
|
||||
For UDP (`dgram`) socket types the `wait` matcher should test for `yes`:
|
||||
|
||||
its('socket_types') { should eq 'dgram' }
|
||||
its('wait') { should eq 'yes' }
|
||||
|
||||
For TCP (`stream`) socket types the `wait` matcher should test for `no`:
|
||||
|
||||
its('socket_types') { should eq 'stream' }
|
||||
its('wait') { should eq 'no' }
|
||||
|
|
|
@ -37,6 +37,10 @@ where:
|
|||
- `MATCHER` is a valid matcher for this resource
|
||||
- `'value'` is the value to be tested
|
||||
|
||||
## Properties
|
||||
|
||||
This Chef InSpec audit resource dynamically exposes all ZFS pool properties available (see: `man zpool` for the list of supported properties).
|
||||
|
||||
## Examples
|
||||
|
||||
The following examples show how to use this Chef InSpec audit resource.
|
||||
|
@ -54,4 +58,4 @@ The following examples show how to use this Chef InSpec audit resource.
|
|||
|
||||
## Matchers
|
||||
|
||||
This Chef InSpec audit resource dynamically exposes all ZFS pool properties available (see: `man zpool` for the list of supported properties). For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
For a full list of available matchers, please visit our [matchers page](/inspec/matchers/).
|
||||
|
|
Loading…
Reference in a new issue