All posts

Blog

Automating IBM Confidential Computing contracts

Go · Confidential Computing · Open Source

Confidential computing on IBM Z asks for one thing of every workload: it has to come wrapped in a cryptographically signed contract. That contract is a single document that binds three things together — the workload itself, the environment it’s allowed to run in, and the keys that signed it.

The first time you generate one of these by hand, it’s a fun puzzle. The fiftieth time, it’s a bug factory. Each contract needs signing, attestation, and encryption, with very little margin for error, and almost none of that scales the moment more than one team gets involved.

So we built tooling for it.

What we shipped

  • contract-go — a Go SDK that handles signing, attestation, and encryption end-to-end.
  • contract-cli — a small, friendly CLI built on contract-go, so platform teams can generate contracts without touching the cryptographic plumbing themselves.
  • terraform-provider-hpcr — declarative, reproducible contract generation that fits naturally next to the rest of your IBM Cloud or on-prem Terraform.

A typical workflow ends up looking like this:

contract-cli generate \
  --workload workload.yaml \
  --signing-key signing.pem \
  --out contract.signed

One command, one signed contract, no hand-edited OpenSSL invocations.

What started life as IBM-internal tooling now ships in the open under ibm-hyper-protect. It’s used by enterprise customers who genuinely need confidential workloads, but who’d rather not become part-time cryptographers to get there. The work was recognised with IBM TCAP Significant Contributor 2025 and TCAP Leader 2026. The full case study, including links to every repo, lives on the work page.

A few things shipping it taught me

  1. Design the SDK around the workflow, not the cryptography. The crypto is the implementation detail. The workflow is the product.
  2. Make the CLI feel like a normal CLI. Real flags, real exit codes, output you can pipe into the next tool. Anything else and people will stop using it.
  3. Treat the Terraform provider as a first-class consumer of your SDK. If the provider feels awkward to write, the SDK probably is too — and the provider is your fastest feedback loop on that.
Back to all posts