Delivering Signed E-Books with Ansible, GitHub, Red Hat, and Crypto Infrastructure

Bartholomew 'Baz' Q. Fizzlebang Principal Platform Visionary and YAML Archaeologist

October 8, 2026 5 min read

The Problem: E-Books Need a Delivery Control Plane¶

Our sales engineering team publishes crypto e-books for field teams, partners, and compliance reviewers. Fourteen PDFs, each with pricing tables, regulatory notes, and product claims. The old process lived on a shared drive and a group inbox. A reader could open a stale copy, a partner could receive an unsigned file, and nobody could prove which version was approved. A regulatory review asked for a byte-for-byte audit trail across three years. That request turned e-book delivery into an infrastructure problem.

We decided the e-books should be treated like production software artifacts. GitHub becomes the source of truth. Ansible orchestrates releases. Red Hat OpenShift runs the build and signing services. Crypto gives us integrity and non-repudiation. The result is a repeatable path from a pull request to a verified reader download.

flowchart TD A[Author pushes e-book source to GitHub] --> B[GitHub Actions validates manifest] B --> C[Ansible Automation Platform job template] C --> D[Red Hat OpenShift build pipeline] D --> E[Crypto signing service creates detached signature] E --> F[Object storage bucket for e-books] F --> G[Event bus publishes release event] G --> H[Notification service sends reader link] H --> I[Reader downloads e-book] C --> J[Inventory and drift remediation] J --> D

Source of Truth in GitHub¶

Each e-book has a dedicated repository. The repository contains the manuscript, a manifest.yaml, a theme package, and a release policy. The manifest records title, audience, classification, version, and the public key fingerprint expected for the release. A pull request triggers GitHub Actions. The workflow runs markdown lint, schema validation, PDF rendering in a pinned container, and a metadata diff against the previous release. On merge to main, the workflow calls Ansible Automation Platform through a signed webhook. GitHub branch protection requires two reviewers, one from product and one from compliance. Every release maps to a commit SHA, so we can trace any reader download back to the exact source.

Ansible as the Orchestration Layer¶

Ansible Automation Platform is the conductor. It consumes a Git-backed dynamic inventory for dev, staging, and production. A release playbook creates the OpenShift namespace, applies quotas, network policies, service accounts, and secrets. It provisions the signing job, waits for the build to finish, verifies the signature, and publishes the release event. A second playbook runs nightly to compare live cluster objects against the desired state and remediate drift. We use job templates, inventories, and credentials in Ansible Automation Platform rather than ad hoc scripts. This gives us repeatability and a clean audit record for every environment.

Red Hat OpenShift Runtime¶

The runtime is a set of OpenShift deployments. The builder service renders each e-book into PDF and EPUB. The signer service computes SHA-256 digests and creates detached signatures. The portal service serves the internal reader experience. The download service enforces policy before issuing a signed, short-lived URL. The services run behind a service mesh with mTLS. Network policies allow only the release pipeline to call the signer. Horizontal pod autoscaling handles the burst when a new e-book is announced. Resource quotas keep the platform predictable. Red Hat OpenShift gives us a consistent runtime from staging to production.

Policy, Identity, and GitOps Controls¶

We use Argo CD to sync the release application from a GitOps repository. Open Policy Agent Gatekeeper and Kyverno enforce image provenance and resource limits. SPIFFE/SPIRE issues workload identities, so signer and portal services authenticate without shared secrets. Cilium provides eBPF network visibility. Falco watches for unexpected process activity in builder pods. PostgreSQL stores release metadata and audit indexes. Redis caches reader entitlements. This layer is essential because e-books contain regulated crypto material and must be served only to approved audiences.

Crypto and Release Integrity¶

The signer uses ECDSA P-256 keys. Private keys live in Vault and are never written to GitHub. Public keys are distributed through a ConfigMap and pinned in the reader portal. Every release produces a detached signature and a manifest. The portal verifies both before it serves a download. If the signature does not match, the release is blocked and the event bus receives a failed-release message. We also append release records to an immutable transparency bucket. Compliance can prove which bytes were approved, when they were signed, and which key was used. Crypto is not a checkbox here; it is the mechanism that makes e-book delivery trustworthy.

Event-Driven Delivery and Observability¶

A release publishes to the Kafka topic ebook.release.v1. The notification service sends an email with a signed, short-lived URL. The download service writes an audit record for every request. Prometheus, Grafana, Loki, and OpenTelemetry give us metrics, logs, and traces across the whole path. Alerts fire for signature failures, inventory drift, missing manifests, and stalled Ansible jobs. Runbooks are versioned in Ansible and linked from alert annotations. The platform is observable from the first pull request to the final download.

Failure Handling and Rollback¶

If a build fails, Ansible stops the release before signing. If signing succeeds but verification fails, the release event is marked failed and the portal keeps serving the previous signed manifest. Rollback is a Git revert in the e-book repository, followed by an Ansible job template that promotes the last known good release. PostgreSQL retains release indexes, and the transparency bucket retains signatures. This gives us a clear rollback path without manual file copying. We can rehearse the whole flow in staging with the same playbooks, the same OpenShift policies, and the same crypto verification path.

Why This Works for Us¶

The e-book pipeline now handles fourteen titles and will soon cover forty. Releases move from two days of manual assembly to about eighteen minutes of automated flow. We have zero unsigned releases since launch. We can answer audit questions with a commit SHA, a signature, and an event record. The infrastructure is reproducible, the source is in GitHub, the runtime is on Red Hat OpenShift, and the release path is driven by Ansible. The crypto layer gives every e-book the same integrity guarantee we expect from software artifacts. This is how a modern engineering organization should deliver e-books.

Grug's Perspective

grugbrain.dev

Grug thinks

Grug's Reaction to the Complexity¶

Grug read post. Grug head hurt. Grug see fourteen PDF. Fourteen. Not moon rocket. Not bank. Just book with pictures and words.

Post say need GitHub, Ansible, OpenShift, Argo CD, Vault, Kafka, SPIFFE/SPIRE, Cilium, Falco, Kyverno, Gatekeeper, Prometheus, Grafana, Loki, OpenTelemetry, PostgreSQL, Redis, service mesh, event bus, transparency bucket. Grug think author fall into buzzword pit and hit every branch on way down.

Grug understand wanting signed book and audit trail. Good. But Grug not understand why deliver PDF require more infrastructure than small country. Author say 'delivery control plane.' Grug say that book, not airplane. Grug suspect if you remove word 'crypto' and 'pipeline,' post become three paragraphs and nap.

Grug see 'zero unsigned releases since launch' and think: Grug also have zero unsigned releases. Grug use one signing command and folder. Grug not need pod autoscaler to send PDF. Grug not need eBPF to know book file is there. Grug not need Kafka to tell Grug book ready. Grug can yell across cave. Work fine.

Grug say: complexity demon got this one. Author build cathedral to mail letter. Cathedral have many doors, many keys, many alarms, and probably one guy who know why door B talk to door F. When guy leave, cathedral fall down. Grug scared.

Grug believe audit trail good. But audit trail can be git log, signature file, and version text. Not every audit need seventeen services and a mesh of mTLS. Grug think post solve problem of 'we want simple signed PDF delivery' by inventing second job: operate small cloud platform.

Grug final reaction: too much. Much too much. Brain hurt. Need sit on rock.

Grug solution

Grug's Simple Solution¶

Grug put fourteen PDF in one Git repo. Maybe folder per book. File name have version and date, like crypto-book-v3-2025-01-10.pdf. Git history is source of truth. No separate manifest galaxy needed; if Grug need list, Grug write releases.txt.

Grug write one small shell script. Script do:

Render PDF from source or copy approved PDF.
Run sha256sum on PDF.
Sign checksum with one key using gpg or minisign.
Put PDF, checksum, and signature in one static bucket or web folder.
Append line to releases.txt with version, date, commit SHA, checksum.
Send reader boring link.

For audit: Grug show git commit, PDF, checksum file, signature file. Compliance ask 'which bytes approved?' Grug point at file and signature. Done. Three years? Git keep history. Bucket keep old files. Boring work forever.

If need control who download, Grug use unguessable link or basic password. If need short-lived URL, Grug use one small function on one server. Not build city to guard one bookshelf.

Grug deploy by copying files to bucket. Rollback by copying previous file back or pointing link to previous version. No Kubernetes. No service mesh. No event bus. No seventeen dashboards. Grug maybe set one alert: 'script fail, send Grug message.' That enough.

Grug solution: one repo, one script, one bucket, one signature, one boring README. Fourteen PDF not distributed system. Grug ship book. Then Grug go eat berry.

Comments 7

DevOps Dana Nov 8, 2026

This is a fascinating pipeline, but I keep wondering if the complexity is justified for fourteen PDFs. Ansible plus OpenShift plus Argo CD plus OPA, Kyverno, SPIFFE, and Falco feels like a lot of moving parts for e-book delivery. What does the on-call burden look like?

Bartholomew 'Baz' Q. Fizzlebang Author Nov 8, 2026

Fair question. The complexity is mostly inherited from the compliance requirement: we need non-repudiation, workload identity, and a byte-for-byte audit trail across years. For fourteen titles it looks heavy, but the same playbooks already handle staging and rollback, and we expect forty titles soon. The on-call runbooks are versioned in Ansible and most alerts map to a single job template.

Platform Pete Nov 8, 2026

The part that sold me was reusing the same crypto verification path in staging and production. That is usually where document pipelines get hand-wavy.

Skeptical Sam Nov 8, 2026

Still feels like a Rube Goldberg machine. Couldn't you just use a managed document signing service and object storage pre-signed URLs?

Security Sally Nov 8, 2026

ECDSA P-256 with Vault is solid, but I want to know more about key rotation. How are public key fingerprints rolled into manifests without breaking existing reader downloads? And who can approve a new signing key?

Bartholomew 'Baz' Q. Fizzlebang Author Nov 8, 2026

We pin fingerprints in manifest.yaml and the portal trusts a small set of active public keys. Rotation is two steps: publish the new public key, switch the signer alias, then retire the old key after the previous release window. A compliance reviewer and platform lead approve key changes.

Crypto Carla Nov 8, 2026

The transparency bucket is the underrated part. If you can prove which key signed which bytes, rotation becomes an audit exercise instead of a scramble.

Ansible Aggie Nov 8, 2026

Nice to see Ansible Automation Platform used as orchestration rather than a pile of shell scripts. How do you handle secrets for OpenShift namespace creation? Are credentials stored in AAP or pulled from Vault at runtime?

Bartholomew 'Baz' Q. Fizzlebang Author Nov 8, 2026

AAP credentials reference Vault; the playbook never prints secret values. Namespace service accounts get short-lived tokens, and the signer key stays in Vault. We also use no_log on tasks that touch credential material.

Frontend Fred Nov 8, 2026

The reader experience sounds almost like an afterthought. Signed short-lived URLs are great, but what happens when a reader forwards the link? Do you bind downloads to identity, or is the URL the only control?

Bartholomew 'Baz' Q. Fizzlebang Author Nov 8, 2026

The URL is short-lived and single-use for external readers; internal readers also go through portal entitlements in Redis. We log every issue and redemption. If a link is shared, the audit record shows it and the download service can revoke the entitlement.

Compliance Kim Nov 8, 2026

This is exactly the question our reviewers ask. Entitlement revocation plus audit records is what makes the short-lived URL defensible.

GitOps Greg Nov 8, 2026

Argo CD syncing the release app from Git is good, but how do you avoid fighting Ansible and Argo over the same cluster objects? Which one owns namespaces, quotas, and network policies?

Bartholomew 'Baz' Q. Fizzlebang Author Nov 8, 2026

Ansible owns release scaffolding and signing job lifecycle; Argo owns the long-running application manifests. We keep the boundary explicit in the playbooks and the GitOps repo to avoid drift fights.

Audit Alice Nov 8, 2026

The three-year byte-for-byte audit trail is the real win. Can you share how the transparency bucket is made immutable? Object lock, WORM storage, or hash chaining?

Bartholomew 'Baz' Q. Fizzlebang Author Nov 8, 2026

We use object lock in compliance mode plus a hash chain in PostgreSQL for release indexes. The bucket is append-only from the signer service account, and deletion requires a break-glass workflow.

Pragmatic Paul Nov 8, 2026

Only ShitOps would make PDF delivery look like a regulated software supply chain. That said, eighteen minutes from merge to reader link is impressive. What happens when Kafka is down?

Bartholomew 'Baz' Q. Fizzlebang Author Nov 8, 2026

Notification is decoupled from release integrity. If Kafka is down, the signed release is still stored and the portal can serve it to entitled readers; notification retries from an outbox. We alert on consumer lag and failed release events.