Patterns for automated compliance testing using Chef InSpec

This document describes patterns for automating policy and compliance checks for your Google Cloud resources using Chef InSpec, an open source infrastructure testing framework. This document is for architects and DevOps practitioners who want to integrate continuous compliance testing into their software development workflow.

Policy and compliance in Google Cloud

Google Cloud provides a range of tools to help you enforce and audit policy and compliance requirements:

Service	Description
Resource hierarchy	You can use the resource hierarchy to map your company's operational structure to Google Cloud, and to manage access control and permissions for groups of related resources. You can define groups of related resources, and apply consistent controls to all resources in the group. For example, you can group all of your Google Cloud projects that are subject to Payment Card Industry Data Security Standard (PCI DSS) compliance into a particular folder. You can then apply relevant controls to all projects in that folder.
Organization Policy Service	You use the Organization Policy Service to define constraints that limit the availability or functionality of Google Cloud services. For example, you can use the resource location constraint to limit the set of regions where location-based resources like virtual machines can be created. The Organization Policy Service works together with the resource hierarchy. You can apply organization policies at different levels of the hierarchy. For example, you can define an organization policy for your projects that are subject to PCI compliance and apply the policy to the PCI folder.
Security Command Center	You can use Security Command Center for centralized visibility of all your Google Cloud resources. Security Command Center automatically analyses your cloud resources for known vulnerabilities and provides a single user interface and data platform to aggregate and manage security findings. Security Health Analytics can provide monitoring and reporting for compliance standards like PCI DSS, and industry standards like the Center for Internet Security (CIS) benchmark. You can view the reports in a compliance dashboard and then export them. Security Command Center integrates with several third-party security sources and provides an API so you can add and manage your custom findings. Security Command Center provides a unified interface for all your security and compliance findings.
Config Sync	If you use GKE Enterprise, you can use Config Sync to keep your Kubernetes clusters in sync with configurations defined in a Git repository. The Git repository acts as the single source of truth for your cluster configuration and policies. Config Sync continuously audits your GKE Enterprise environment to identify and fix clusters that deviate from the configuration defined in your repository.
Policy Controller	If you use GKE Enterprise, you can use Policy Controller, a Kubernetes dynamic admission controller, to enforce fully programmable policies for your clusters. Using Policy Controller, you can prevent the creation of objects within your clusters that don't satisfy your policy requirements. For example, you can create policies to enforce Pod security.

Introducing Chef InSpec

Chef InSpec is an open source infrastructure testing framework with a human-readable domain-specific language (DSL) for specifying compliance, security, and policy requirements.

With Chef InSpec, you can do the following:

• Define compliance requirements as code and test your cloud infrastructure against those requirements.
• Enable development teams to add application-specific tests and assess the compliance of their applications to security policies before pushing changes to the production environment.
• Automate compliance verification in CI/CD pipelines and as part of the release process.
• Test your Google Cloud infrastructure in the same way that you test your infrastructure in other cloud environments.

Google Cloud provides several resources to help you get started with Chef InSpec:

• The Google Cloud InSpec resource pack contains the baseline resources for writing Chef InSpec tests against Google Cloud objects.
• The Google Cloud InSpec CIS profile contains a set of Chef InSpecs tests that assess the security posture of your Google Cloud projects against the Center for Internet Security (CIS) Benchmark.

Best practices for using Chef InSpec with Google Cloud

The following are general best practices for using Chef InSpec:

• Define and adopt a process for fixing the violations discovered by your Chef InSpec tests. Chef InSpec highlights violations to your policy and compliance requirements, but it doesn't perform any remediation.
• Grant appropriate IAM permissions to the service account that you use to run the Chef InSpec tests. For example, if you are testing Cloud Storage buckets, the service account must have the appropriate IAM roles for Cloud Storage.
• Configure Chef InSpec reporters to produce formatted reports that describe the tests and results. You can store these reports to provide a historical record. You can also use these reports as inputs to your other security and compliance tools. For example, you can Integrate Chef InSpec and Security Command Center.
• Group related Chef InSpec tests into profiles. You can create different profiles for different use cases. For example, you might run a comprehensive, end-to-end profile as part of your scheduled nightly tests. Or, you might run a shorter, more focused profile in response to real-time events.

Write Chef InSpec tests

You write Chef InSpec tests using the Chef InSpec DSL, which is a Ruby DSL for writing audit controls.

The following code shows a control for validating attributes of Cloud Storage buckets:

control 'policy_gcs_bucket' do
 title 'Cloud Storage bucket policy'
 desc 'Compliance policy checks for Cloud Storage bucket'
 impact 'medium'

 google_storage_buckets(project: project_id).bucket_names.each do |bucket|
   describe "[#{project_id}] Cloud Storage Bucket #{bucket}" do
     subject { google_storage_bucket(name: bucket) }
     its('storage_class') { should eq 'STANDARD' }
     its('location') { should be_in ['EUROPE-WEST2', 'EU'] }
     end
   end
 end

The control specifies the following information:

• Metadata that describes the control
• Impact or severity of failures
• Policy checks that verify attributes of each Cloud Storage bucket in your project

Run Chef InSpec tests with Cloud Build

The patterns described in this document use Cloud Build and the Chef InSpec container image to run the InSpec tests. By using Cloud Build, you can run container images, and chain build steps together to form a pipeline. For example, you can run the Chef InSpec tests in one build step, and then export or analyze the generated reports in a subsequent step. However, using Cloud Build is not required. You can integrate Chef InSpec with whatever tools you use.

The following Cloud Build configuration file shows a pipeline with two build steps:

steps:
- id: 'run-inspec-cis'
  name: chef/inspec:latest
  entrypoint: '/bin/sh'
  args:
   - '-c'
   - |
     inspec exec https://github.com/GoogleCloudPlatform/inspec-gcp-cis-benchmark.git \
     --target gcp:// \
     --input gcp_project_id=${PROJECT_ID} \
     --reporter cli json:/workspace/report.json \
     --chef-license accept || touch fail.marker

- id: 'store-report'
  name: gcr.io/cloud-builders/gsutil:latest
  args:
   - cp
   - /workspace/report.json
   - gs://${_REPORTS_BUCKET}/cis-report-${BUILD_ID}.json

The first step runs the Google Cloud CIS benchmark tests and generates a report in JSON format. The build step uses the chef/inspec container image, and fetches the tests from the public Google Cloud CIS GitHub repository. The second build step copies the generated report to a Cloud Storage bucket.

For simplicity, the preceding example references the latest tag for all the container images. To help make your builds reproducible, we recommend that you reference a specific, fixed container image version, rather than a rolling one, such as latest.

If any of the tests fail, Chef InSpec returns an error. Instead of failing the build, the first build step writes a fail.marker file and the second build step runs even if any of the Chef InSpec tests fail. If you want to explicitly fail the build to highlight the errors, you can check for the fail.marker file in a final build step, and fail the build if it exists.

Analyze Chef InSpec reports

You can configure Chef InSpec reporters to produce formatted reports that describe the InSpec tests and results. You can store these reports to provide a historical record. You can also use these reports as inputs to your other security and compliance tools, or to generate visualizations or alerts. The patterns described later in this document recommend storing your Chef InSpec reports in a Cloud Storage bucket.

The following diagram shows how you can store the reports and automatically trigger further action.

Adding the report to a Cloud Storage bucket generates an event. You can trigger further action or analysis of the report in response to this event. In the preceding diagram, you trigger a Cloud Run function that writes details of the Chef InSpec tests to BigQuery and another Cloud Run function that adds findings to Security Command Center.

Integrate Chef InSpec and Security Command Center

Security Command Center is the canonical security and risk database for Google Cloud. Security Command Center provides centralized visibility of all your Google Cloud resources, and automatically analyses your cloud resources for known vulnerabilities. We recommend enabling Security Command Center for your organization.

You can add the results of your Chef InSpec tests to Security Command Center. Security Command Center acts as the centralized data platform to aggregate and manage security findings from multiple sources.

Security Command Center includes Security Health Analytics. Security Health Analytics automatically scans your Google Cloud projects and resources for common vulnerabilities. For example, Security Health Analytics runs scans that assess your projects against the CIS Google Cloud Foundation 1.0 benchmark. You can also run a similar set of tests using the Google Cloud InSpec CIS profile. You should compare the scope of your Chef InSpec tests such that the tests don't duplicate the checks performed by Security Health Analytics.

There are several ways to add Chef InSpec findings to Security Command Center:

• Use Chef Automate for Security Command Center to provide automatic integration of Chef InSpec test results into Security Command Center.
• Use the Security Command Center API to create a custom source for Chef InSpec, and then create findings to capture any violations discovered by your Chef InSpec tests.

Patterns

This section describes patterns for integrating Chef InSpec into your day-to-day operations. You can combine these patterns to achieve continuous compliance testing.

Schedule Chef InSpec tests

In this pattern, you run your set of Chef InSpec tests on a fixed schedule. We recommend this fixed schedule approach as a good way to get started with Chef InSpec because you can introduce Chef InSpec tests without modifying your existing processes.

The following diagram shows how you can run your tests on a schedule.

In the preceding diagram, you create a Cloud Scheduler job that runs with your preferred frequency. Each time your job runs, it triggers a Cloud Build pipeline that runs your Chef InSpec tests and outputs the test report to Cloud Storage. For more information, see Scheduling builds.

This pattern has the following benefits:

• You can introduce Chef InSpec tests with minimum changes to your existing processes.
• You can use Chef InSpec tests independently of any process that you use to provision and manage your infrastructure and apps.

This pattern has the following limitations:

• The Chef InSpec tests are decoupled from your infrastructure provisioning, which makes it harder to attribute particular changes to failed Chef InSpec tests.
• The Chef InSpec tests run only periodically, so there might be some delay before you identify compliance or policy violations

Integrate directly with your CI/CD pipelines

Many organizations automate the provisioning and management of their infrastructure by using tools like Terraform or Config Connector. Typically, infrastructure is created or changed only as part of a CI/CD pipeline. For more information about CI/CD concepts on Google Cloud, see Modern CI/CD with GKE Enterprise.

In this pattern, you add Chef InSpec tests as additional steps in your infrastructure deployment pipelines so that you can validate your infrastructure whenever you run your deployment pipeline. You can fail the build if there are any compliance violations.

The following diagram shows a common workflow where the deployment pipeline is triggered based on a commit that includes infrastructure changes.

In the preceding diagram, the infrastructure changes are applied to a test or staging environment, and then the Chef InSpec tests are run against that environment. If all Chef InSpec checks are compliant, you can merge and apply the infrastructure changes to the production environment, and the Chef InSpec tests run again against the production environment.

This pattern has the following benefits:

• The Chef InSpec tests are integrated directly into your deployment process so violations are quickly identified.
• If the Chef InSpec tests don't pass, you can explicitly fail the deployment.

This pattern has the following limitations:

• The Chef InSpec tests are directly integrated with your build pipelines, so the team that manages your build pipeline must understand the Chef InSpec tests
• If you have multiple builds that require Chef InSpec tests, you must add Chef InSpec steps into each individual build, which might make it more difficult to maintain and scale your Chef InSpec efforts.

Integrate indirectly with your CI/CD pipelines

This pattern is similar to the previous pattern, but instead of directly running your Chef InSpec tests as a step within your deployment pipeline, you run your Chef InSpec tests in a separate pipeline. This separate pipeline is triggered by your deployment pipelines. You can keep your Chef InSpec logic separate from your infrastructure pipelines, but still run your compliance and policy tests as part of your deployment workflow.

Cloud Build automatically generates build notifications when your build's state changes—for example, when your build is created, when your build transitions to a working state, and when your build completes. The notification messages are published to a Pub/Sub topic and contain information about the build, including the individual build steps and their arguments.

The following diagram shows how you can create a Cloud Run function that is automatically triggered whenever a message is published to the build notification Pub/Sub topic.

In the preceding diagram, the function can inspect the build notification message, and then trigger your Chef InSpec pipeline when required. For example, you only want to trigger the Chef InSpec pipeline in response to successful builds that contain particular build steps.

This pattern has the following benefits:

• The Chef InSpec tests are independent of your deployment pipelines. The teams that manage the deployment pipelines don't need to interact with Chef InSpec.
• You can centralize your Chef InSpec tests, making it easier to maintain and scale your Chef InSpec efforts.
• You can selectively run the Chef InSpec tests depending on the results and output of the upstream builds.

This pattern has the following limitations:

• You must write and maintain code to parse and analyze the build notification messages to determine whether to run your Chef InSpec tests and to pass parameters to your Chef InSpec tests.
• Cloud Build notifications are published to a Pub/Sub topic in the same project. If you have builds in multiple projects, you need to deploy the Cloud Run function to each project.

Trigger Chef InSpec tests in response to Cloud Asset Inventory notifications

Cloud Asset Inventory provides an inventory of all your Google Cloud resources. You can use Cloud Asset Inventory to search, analyze, and export your assets and asset metadata across your Google Cloud projects, folders, and organization. You can also use Cloud Asset Inventory to send real-time notifications about changes to your cloud resources and policies.

The following diagram shows how you can run your Chef InSpec tests based on notifications from Cloud Asset Inventory.

The preceding diagram shows how you can get near real-time feedback on any new or updated cloud resources that are not compliant. You can filter the notifications so that you are notified only for changes to certain types of resources. You can use these notifications to trigger targeted, resource-specific Chef InSpec tests. For example, you run a particular set of tests whenever a Cloud Storage bucket is created, and run a different set of Chef InSpec tests when an IAM policy is updated.

This pattern has the following benefits:

• You can trigger targeted, resource-specific Chef InSpec tests depending on the particular changes to your cloud assets.
• Cloud Asset Inventory notifications are delivered in near real time, so any compliance or policy violations are quickly identified.
• You can use this pattern independently of any process that you use to provision and manage your infrastructure. The Chef InSpec tests are run regardless of whether infrastructure is created or changed by an individual developer or a CI/CD pipeline.
• Cloud Asset Inventory can generate notifications about changes to your resources across your whole organization or from selected folders or projects. You can execute particular sets of Chef InSpec tests depending on the folder or project the change originated from.
• You can use this pattern alongside the other patterns. For example, many organizations don't have automated deployments in place for their development or sandbox environments. You can use this pattern to perform selected policy checks on these environments, while integrating with your CI/CD pipelines for your production and staging environments.

This pattern has the following limitations:

• This pattern might not be practical if there is a large volume of changes to your cloud assets because your Chef InSpec tests might be triggered by each change.
• You must write and maintain code to parse and analyze the Cloud Asset Inventory notification messages to determine whether to run your Chef InSpec tests

What's next

• Try the Cloud Shell walkthrough to quickly install Chef InSpec in your Cloud Shell instance and scan infrastructure in your Google Cloud projects against the CIS Benchmark.
• Visit the Google Cloud Compliance resource center.
• Read enterprise foundations blueprint.
• For more reference architectures, diagrams, and best practices, explore the Cloud Architecture Center.