Extend EnvVar with ValueFrom for Secret and ConfigMap references

[ChrisJBurns]

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.EnvVar supports all of these via its ValueFrom field (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 test

Notes

• The JSON serialization of corev1.EnvVar is a superset of the custom type — existing manifests with just name/value continue to work.
• The valueFrom field is optional, so this is backwards-compatible for existing users.
• This is a v1alpha1 API so the schema change is acceptable.

Generated with Claude Code

[anveshthakur]

hey I would like to work on it

[ChrisJBurns]

@anveshthakur Go for it!

[anveshthakur]

hey raised a PR let me know if anything else is required over here.
Thanks!

[Sanskarzz]

@ChrisJBurns, please assign me this issue.

[ChrisJBurns]

@Sanskarzz I think this will be a breaking change to the env var functionality, so we probably want to leave this until we go to v1beta2