* Remove deprecated yumrepo. (#3435) * Remove deprecations for cli `--format` and metadata.rb (#3452) * Remove deprecated database_helpers stderr/stdout methods. Update deprecation text for processes/apache. * Remove deprecations for `--format` and metadata.rb Remove deprecated `format` code. Remove deprecated code test and change json-config format test to use reporter. Remove deprecated metadata.rb code Remove deprecation notice for old supports syntax. Deprecate metadata.rb from source_reader Remove rubocop disables as they are no longer required for this code block. Remove deprecated legacy metadata.rb mock profiles. Remove deprecated metadata.rb profile tests. Remove deprecated yumrepo test. * Allow inspec-3.0 branch to be tested. * Allow appveyor to test inspec-3.0 branch * Change runner tests to use reporter rather than format. Remove deprecated `supports: linux` tests. * Remove skip from inherited profiles from showing up in reporting (breaking change) (#3332) * Skip loading dependency profiles if they are unsupported on the current platform. Skip loading dependencies if they are unsupported on the current platform. Wrap our log and next in a conditional checking if the platform is supported. Change a `if !` into a `unless` Check if the backend is a Train Mock Connection and if so say that the profile does support the platform. While iterating through tests being loaded skip when the platform is unsupported. We now log a WARN when a profile is skipped due to unsupported platform, so lets check that. Modified existing test to log that there are 0 skipped tests, instead of 2. Add functional test that loads profile-support-skip with a json reporter to check that our controls are not loaded and that stderr contains our warning. * Rather than iterating through each test return before recursion if the platform is unsupported. * Resolve tests using a supported platform different from testing platform Add a control to `test/unit/mock/profiles/complete-profile` that would work on any OS with a Internet connection. This allows the profile to execute on any OS with success. `filesystem_spec.rb` was a control that would only work on Linux and some BSD's. We want profile tests to consistently work across development and testing platforms, and not get 'skipped' in some cases. Travis-CI tests on Linux, Inspec Dev team uses Linux and MacOS, Appveyor tests on Windows Also Updated `file_provider_test.rb` for `complete-profile` content changes. If you `MockLoader.load_profile` on a unsupported platform you might not hit the usual skip. Lets handle situations where the tests array in Profile#load_checks_params could be nil. * Use safe navigation rather than checking if tests is nil. Update tests to point to unsupported_inspec and account for WARN changes. Make unsupported_inspec profile support os-family 'unsupported_inspec' * Fix skip bug when using include/require controls. (#3487) * Fix skip bug when using include/require controls. * fix test and feedback. * Remove need for UUID detection for Automate report (#3507) * Add json metadata for skipped profiles (#3495) * Add skip metadata to json reports * Unify skip messages. * Update with status field. * Add testing. * Fix tests. * lint * Add skip exit codes for profile skips. * Update website for 3.0 launch Add `plugins` to sidebar. Change 2.0 -> 3.0 in slim files. Update 3.0 features list. * Fix comments * Update float to numeric. * Change Float to numeric. * updated feature list and impact doc * Change "What's new in InSpec 3.0" -> "Announcing InSpec 3.0" * Bump VERSION to 3.0.0 (#3511) * Remove 3.0 testing checks. * Fix azure link.
4.5 KiB
Using InSpec on Cloud Platforms
As of InSpec 2.0, we have expanded our platform support beyond individual machines and now include support for select AWS and Azure resources.
Using InSpec, you can use several InSpec resources to audit properties of your cloud infrastructure - for example, an Amazon Web Services S3 bucket.
AWS Platform Support in InSpec
Setting up AWS credentials for InSpec
InSpec uses the standard AWS authentication mechanisms. Typically, you will create an IAM user specifically for auditing activities.
- 1 Create an IAM user in the AWS console, with your choice of username. Check the box marked "Programmatic Access."
- 2 On the Permissions screen, choose Direct Attach. Select the AWS-managed IAM Profile named "ReadOnlyAccess." If you wish to restrict the user further, you may do so; see individual InSpec resources to identify which permissions are required.
- 3 After generating the key, record the Access Key ID and Secret Key.
Using Environment Variables to provide credentials
You may provide the credentials to InSpec by setting the following environment variables: AWS_REGION
, AWS_ACCESS_KEY_ID
, and AWS_SECRET_KEY_ID
. You may also use AWS_PROFILE
, or if you are using MFA, AWS_SESSION_TOKEN
. See the AWS Command Line Interface Docs for details.
Once you have your environment variables set, you can verify your credentials by running:
you$ inspec detect -t aws://
== Platform Details
Name: aws
Families: cloud, api
Release: aws-sdk-v2.10.125
Using the InSpec target option to provide credentials on AWS
Look for a file in your home directory named ~/.aws/credentials
. If it does not exist, create it. Choose a name for your profile; here, we're using the name 'auditing'. Add your credentials as a new profile, in INI format:
[auditing]
aws_access_key_id = AKIA....
aws_secret_access_key = 1234....abcd
You may now run InSpec using the --target
/ -t
option, using the format -t aws://region/profile
. For example, to connect to the Ohio region using a profile named 'auditing', use -t aws://us-east-2/auditing
.
To verify your credentials,
you$ inspec detect -t aws://
== Platform Details
Name: aws
Families: cloud, api
Release: aws-sdk-v2.10.125
Azure Platform Support in InSpec
Setting up Azure credentials for InSpec
To use InSpec Azure resources, you will need to create a Service Principal Name (SPN) for auditing an Azure subscription.
This can be done on the command line or from the Azure Portal:
The information from the SPN can be specified either in the file ~/.azure/credentials
, as environment variables, or by using InSpec target URIs.
Setting up the Azure Credentials File
By default InSpec is configured to look at ~/.azure/credentials, and it should contain:
[<SUBSCRIPTION_ID>]
client_id = "<CLIENT_ID>"
client_secret = "<CLIENT_SECRET>"
tenant_id = "<TENANT_ID>"
NOTE: In the Azure web portal, these values are labeled differently:
- The client_id is referred to as the 'Application ID'
- The client_secret is referred to as the 'Key (Password Type)'
- The tenant_id is referred to as the 'Directory ID'
With the credentials are in place you may now execute InSpec:
inspec exec my-inspec-profile -t azure://
Using Environment variables to provide credentials
You may also set the Azure credentials via environment variables:
AZURE_SUBSCRIPTION_ID
AZURE_CLIENT_ID
AZURE_CLIENT_SECRET
AZURE_TENANT_ID
For example:
AZURE_SUBSCRIPTION_ID="2fbdbb02-df2e-11e6-bf01-fe55135034f3" \
AZURE_CLIENT_ID="58dc4f6c-df2e-11e6-bf01-fe55135034f3" \
AZURE_CLIENT_SECRET="Jibr4iwwaaZwBb6W" \
AZURE_TENANT_ID="6ad89b58-df2e-11e6-bf01-fe55135034f3" inspec exec my-profile -t azure://
Using the InSpec target option to provide credentials on Azure
If you have created a ~/.azure/credentials
file as above, you may also use the InSpec command line --target
/ -t
option to select a subscription ID. For example:
inspec exec my-profile -t azure://2fbdbb02-df2e-11e6-bf01-fe55135034f3