Security finds unsigned model-serving containers being pulled into the city’s Kubernetes cluster. What supply-chain control should architecture require?
Select an answer to reveal the explanation.
Short Explanation
You want serving images you can trust before they reach the cluster, not mystery boxes on the loading dock. Require signed images from trusted registries and deploy-time verification; runtime monitoring cannot replace that gate.
Full Explanation
Model-serving containers are part of the GenAI application supply chain, so you should verify their integrity before admitting them to the city’s Kubernetes cluster. Requiring signed, verified serving images from trusted registries, with deploy-time policy enforcement, helps prevent tampered, substituted, or casually rebuilt images from running against municipal workloads and resident data. Preferring the newest unsigned tag named latest for agility sacrifices reproducibility and integrity: tags can drift or be substituted by anyone able to push them. Allowing unsigned images from approved registries during outages is also unsafe; runtime monitoring may detect suspicious behavior after a compromised container has already entered the cluster, but it does not establish image provenance or prevent execution. Building serving images on developer laptops without reproducible builds weakens provenance and can produce inconsistent, unauditable artifacts. Exam caveat: signing alone is incomplete if admission policy does not verify signatures and enforce the requirement at deploy time. Practical check: configure trusted-registry allowlists and image-signature verification in the cluster, deny unsigned GenAI serving images—including unsigned latest tags—and ensure builds use reproducible processes with recorded digests.