Application, container, and Helm fields

The application is a small FastAPI HTTP service. Its simplicity makes the artifact and admission path easier to inspect; it does not remove the security risks of the container, dependencies, CI authority, or Kubernetes environment around it.

HTTP behavior

Route	Response purpose	Trust limit
/	Static service/status response	Reachability observation only
/health	Static healthy/service response	Does not check registry, verifier, or external dependencies
/info	Build commit environment value, image-digest environment value, and signed field	signed: true is hardcoded, not a runtime verification result

GIT_SHA is a Docker build argument promoted into environment and OCI revision label. IMAGE_DIGEST is read from the runtime environment with fallback unknown. The Helm template does not inject it, so /info does not independently establish the running digest. Read the Deployment/Pod image reference and correlate it with verified metadata instead. The comment attributing signed: true to admission is an application assertion that can be false outside policy scope.

The top-level requirements pin FastAPI, Starlette, Uvicorn, and Pydantic versions. They do not pin every transitive package with hashes. The provenance source revision helps identify the requirement file used; it does not make dependency resolution hermetic.

Container build and runtime

The Dockerfile uses python:3.12-slim-trixie for both stages. The builder installs gcc, creates /opt/venv, installs dependencies, then removes pip and setuptools from that copied virtual environment. The final stage applies available Debian updates, copies application and venv, creates numeric UID/GID 10001, and runs Uvicorn on port 8000 as that user.

This removes the builder’s compiler installation from the copied application environment, but the runtime remains a Debian-based image with ordinary packages and a shell. The controlled shell detection itself demonstrates that /bin/sh exists. Avoid calling this shell-free or claiming every package manager was removed from every location in the base image.

Both FROM instructions use a mutable tag; apt update/upgrade, pip upgrade, and transitive resolution are time-dependent inputs. A digest-pinned deployment makes the selected built artifact stable after build; it does not make a future rebuild reproducible. Final-image Trivy scans the actual pushed digest to address that built artifact.

Helm desired state

Field	Baseline behavior
image.repository + image.digest	Renders repository@sha256:…, with no mutable runtime tag
replicaCount	2
Pod security context	Non-root, UID/GID 10001, RuntimeDefault seccomp
Container security context	No privilege escalation, read-only root filesystem, all Linux capabilities dropped
Resource requests	50m CPU, 64 MiB memory
Resource limits	200m CPU, 128 MiB memory
Service	ClusterIP port 80 → application port 8000
Readiness/liveness	TCP port probes, not HTTP /health checks

The Docker HEALTHCHECK uses an HTTP request to /health; Kubernetes uses the chart’s TCP probes. Those are different health tests. A successful TCP probe demonstrates a listening port rather than the application response body. Hardening contains some execution paths, but does not prove application logic or dependency safety.

Desired state and source separation

The active Argo Application references k8s/helm/supply-chain-demo; standalone deployment/service manifests under k8s/manifests/ are not its desired-state source. The Helm values’ selected digest can differ from the newest verified CI digest because promotion is manual. Record both before diagnosing an apparent mismatch.

Automated prune and self-heal restore committed desired state. They do not approve its trust claims; Kyverno makes that scoped admission decision. The immutable digest joins the artifact view to the deployment view while the signer and repository permissions remain separate authority questions.

Source anchors

Application routes, requirements, Dockerfile, Helm values, and Deployment template.