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.
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-185takes the serving container image frommodel.Spec.Serving.Imagewhen set.operator/internal/controller/reconcilers/modelservice.go:206-207takes the container command frommodel.Spec.Serving.Commandwhen 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
serving.image/serving.commandto a maintainer-configured allowlist via the validating webhook, or gate them behind a separate privileged role.Not a regression from PR #117; filed so it is tracked separately from #116.