Skip to content

Extend EnvVar with ValueFrom for Secret and ConfigMap references #4547

@ChrisJBurns

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions