Steampipe/Powerpipe Stack¶

The Steampipe/Powerpipe Stack is the platform's main method for machine-based KSI ingestion. Stratus provides a deployment template that installs Steampipe and Powerpipe with Stratus mods inside your own cloud environment. The stack runs on a schedule, evaluates your live cloud configuration against FedRAMP 20x Key Security Indicators, and writes JSON snapshots to a storage container in your account that the platform ingests and turns into KSI validation records -- so your compliance evidence reflects what is actually deployed, not what a document says should be.

What it is¶

The stack is three open-source layers plus the Stratus mods that make the output mean something to the platform:

Steampipe documentation

Powerpipe documentation

How it works¶

The pipeline runs end to end without anyone touching it:

1. Deploy the scanner stack. Stratus provides the templates during onboarding; you deploy the scanner stack once, into whichever of your accounts should run the scans. The scanner's identity carries only the cloud provider's managed read-only policies, so it cannot modify anything it inspects.
2. Cover your other accounts. For every additional account to scan, deploy the member-account template -- a single read-only role that trusts the scanner's identity and requires an external ID you generate. No agents, no per-account schedules, no per-account infrastructure -- the member template adds only a role, which carries no charge.
3. The scheduled task runs. On its schedule, the task starts Steampipe, runs the Stratus mods against each account in turn, and produces per-check, per-resource results.
4. Snapshots land in storage. The task writes one JSON snapshot per account per benchmark to a storage container in your account, then exits -- there is no long-running service and nothing listening for inbound traffic.
5. The platform ingests. You grant Stratus a read-only path to the container, gated on a Stratus-issued external ID, and an n8n workflow polls it for new snapshots and writes them into your GRC-ITSM instance. The snapshots stay in your account, and you can revoke the grant at any time.
6. KSI validation records update. Each ingested result becomes evidence on the matching machine-based KSI: passing checks record the indicator as Satisfied, failures surface as Not Satisfied or Partially Satisfied validation records, and a Not Satisfied result is tracked as a vulnerability until it passes again.

Because the checks run against the live environment, the resulting evidence is continuous: every scheduled run re-validates the same indicators against the current state, which is exactly what machine-based KSI validation asks for.

Architecture¶

flowchart TD
    subgraph scanner ["Client scanner account"]
        A["Scheduled task<br/>(ECS scheduled task today,<br/>Azure runtime planned)"]
        B["Steampipe + Powerpipe<br/>with Stratus mods"]
        D["Storage container<br/>(S3 today, Azure Blob planned)"]
    end
    subgraph members ["Other client accounts"]
        C["Read-only scanner role<br/>(external ID required)"]
    end
    subgraph stratus ["Stratus GRC-ITSM"]
        E["n8n ingestion workflow"]
        F["KSI validation records"]
        G["Vulnerability workflow"]
    end
    A -->|"Runs on schedule"| B
    B -->|"Scans this account directly;<br/>assumes the role to scan others"| C
    B -->|"JSON snapshots<br/>per account per benchmark"| D
    E -->|"Reads via client-granted<br/>role (external ID required)"| D
    E -->|"Writes evidence"| F
    F -->|"Failed checks"| G

The boundary matters: the scanner, its credentials, and the snapshots all live in your accounts. The only cross-boundary access is the ingestion workflow's read of the storage container, which uses a role you create, scope to read-only on that container, gate on an external ID, and can revoke at any time.

Deploying on AWS¶

AWS is the supported runtime today. Stratus provides two CloudFormation templates during onboarding, along with full deployment instructions -- this section covers what they create and the decisions you make, not the click-by-click steps.

The scanner stack provisions:

• An S3 bucket for snapshots -- encrypted, versioned, all public access blocked, with a configurable retention lifecycle (90 days by default), and retained if the stack is ever deleted.
• An ECS Fargate task definition whose task role holds the AWS-managed SecurityAudit and ViewOnlyAccess policies -- read-only, no data-plane reads -- plus permission to assume the member-account role in your other accounts.
• An EventBridge Scheduler that fires the task on a cron you control (daily by default).
• A CloudWatch log group capturing scanner output.
• Optionally, the cross-account reader role Stratus's ingestion assumes -- see Granting Stratus access below.

The task runs in your VPC's private subnets, egress-only: no load balancer, no inbound rules, nothing listening. Both templates create named IAM resources, so deploy them with CAPABILITY_NAMED_IAM.

Choices that matter¶

Most parameters keep their defaults. The ones worth a decision:

Scanning more than one account¶

The scanner stays in one account; every other account gets one read-only IAM role and nothing else. Generate a single external ID (any hard-to-guess value -- a UUID is ideal, and keep it out of source control), then deploy the member-account template into each account with the scanner's account ID, the scanner's task role name (both available as scanner stack outputs), and that external ID. The member role's trust policy pins the specific scanner task role, not the whole scanner account -- that pin is what gates assumption -- and the external ID adds confused-deputy protection on top.

Past three or four accounts, deploy the member template once as a CloudFormation StackSet targeting an Organizational Unit -- accounts added to the OU later pick up the role with no further action. Then list the account IDs and the external ID on the scanner stack and it covers them on the next run.

Granting Stratus access¶

The snapshots sit in your bucket until you grant Stratus's ingestion environment a way to read them. Two options -- pick one:

• Cross-account role (preferred). The scanner stack creates a reader role scoped to read-only on the snapshot bucket, gated on an external ID that Stratus issues per customer -- do not invent your own, since a distinct per-customer value is what prevents one customer's ID from working against another's role. The grant involves no long-lived credentials: Stratus's n8n assumes the role and receives short-lived credentials each time. Until you fill in Stratus's account ID, the role trusts only your own account and nothing external can assume it.
• IAM user access key. Cross-account roles cannot span AWS partitions, so if your account and Stratus's ingestion environment are in different partitions (one commercial, one GovCloud), the stack instead creates an IAM user with the same read-only scope. You generate an access key and provide it to Stratus following the deployment instructions. This is a long-lived credential -- rotate it regularly.

Either way, finish by sending Stratus the snapshot bucket name and (for the role option) the reader role ARN from the stack outputs. Ingestion starts after the next scheduled run, and you can revoke access at any time by removing the role trust or the access key.

Why Steampipe¶

The reason this stack is the main ingestion method rather than a per-service integration is the plugin ecosystem. Steampipe has plugins for AWS, Azure, GCP, Kubernetes, GitHub, Cloudflare, Okta, and well over a hundred other providers, all queryable through the same SQL engine. A KSI that needs evidence from a new service does not need a new integration -- it needs a query against a plugin that already exists, added to the Stratus mods. That keeps machine-based KSI coverage growing with your environment instead of waiting on integration development.

Verify the setup¶

1. Confirm the scheduled task runs to completion in your environment and one JSON snapshot per account per benchmark appears in the storage container after a run. Trigger a run by hand rather than waiting for the schedule -- the deployment instructions Stratus provides with the templates cover this, expected runtimes, and multi-account troubleshooting.
2. In GRC-ITSM, open the KSIs area under Compliance and confirm the machine-based KSIs the mods cover carry fresh validation records after ingestion.
3. Confirm a deliberately failing check (or any known gap) surfaces as a Not Satisfied validation record and its finding enters the vulnerability workflow.
4. Check the 20X reports under Reporting reflect the ingested KSI statuses.