Deployment trust and the runtime boundary — what happens when an artifact reaches production

The runtime boundary is the sixth trust boundary and the last gate before production. The five previous boundaries — source, dependency, build, artifact, deployment — have all been about producing and delivering an artifact. The runtime boundary is about the artifact’s first moment in production: the moment the process starts, the moment the syscall is made, the moment the secret is read. The deployer identity, admission control, and signed deploy manifests are the controls. The deployment does not end when the artifact starts; it ends when the artifact is verified at the runtime boundary.

The runtime boundary

The runtime boundary is the boundary between the artifact and the running system. The boundary is enforced by:

• The deployer identity. The cloud IAM role or the Kubernetes service account that performs the deploy. The identity is what the cluster’s audit log records; the identity is what the regulator asks about.
• Admission control. The validation that runs when the artifact is submitted to the cluster. The validator checks the signature, the provenance, the policy, and the SBOM. The artifact is rejected if the validator fails.
• Signed deploy manifests. The manifest that names the artifact (by digest) and the policy that applies to it. The manifest is signed by the deployer identity; the signature is what binds the manifest to the deployer.
• Runtime policy. The policy that governs what the artifact can do once running: which syscalls, which network egress, which secrets. The policy is the last line of defence.

flowchart LR
    A["Deploy manifest"] --> B["Signed by deployer"]
    B --> C["Admission controller"]
    C --> D["Verify signature"]
    C --> E["Verify provenance"]
    C --> F["Verify policy"]
    D --> G["Allow"]
    E --> G
    F --> G
    G --> H["Artifact runs"]
    H --> I["Runtime policy"]
    I --> J["Syscall / network / secret"]
    I --> K["Audit log"]

The diagram shows the runtime boundary. The deploy manifest arrives at the cluster; the admission controller verifies the signature, the provenance, and the policy; the artifact is allowed to run if all three checks pass; once running, the runtime policy governs what the artifact can do, and the audit log records everything.

This is the boundary most often left unverified. Teams verify the source and the build, sign the artifact, and then deploy without verifying what arrives at the cluster. The audit log records the artifact that ran, but the audit cannot answer “was the artifact that ran the artifact that was signed?”.

slsa-verifier and the runtime check

The slsa-verifier tool verifies a SLSA provenance attestation against the artifact and the expected builder. The verifier checks the signature, the source repository, the build platform, and the policy. The deployment pipeline runs the verifier before allowing the artifact to run.

slsa-verifier verify-image \
  --source github.com/example/app \
  --builder-id https://github.com/actions/runner \
  registry.example.com/app@sha256:$DIGEST

The command verifies the artifact against the expected source repository and the expected build platform. The verifier fetches the attestation from the registry, checks the signature, checks the source URI, checks the builder URI, and exits zero if all three match. The deployment script chains the check and fails if the exit code is non-zero.

The verifier is the operational primitive of the runtime boundary. The verifier is what runs in the admission controller; the verifier is what the deployment pipeline calls; the verifier is what the audit log records. The verifier is the gate.

Admission control and policy

The runtime boundary is enforced by an admission controller (the Kubernetes validating admission policy, the Sigstore Policy Controller, an OPA Gatekeeper constraint, or a Kyverno policy). The admission controller runs before the artifact is admitted to the cluster. The controller can:

• Verify the signature. The controller checks the signature against the trusted publisher identity. The artifact is rejected if the signature is invalid.
• Verify the provenance. The controller checks the provenance attestation against the expected source and builder. The artifact is rejected if the provenance does not match.
• Verify the policy. The controller checks the SBOM and the build metadata against the policy: no disallowed dependencies, no disallowed licenses, no disallowed vulnerabilities above a threshold. The artifact is rejected if the policy fails.
• Record the audit log. The controller records the digest, the verification result, and the deployer identity in the audit log. The audit answers “what was deployed, by whom, under what signature”.

The four checks are the production discipline. A controller that verifies only the signature has closed the artifact boundary but not the source or the policy. A controller that verifies the signature and the provenance but not the policy has closed the source boundary but not the dependency boundary. The chain is the four together.

Production discipline

1. Verify the provenance at the runtime boundary. The deployment calls slsa-verifier before submitting the artifact to the cluster. The deployment fails if verification fails.
2. Enforce admission control in the cluster. The admission controller runs the same verifications the deployment pipeline ran. The cluster rejects the artifact if the controller fails.
3. Sign the deploy manifest. The manifest is signed by the deployer identity. The signature binds the manifest to the deployer.
4. Record the audit log. The audit log records the digest, the verification result, and the deployer identity at every step. The audit answers “what ran, by whom, under what signature, against what policy”.
5. Treat the runtime boundary as a chain, not a single check. The checks are independent. The signature checks the bytes; the provenance checks the build; the policy checks the dependencies; the audit log records the verification. A check that is skipped is a chain that is broken.

Cross-course references

• Git, CI/CD & GitOps — Part LXV-01 (Trust Boundaries) maps the runtime boundary this lesson covers.
• Git, CI/CD & GitOps — Part XLV-06 (Provenance) covers the attestation the runtime boundary verifies.
• Git, CI/CD & GitOps — Part LII-04 (Policy Conftest) covers the policy-as-code model the admission controller enforces.
• Kubernetes for Production Sysadmins — Part XIX (Admission Control) covers the Kubernetes primitive in detail.

Quiz