I build things, then try to
break them.

You write a small WebApp resource: an image, a port, how many replicas. The controller reconciles it into a Deployment, a Service, a HorizontalPodAutoscaler and a PodDisruptionBudget, then keeps them matching the spec forever. Edit a child by hand and the next reconcile puts it back.

The interesting part is the parts that refuse. An admission webhook rejects :latest and untagged images, because an operator that forbids mutable tags for its operands should hold itself to the same rule. Status conditions report what is actually true, including Available=False when the image does not exist. Two API versions are served through a conversion webhook that completes inconsistent stored data instead of rejecting it.

Admission control that ties a Kubernetes workload to the build that produced it. Not this image is signed, but this image was built by the workflow that belongs to this service, checked against a trust root the workload itself cannot write. The demo runs three admissions against images the repository really publishes: its own build is admitted, an unsigned image is refused, and an image built by a different workflow of the same trusted builder is refused as well. The third one is the whole point, because it is not a forgery.

The project began from a claim that turned out to be false, and correcting it is more interesting than the claim was. I argued that Kyverno could not express a per-resource provenance check, then tested it against Kyverno 1.19 before writing a line of the webhook. It can, in nine lines of CEL. So the boundary moved: Kyverno stays the enforcement engine and nothing here reimplements it, but it can only read a trust root, not create one, keep it in step, or control who writes it. That registry is what this builds, with RBAC bound to the platform's ServiceAccount and to nobody else. The design record saying the earlier one was wrong is kept next to it, unedited.

My final degree project at EPSEVG · UPC, built with the environmental association Alytes for outreach and education. It is a whole platform rather than a model: dataset preparation, two-stage YOLO12 training, a GPU-aware FastAPI inference service, asynchronous video jobs, and an RTMP→HLS pipeline that draws boxes on a live stream.

Four modes share one backend: image upload, async video analysis, the browser webcam, and published RTMP cameras. Video jobs are content-addressed (SHA-256(file : conf : stride)), so re-uploading the same clip returns instantly, even for a different user, and any job still queued survives a backend restart. Every stage is bounded: worker pools, semaphores, a sliding-window rate limiter and hard timeouts on both inference and FFmpeg.