Production hardening across PostQ

“Production-ready” is not a UI state. It is the collection of failure behavior, tenant boundaries, recovery procedures, honest documentation, and repeatable evidence around a product. We audited every PostQ repository with that definition and fixed the highest-risk gaps before adding more surface area.

This release is deliberately broad, but it has one theme: a customer should be able to tell what ran, what it covered, where keys live, whether a retry duplicated data, and which artifact entered their environment.

Kubernetes agent 0.3: real coverage, explicit failure

The agent already parsed TLS Secrets, Ingress resources, and PEM data in ConfigMaps. The Helm chart also advertised cert-manager and service mesh coverage that the binary did not actually perform. Version 0.3 closes that gap with dynamic-client scanners for cert-manager Certificates, Istio PeerAuthentication and DestinationRule resources, and Linkerd MeshTLSAuthentication policies.

• Scoped RBAC now contains only resources the binary reads.
• Namespace failures are aggregated and returned as coverage warnings instead of silently skipped.
• Every logical scan carries one UUID across retries; the API deduplicates it per organization.
• The API recomputes summary counts from findings instead of trusting client totals.
• HTTP 429/5xx and transient network failures use bounded backoff with jitter and Retry-After.
• Agent version, commit, host, OS, and warnings are persisted with the scan.
• Internal and Kubernetes deadlines prevent overlapping, permanently wedged CronJobs.

Organization identity now comes only from the scoped API key. The old chart value remains accepted for compatibility, but it is not sent as an authorization claim.

helm install postq-agent oci://ghcr.io/postqdev/charts/postq-agent \
  --version 0.3.0 \
  --namespace postq --create-namespace \
  --set apiKey="$POSTQ_API_KEY" \
  --set clusterName=prod-east-1

Vault now spans AWS, Azure, and Google Cloud

PostQ Vault already supported customer-owned AWS KMS and Azure Key Vault roots. Google Cloud KMS is now a first-class KEK and classical signing provider.

For KEK custody, PostQ creates a random 256-bit data-encryption key, seals the managed private material with AES-256-GCM, and asks the customer’s Cloud KMS CryptoKey to encrypt that DEK. For the classical half, Vault can create an ECDSA P-256 CryptoKey in the customer’s KeyRing and delegate every signature to Cloud KMS or Cloud HSM. The classical private key never enters PostQ memory.

Authentication uses Application Default Credentials or Workload Identity Federation. PostQ stores KMS resource names, not a long-lived Google Cloud credential.

await pq.vault.putSettings({
  defaultKekProvider: "gcp-kms",
  gcp: {
    kekKeyName: "projects/acme/locations/global/keyRings/postq/cryptoKeys/vault-kek",
    keyRingName: "projects/acme/locations/us-east1/keyRings/postq-signing",
    protectionLevel: "HSM",
  },
});

const key = await pq.hybridKeys.create({
  name: "release-signing",
  algorithm: "mldsa65+ecdsa-p256",
  kekProvider: "gcp-kms",
  keyProvider: "gcp-kms",
});

An important boundary: the ML-DSA half is still PostQ-managed unless an explicitly supported enclave provider is selected. We do not claim that AWS CloudHSM, Azure Managed HSM, or Google Cloud KMS currently provides the ML-DSA integration represented by the reserved roadmap provider names.

SDK 0.6: the API contract is one contract again

A line-by-line comparison found drift in Policy, Ledger, Vault, audit, and hybrid-provider shapes — especially in Python and .NET. Version 0.6 aligns JavaScript, Python, and .NET to the live Fastify routes and expands the OpenAPI source of truth to include those route families.

• Live server-side URL and cloud scan helpers in all three SDKs.
• Provider-aware hybrid key creation, including Google Cloud KMS.
• Correct enforce/warn/audit Policy rules and environment scopes.
• Correct Ledger hash-chain fields, checkpoint pagination, seal results, proofs, and bundles.
• Correct Vault defaultKekProvider requests and save/clear envelopes.
• Browser-safe UTF-8 base64 encoding in the JavaScript SDK.

API operations: fail closed and leave evidence

The API now exposes a database-backed /ready probe in addition to liveness, runs as a non-root container user, and shuts down gracefully. Responses carry request IDs, no-store caching, content-type and frame protections, permission restrictions, and HSTS in production. Structured logs redact authorization and cookie fields.

Kubernetes ingest no longer acknowledges a scan if finding or asset persistence fails. A replay returns the original completed scan, while reusing the same idempotency key for a different scan returns a conflict.

CLI and MCP: bounded agent execution

postq-mcp now ships in the same release archive as the CLI. It keeps stdout protocol-only while bounding JSON-RPC frames, payloads, subprocess output, and execution time. Invalid JSON gets a proper JSON-RPC parse error, tool inputs are validated, and subprocess deadlines cancel the child process.

The CLI also refuses remote plaintext API endpoints (loopback HTTP is retained for development), bounds API response bodies, propagates read failures, and redacts PostQ keys from error output.

Enclave and transparency boundaries

The enclave’s signing counter is now persisted per key before use, so a restart cannot reuse a counter. New opaque key references have 128 bits of entropy, record writes are atomic and synced, and references are validated before filesystem access. Non-loopback RPC requires an explicit opt-in plus TLS and bearer authentication; production mode also refuses mock attestation and filesystem-generated seal keys.

PQ Transparency can require a write token while leaving reads and offline verification public. Production mode requires both an injected ML-DSA signing key and a strong write token. Remote witness calls retry transient failures with bounded response reads, and the PostQ Ledger supplies the write token when anchoring a seal.

Verifiable builds and broader tests

Kubernetes and Azure scanner images now publish BuildKit SBOM and provenance attestations and are keylessly signed by the release workflow. The Helm OCI artifact is signed as well. CLI archives add an SBOM and GitHub build-provenance attestation.

New CI covers the scanner web app, Kubernetes agent race tests, Helm rendering, cloud deploy scripts, enclave, transparency log and witness, Azure inventory classification/redaction, and the educational lab’s vulnerable-versus-hardened behavior. We also fixed a reusable HTTP mock that could make the .NET pagination test loop forever — a useful reminder that the test harness itself is production infrastructure.

What is not GA

Production hardening also means saying no to invented completeness. These boundaries remain explicit:

• Google Cloud cryptographic inventory scanning is Roadmap; Google Cloud KMS custody is implemented.
• Mock enclave attestation is development-only. Hardware-backed vendor paths require their own deployment and evidence.
• The standalone scanner’s non-URL web tabs remain labelled demo; live evidence comes from the API, CLI, or agents.
• PQ Transparency remains a single-writer service; production operation requires backup, key escrow, and independent witnesses.
• Commercial SLA, residency, and retention commitments belong in a customer contract and tested runbook, not an unchecked marketing sentence.

The current, shareable status is maintained in the capability matrix, and the production runbook now makes migrations, tenant-isolation tests, backup restores, rollback, and provider smoke tests release gates rather than tribal knowledge.

Start with the live scanner at postq.dev/scanner, or contact us for a scoped deployment review.