-
Notifications
You must be signed in to change notification settings - Fork 201
Extend EnvVar with ValueFrom for Secret and ConfigMap references #4547
Description
Summary
The operator defines a custom EnvVar type with only Name and Value (literal strings). It is missing the ValueFrom field that corev1.EnvVar provides, so users cannot reference Secrets, ConfigMaps, or pod field refs in environment variables. This forces sensitive data to be stored in plaintext in the MCPServer manifest.
Current custom type (cmd/thv-operator/api/v1alpha1/mcpserver_types.go, lines ~370-379)
type EnvVar struct {
// Name of the environment variable
// +kubebuilder:validation:Required
Name string `json:"name"`
// Value of the environment variable
// +kubebuilder:validation:Required
Value string `json:"value"`
}Fields using the custom type
| Struct | File | Line | Context |
|---|---|---|---|
| MCPServerContainerSpec | mcpserver_types.go |
~196 | MCP server container env vars |
| MCPRemoteProxyRunnerSpec | mcpserver_types.go |
~351 | Proxy runner container env vars |
Why this matters
- No way to reference Kubernetes Secrets — forces API keys, tokens, passwords into plaintext manifests
- No way to reference ConfigMap values for dynamic configuration
- No access to pod field refs (
status.podIP,metadata.name) needed for service discovery and telemetry corev1.EnvVarsupports all of these via itsValueFromfield (SecretKeyRef,ConfigMapKeyRef,FieldRef,ResourceFieldRef)
What to change
1. Replace type definition (cmd/thv-operator/api/v1alpha1/mcpserver_types.go)
Delete the custom EnvVar type definition (lines ~370-379). Replace the Env field type in both structs with corev1.EnvVar:
// Before
Env []EnvVar `json:"env,omitempty"`
// After
Env []corev1.EnvVar `json:"env,omitempty"`The file already imports corev1 for other types.
Note: the custom type marks Value as +kubebuilder:validation:Required. In corev1.EnvVar, Value and ValueFrom are both optional (one or the other is set). Dropping this validation is correct — it's what enables the ValueFrom path.
2. Update controller code
Search cmd/thv-operator/controllers/ for where EnvVar fields are read and converted to corev1.EnvVar for pod specs. The controller likely has conversion logic that can be simplified or removed since the types now match directly.
Also search cmd/thv-operator/pkg/ for any helper functions that convert the custom EnvVar type.
3. Update tests
Test files constructing EnvVar{Name: "FOO", Value: "bar"} need updating to corev1.EnvVar{Name: "FOO", Value: "bar"}. The struct field names are the same so this may just be a type prefix change.
4. Regenerate and verify
task gen
task crdref-gen
task lint-fix
task lint
task testNotes
- The JSON serialization of
corev1.EnvVaris a superset of the custom type — existing manifests with justname/valuecontinue to work. - The
valueFromfield is optional, so this is backwards-compatible for existing users. - This is a
v1alpha1API so the schema change is acceptable.
Generated with Claude Code