LLMModel create/edit grants arbitrary container execution with Secret access

Reported as H-04 in the PR #117 security assessment; follow-up to #116.

What

The operator runs whatever image and command an LLMModel names, verbatim:

• operator/internal/controller/reconcilers/modelservice.go:184-185 takes the serving container image from model.Spec.Serving.Image when set.
• operator/internal/controller/reconcilers/modelservice.go:206-207 takes the container command from model.Spec.Serving.Command when set.

So anyone with RBAC to create or edit LLMModel CRs in the operator namespace controls the image and command the operator schedules there, and that pod can read the Secrets the operator mounts into serving pods (provider credentials, the model's api-keys Secret, the HF token). The serving-command override added in PR #117 makes this explicit: the CR author, not the operator, decides what runs.

Why it matters

LLMModel reads as a model-configuration resource, so delegating edit access to it (for example, to a data-science team) also delegates code execution and credential access in the operator namespace. Nothing today restricts the image or command, or blocks Secret mounting for user-supplied workloads.

Options

• Restrict serving.image / serving.command to a maintainer-configured allowlist via the validating webhook, or gate them behind a separate privileged role.
• Document that LLMModel edit access should be treated as cluster-admin-equivalent.
• Scope which Secrets a serving pod can mount so a user-chosen image cannot read credentials it should not.

Not a regression from PR #117; filed so it is tracked separately from #116.

Start with operator/internal/controller/reconcilers/modelservice.go:184-207 and review PR #117 alongside the security assessment. Determine which mitigation direction is accepted for image and command overrides and Secret access; done means the chosen policy is implemented and its security behavior is verified.