Chef InSpec Compliance

My Compliance Automation Journey

The turning point in my Chef journey came when I was tasked with ensuring PCI-DSS compliance across 60+ servers. Manual compliance checks were consuming days of effort each quarter, and audits were stressful events involving spreadsheets, screenshots, and manual verification. I knew there had to be a better way.

That's when I discovered Chef InSpec - a compliance-as-code framework that transformed how I approached security and compliance. Instead of quarterly panic, I now have continuous compliance validation, automated evidence collection, and the confidence that comes from knowing my infrastructure's compliance posture in real-time.

What is Chef InSpec?

Chef InSpec is an open-source testing framework for infrastructure with a human-readable language for specifying compliance, security, and policy requirements. Unlike traditional compliance tools that simply scan and report, InSpec lets you write tests as code, integrate them into your CI/CD pipeline, and continuously validate your infrastructure.

Key Capabilities:

• Write compliance tests in a simple, readable DSL

• Test infrastructure locally or remotely (SSH, WinRM, Docker, cloud APIs)

• Generate evidence reports in multiple formats (JSON, HTML, JUnit)

• Integrate with Chef Automate for centralized compliance visibility

• Use pre-built profiles for industry standards (CIS, DISA STIGs, PCI-DSS)

Why InSpec Changed My Compliance Approach

Before InSpec:

• ❌ Quarterly manual audits taking 3-5 days

• ❌ Compliance drift between audits going undetected

• ❌ Difficult to prove continuous compliance

• ❌ No consistency across different teams

• ❌ Limited test coverage due to time constraints

After InSpec:

• ✅ Continuous automated compliance validation

• ✅ Compliance issues detected immediately

• ✅ Automated evidence generation for auditors

• ✅ Standardized tests across all teams

• ✅ Comprehensive coverage with minimal effort

InSpec Architecture and Components

The InSpec DSL

InSpec uses a human-readable Domain Specific Language based on Ruby:

# Check if SSH is configured securely
describe sshd_config do
  its('Protocol') { should eq '2' }
  its('PermitRootLogin') { should eq 'no' }
  its('PasswordAuthentication') { should eq 'no' }
end

# Verify file permissions
describe file('/etc/ssh/sshd_config') do
  it { should be_file }
  it { should be_owned_by 'root' }
  its('mode') { should cmp '0600' }
end

# Check if a service is running
describe service('firewalld') do
  it { should be_installed }
  it { should be_enabled }
  it { should be_running }
end

What I Love About This Syntax:

• Reads like natural language

• Easy for security teams to understand

• No programming expertise required

• Self-documenting tests

InSpec Resources

InSpec provides resources for testing various infrastructure components:

• System Resources: file, directory, user, group, service, package

• Network Resources: port, interface, bond, bridge

• Security Resources: sshd_config, auditd, iptables, firewalld

• Application Resources: nginx, apache, mysql, postgres

• Cloud Resources: aws_s3_bucket, azure_virtual_machine, google_compute_instance

Getting Started with InSpec Shell

The InSpec shell is an interactive environment for developing and testing compliance code - I use it daily for rapid prototyping.

Launching InSpec Shell

# Local testing
inspec shell

# Remote Linux host via SSH
inspec shell -t ssh://user@hostname -i ~/.ssh/id_rsa

# Remote Windows host via WinRM
inspec shell -t winrm://Administrator@windowshost --password 'SecurePass123!'

# Docker container
inspec shell -t docker://container_id

# With sudo for privilege escalation
inspec shell -t ssh://user@hostname -i ~/.ssh/id_rsa --sudo

Interactive Testing in InSpec Shell

My Typical Workflow:

# Start InSpec shell
$ inspec shell -t ssh://ubuntu@webserver -i ~/.ssh/id_rsa

Welcome to the interactive InSpec Shell
To find out how to use it, type: help

# Check if nginx is installed
inspec> package('nginx').installed?
=> true

# Verify nginx service status
inspec> service('nginx').running?
=> true

# Check file permissions
inspec> file('/etc/nginx/nginx.conf').mode
=> 0644

# Test SSL configuration
inspec> nginx_conf.params['ssl_protocols']
=> ["TLSv1.2", "TLSv1.3"]

# Exit shell
inspec> exit

Pro Tip: I use InSpec shell to test individual resources before writing full profiles. It's faster than the edit-run-debug cycle.

Using InSpec Shell with Controls

You can even test complete controls interactively:

inspec> describe sshd_config do
inspec>   its('Protocol') { should eq '2' }
inspec>   its('PermitRootLogin') { should eq 'no' }
inspec> end

  ✔  SSH Configuration Protocol should eq "2"
  ✔  SSH Configuration PermitRootLogin should eq "no"

Summary: 2 successful, 0 failures, 0 skipped

Creating Your First InSpec Profile

Generating a Profile

# Create a new profile
inspec init profile linux-baseline
cd linux-baseline

# View structure
tree

Generated Structure:

linux-baseline/
├── README.md
├── controls/
│   └── example.rb
├── inspec.yml
└── libraries/

Understanding inspec.yml

The inspec.yml file contains profile metadata:

name: linux-baseline
title: Linux Security Baseline
maintainer: Your Name
copyright: Your Organization
copyright_email: [email protected]
license: Apache-2.0
summary: Security baseline for Linux systems
version: 1.0.0
supports:
  - platform-family: linux

Writing Controls

Edit controls/ssh.rb:

# encoding: utf-8
# copyright: 2024, Your Organization

title 'SSH Server Configuration'

control 'ssh-01' do
  impact 1.0
  title 'SSH Protocol Version'
  desc 'Ensure SSH Protocol 2 is configured'
  desc 'rationale', 'SSH Protocol 1 has known vulnerabilities'
  desc 'check', 'Review sshd_config for Protocol setting'
  desc 'fix', 'Set Protocol 2 in /etc/ssh/sshd_config'
  
  tag severity: 'critical'
  tag cis: '5.2.4'
  tag nist: ['AC-17', 'IA-5']
  
  ref 'CIS Distribution Independent Linux Benchmark', 
      url: 'https://www.cisecurity.org/benchmark/distribution_independent_linux'
  
  describe sshd_config do
    its('Protocol') { should eq '2' }
  end
end

control 'ssh-02' do
  impact 1.0
  title 'Disable Root Login'
  desc 'Ensure root login via SSH is disabled'
  
  tag severity: 'critical'
  
  describe sshd_config do
    its('PermitRootLogin') { should eq 'no' }
  end
end

control 'ssh-03' do
  impact 0.8
  title 'Disable Password Authentication'
  desc 'Use key-based authentication instead of passwords'
  
  tag severity: 'high'
  
  describe sshd_config do
    its('PasswordAuthentication') { should eq 'no' }
    its('PubkeyAuthentication') { should eq 'yes' }
  end
end

What I Include in Every Control:

• impact - Severity rating (0.0-1.0)

• title - Clear, descriptive name

• desc - What the control tests

• tag - Metadata for reporting and filtering

• ref - Reference documentation

Running InSpec Profiles

Local Execution

# Run profile against localhost
inspec exec linux-baseline

# Run with detailed output
inspec exec linux-baseline --log-level debug

# Run specific control
inspec exec linux-baseline --controls ssh-01

Remote Execution

# SSH target
inspec exec linux-baseline -t ssh://user@host -i ~/.ssh/id_rsa

# Multiple targets using SSH config
inspec exec linux-baseline -t ssh://webserver1
inspec exec linux-baseline -t ssh://webserver2

# Windows via WinRM
inspec exec windows-baseline -t winrm://admin@winserver --password 'Pass123!'

# Docker container
inspec exec linux-baseline -t docker://container_name

My Real-World Example

Running compliance checks across my web tier:

# Create list of targets
cat > targets.txt << EOF
ssh://[email protected]
ssh://[email protected]
ssh://[email protected]
EOF

# Run against all targets
while read target; do
  echo "Scanning $target"
  inspec exec linux-baseline -t $target -i ~/.ssh/prod_key \
    --reporter json:results/$(echo $target | cut -d@ -f2).json
done < targets.txt

Generating Reports

InSpec supports multiple output formats for different audiences:

CLI Output (Default)

inspec exec linux-baseline

Output:

Profile: Linux Security Baseline
Version: 1.0.0
Target:  ssh://ubuntu@webserver

  ✔  ssh-01: SSH Protocol Version
     ✔  SSH Configuration Protocol should eq "2"
  ✔  ssh-02: Disable Root Login
     ✔  SSH Configuration PermitRootLogin should eq "no"
  ✖  ssh-03: Disable Password Authentication
     ✖  SSH Configuration PasswordAuthentication should eq "no"
     
     expected: "no"
          got: "yes"

Profile Summary: 2 successful controls, 1 control failure, 0 controls skipped
Test Summary: 3 successful, 1 failure, 0 skipped

JSON Report

# Generate JSON for programmatic processing
inspec exec linux-baseline --reporter json:report.json

# Or send to Chef Automate
inspec exec linux-baseline --reporter json:report.json cli

I use JSON reports for:

• Integration with CI/CD pipelines

• Custom dashboards and metrics

• Feeding Chef Automate

• Historical trend analysis

HTML Report

# Generate human-readable HTML report
inspec exec linux-baseline --reporter html:report.html

# Open in browser
open report.html  # macOS
xdg-open report.html  # Linux

Perfect for:

• Sharing with management

• Audit evidence

• Team reviews

JUnit XML (for CI/CD)

# Generate JUnit format for Jenkins/GitLab CI
inspec exec linux-baseline --reporter junit:results.xml

Working with InSpec Inputs

Inputs make profiles flexible and reusable across environments.

Defining Inputs

In controls/nginx.rb:

# Define input with default
input('nginx_version', 
  value: '1.18.0',
  description: 'Minimum required nginx version'
)

input('allowed_ports',
  value: [80, 443],
  description: 'Allowed listening ports'
)

control 'nginx-01' do
  impact 0.7
  title 'Nginx Version'
  
  describe package('nginx') do
    its('version') { should >= input('nginx_version') }
  end
end

control 'nginx-02' do
  impact 0.5
  title 'Nginx Listening Ports'
  
  input('allowed_ports').each do |allowed_port|
    describe port(allowed_port) do
      it { should be_listening }
    end
  end
end

Providing Input Values

# Via command line
inspec exec nginx-profile \
  --input nginx_version=1.20.0 \
  --input allowed_ports="[80,443,8080]"

# Via input file (inputs.yml)
cat > inputs.yml << EOF
nginx_version: 1.20.0
allowed_ports:
  - 80
  - 443
  - 8080
EOF

inspec exec nginx-profile --input-file inputs.yml

My Use Case: I maintain environment-specific input files (dev-inputs.yml, prod-inputs.yml) to test the same profile with different expectations.

Using Pre-Built Profiles from Chef Supermarket

Why reinvent the wheel? I leverage community profiles extensively.

Finding Profiles

Browse available profiles at Chef Supermarket.

Popular Profiles I Use:

• dev-sec/linux-baseline - Linux security baseline

• dev-sec/ssh-baseline - SSH hardening

• dev-sec/nginx-baseline - Nginx security

• cis/cis-docker-benchmark - CIS Docker Benchmark

Running Supermarket Profiles

# Run directly from Supermarket
inspec supermarket exec dev-sec/linux-baseline

# Run against remote target
inspec supermarket exec dev-sec/linux-baseline \
  -t ssh://user@host -i ~/.ssh/id_rsa

Customizing Supermarket Profiles

Create a wrapper profile to customize community profiles:

# Create wrapper profile
inspec init profile my-linux-baseline
cd my-linux-baseline

Edit inspec.yml:

name: my-linux-baseline
title: My Custom Linux Baseline
version: 1.0.0
depends:
  - name: linux-baseline
    supermarket: dev-sec/linux-baseline
    version: '>= 2.0'

Create controls/overrides.rb:

# Include base profile
include_controls 'linux-baseline' do
  # Skip specific control
  skip_control 'os-01'
  
  # Override control with custom check
  control 'os-02' do
    impact 0.9
    title 'Custom OS Check'
    
    describe file('/etc/custom-config') do
      it { should exist }
    end
  end
end

Real-World Compliance Scenario: PCI-DSS

Let me share how I use InSpec for PCI-DSS compliance:

The Challenge

I needed to ensure continuous PCI-DSS compliance for systems processing payment data:

• Requirement 2.2: Secure system configurations

• Requirement 8.2: User authentication controls

• Requirement 10.2: Audit logging

The Solution

Created a custom PCI-DSS profile:

# controls/pci-req-2.2.rb
control 'pci-2.2-01' do
  impact 1.0
  title 'PCI-DSS Req 2.2 - Remove Unnecessary Services'
  desc 'Ensure only necessary services are running'
  tag pci: '2.2'
  
  unnecessary_services = ['telnet', 'rsh', 'rlogin']
  
  unnecessary_services.each do |svc|
    describe package(svc) do
      it { should_not be_installed }
    end
  end
end

# controls/pci-req-8.2.rb
control 'pci-8.2-01' do
  impact 1.0
  title 'PCI-DSS Req 8.2 - Password Complexity'
  desc 'Enforce strong password policy'
  tag pci: '8.2'
  
  describe file('/etc/security/pwquality.conf') do
    its('content') { should match /minlen\s*=\s*([8-9]|[1-9]\d+)/ }
    its('content') { should match /dcredit\s*=\s*-1/ }
    its('content') { should match /ucredit\s*=\s*-1/ }
  end
end

# controls/pci-req-10.2.rb
control 'pci-10.2-01' do
  impact 1.0
  title 'PCI-DSS Req 10.2 - Audit Logging Enabled'
  desc 'Ensure comprehensive audit logging'
  tag pci: '10.2'
  
  describe service('auditd') do
    it { should be_enabled }
    it { should be_running }
  end
  
  describe auditd_conf do
    its('log_file') { should eq '/var/log/audit/audit.log' }
    its('max_log_file_action') { should eq 'rotate' }
  end
end

The Execution

# Run daily via cron
0 2 * * * inspec exec /opt/inspec/pci-dss-baseline \
  -t ssh://localhost \
  --reporter json:/var/log/inspec/pci-$(date +\%Y\%m\%d).json \
  cli > /var/log/inspec/pci-latest.log

The Results

• Automated daily compliance validation

• Immediate alerts on compliance drift

• Pre-generated audit evidence

• 90% reduction in audit preparation time

Best Practices from My Experience

1. Organize Controls Logically

controls/
├── 01-filesystem.rb
├── 02-users-groups.rb
├── 03-network.rb
├── 04-services.rb
└── 05-logging.rb

2. Use Meaningful Impact Levels

impact 1.0   # Critical - must pass
impact 0.7   # High - should pass
impact 0.5   # Medium - nice to pass
impact 0.3   # Low - informational

3. Tag Everything

tag severity: 'critical'
tag cis: '5.2.4'
tag nist: ['AC-17']
tag environment: 'production'
tag remediation_time: '< 1 hour'

4. Provide Context

desc 'check', 'How to manually verify this requirement'
desc 'fix', 'Steps to remediate failures'
desc 'rationale', 'Why this control is important'
ref 'Documentation', url: 'https://example.com/docs'

5. Test Before Deploy

# Validate profile syntax
inspec check my-profile

# Test against test system first
inspec exec my-profile -t ssh://test-system

Integration with CI/CD

InSpec fits perfectly into automated pipelines:

GitLab CI Example

# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

validate-profile:
  stage: validate
  script:
    - inspec check compliance-profile
  
compliance-test:
  stage: test
  script:
    - inspec exec compliance-profile -t ssh://test-server
      --reporter junit:results.xml
  artifacts:
    reports:
      junit: results.xml

What's Next?

You now understand how to: ✅ Use InSpec shell for interactive testing ✅ Create custom compliance profiles ✅ Run tests locally and remotely ✅ Generate reports for different audiences ✅ Leverage community profiles ✅ Integrate InSpec with CI/CD

Continue to Chef Automate Overview to see how InSpec integrates with centralized compliance reporting, or explore Best Practices for production deployment patterns.

Compliance as code isn't just about meeting audit requirements - it's about building confidence in your infrastructure's security posture every single day.

---

Ready to explore Chef Automate? Continue to Chef Automate Overview