In the evolving landscape of cloud security, we often talk about “defense in depth” and “zero trust,” but rarely do we see implementations that truly embody these principles at every layer. Most infrastructure deployments still rely on long-lived credentials, implicit trust boundaries, and the hope that our CI/CD pipelines haven’t been compromised.
What if every deployment required physical proof of approval? What if credentials expired within minutes instead of months? What if your infrastructure could verify not just who deployed it, but exactly what was deployed—down to the cryptographic fingerprint?
This isn’t theoretical. This architecture exists, and it challenges everything we thought we knew about secure infrastructure deployment.
1. Hardware-Bound Deployments: Your YubiKey Becomes Your Deployment Authority
The most striking innovation here is the assertion that no Terraform plan should exist unsigned—ever. Not in your CI/CD pipeline. Not in your artifact storage. Nowhere.
“Every Terraform plan is signed with a YubiKey PIV certificate — unsigned plans never exist in storage.”
Think about the implications. In traditional workflows, we sign container images after they’re built. We sign Git commits after they’re written. But here, the infrastructure changes themselves are cryptographically bound to a physical hardware token before they’re even stored.
Why this matters: Compromising the deployment pipeline no longer grants an attacker the ability to deploy. They would need physical access to the YubiKey and knowledge of its PIN. This transforms infrastructure deployment from a “what you know” problem (credentials, tokens) to a “what you have” problem (physical hardware).
The elegance is in the inversion: instead of protecting the deployment pipeline, the pipeline becomes irrelevant without the hardware key. The YubiKey PIV slot becomes the root of trust, and everything flows from there.
2. Ephemeral Certificates That Auto-Revoke: 10-Minute Credentials for Each Deployment
We live in a world where TLS certificates are valid for 90 days, sometimes a year. We’ve normalized credential lifespans measured in months. This architecture obliterates that paradigm.
“Vault PKI issues a single-use TLS cert for each OCI Function deployment — auto-revoked after update.”
Every function deployment receives a certificate with a 10-minute TTL, issued by HashiCorp Vault’s PKI engine. Once the deployment updates, the certificate is immediately revoked. This isn’t credential rotation—it’s credential evaporation.
The counter-intuitive insight: The shorter the credential lifetime, the simpler your security model becomes. No rotation schedules. No certificate renewal logic. No “what happens when the cert expires mid-deployment” edge cases. The credential exists only long enough to prove the deployment’s validity, then vanishes.
This approach transforms how we think about credential management. Instead of asking “how do we protect long-lived credentials,” we ask “why do credentials need to exist longer than the operation they authorize?”
3. Fingerprint-Bound Function Execution: Code That Refuses to Run Without Proof
Here’s where it gets truly fascinating. The OCI Function doesn’t just check credentials—it validates that the deployment fingerprint matches the certificate fingerprint embedded during deployment.
# From handler.py
cert_fingerprint_hex = cert.serial_number.to_bytes(8, "big").hex()
if plan_fingerprint != cert_fingerprint_hex:
raise Exception("Plan fingerprint mismatch – unauthorized deployment")
The function refuses to execute unless the X-Plan-Fingerprint header matches the certificate’s binding. This creates an immutable audit chain: YubiKey signature → Terraform plan → Vault certificate → Function runtime.
The paradigm shift: Traditional security asks “is this caller authorized?” This system asks “is this exact deployment authorized?” A compromised function invocation endpoint can’t be used to run arbitrary code—it can only run the code that was YubiKey-approved.
This is infrastructure immutability taken to its logical extreme. You’re not just preventing unauthorized changes; you’re cryptographically ensuring that only the precise, signed changes can execute.
4. The Vault AppRole Architecture: Trust Delegation Without Credential Leakage
The use of HashiCorp Vault’s AppRole authentication for Terraform deserves special attention. Many organizations struggle with how to authenticate Terraform in CI/CD pipelines without exposing cloud credentials.
This implementation uses Vault as an authentication broker:
- Terraform authenticates to Vault using AppRole (role ID + secret ID)
- Vault issues short-lived TLS certificates bound to deployment fingerprints
- Functions validate those certificates at runtime
The breakthrough: Vault becomes the single source of truth for “what deployments are authorized,” while the YubiKey remains the source of truth for “who authorized this deployment.” The separation of concerns is elegant—authentication, authorization, and cryptographic proof are distinct layers that reinforce each other.
You’re not storing cloud credentials in CI/CD. You’re not rotating API keys. You’re requesting just-in-time proof of authorization from a central authority, bound to a hardware-signed artifact.
5. The Tamper-Test Success Criterion: Security Through Mathematical Certainty
The README includes a success criterion that seems almost dismissive in its simplicity:
“Tamper test: Modify plan → signature fails → Function rejects”
But this single line encapsulates the entire security model. If you change even one byte in the Terraform plan, the signature verification fails. No signature, no deployment. No exceptions. No override flags. No emergency break-glass procedures.
The philosophical shift: Most security systems operate on probabilistic detection—we try to catch tampering through alerts, monitoring, and anomaly detection. This system makes tampering mathematically impossible to hide. You can modify the plan, but you can’t make the function accept it without the YubiKey.
This represents a move from detective controls (we’ll notice if something’s wrong) to preventive controls (wrong things simply cannot happen). The system doesn’t detect unauthorized deployments—it makes them impossible.
The Future of Deployment Security
This architecture forces us to confront uncomfortable questions:
- If we can bind deployments to hardware tokens, why don’t we?
- If certificates can be valid for 10 minutes, why are we issuing them for 90 days?
- If we can cryptographically prove exactly what was deployed, why do we settle for proving who deployed it?
The most powerful aspect of this implementation isn’t any single technical component—it’s the holistic rethinking of what “secure deployment” means. It moves us from “securing the pipeline” to “making the pipeline irrelevant without hardware proof.”
The question we should be asking: If an attacker gained full access to your CI/CD pipeline tomorrow, could they deploy unauthorized infrastructure? In most organizations, the answer is yes. In this architecture, the answer is mathematically no.
Ready to See It in Action?
This isn’t a thought experiment or a research paper. It’s proof-of-concept-ready code, fully documented, with clear success criteria and implementation steps. If you’re serious about zero-trust infrastructure, hardware-bound deployments, and ephemeral credential architectures, exploring this repository will change how you think about security.
Explore the implementation: Immutable-Plan-Enforcer on GitHub
The code is there. The patterns are there. The only question is: are you ready to rethink how deployment security should work?