Remote & cloud targets

SSH, WinRM, and cloud APIs.

One of InSpec’s strengths is that the same control language runs against many kinds of target via the -t transport. Local (the default), SSH (ssh://user@host, for Linux servers), WinRM (winrm://, for Windows), Docker (docker://container), and cloud APIs (aws://, azure://, gcp://) for testing cloud resources rather than hosts. You write the control once; the transport decides what it runs against. This is what lets one tool cover servers, containers, and cloud posture.

$ inspec exec baseline -t ssh://ops@web1 -i ~/.ssh/id_ed25519   # a Linux host
$ inspec exec baseline -t docker://payments-api                  # a container
$ inspec exec aws-baseline -t aws://                             # AWS account (uses creds)

Cloud and agentless scanning

The cloud transports (with the InSpec AWS/Azure/GCP resource packs) let you write controls over cloud resources — “no security group open to 0.0.0.0/0,” “S3 buckets have encryption” — checked against the live account via its API, complementing the pre-deploy view from Checkov with a runtime one. And because SSH/WinRM scanning needs no agent on the target (just access), InSpec can assess a fleet without installing anything, which matters for auditing systems you do not own the provisioning of.

describe aws_s3_bucket('acme-logs-prod') do
  it { should_not be_public }
  it { should have_default_encryption_enabled }
end
describe aws_security_group('sg-123') do
  it { should_not allow_in(port: 22, ipv4_range: '0.0.0.0/0') }
end