Secrets and Configuration Management
wasmCloud components receive configuration through the localResources.environment field in a Workload or WorkloadDeployment manifest. This field supports three sources that can be used individually or combined: inline key-value pairs, Kubernetes ConfigMaps, and Kubernetes Secrets.
In this section of the Operator Manual, you'll learn how to:
- Supply inline configuration to a component
- Reference ConfigMaps and Secrets from a workload manifest
- Combine multiple configuration sources
Inline configuration
All values supplied through localResources.environment — regardless of source — are delivered to the component as POSIX-style environment variables via the wasi:cli/environment interface. Components read them the same way they would read any environment variable in their language of choice.
The simplest approach is to supply key-value pairs directly in the manifest under localResources.environment.config:
components:
- name: http-component
image: ghcr.io/wasmcloud/components/http-hello-world-rust:0.1.0
localResources:
environment:
config:
LOG_LEVEL: info
REGION: us-east-1Inline values are suitable for non-sensitive configuration that is safe to store in version control.
ConfigMaps
To supply configuration from a Kubernetes ConfigMap, reference it by name under configFrom:
components:
- name: http-component
image: ghcr.io/wasmcloud/components/http-hello-world-rust:0.1.0
localResources:
environment:
configFrom:
- name: app-configEach key-value pair in the referenced ConfigMap is delivered to the component as an environment variable. Multiple ConfigMaps may be listed; if the same key appears in more than one, the last entry in the list takes precedence.
Secrets
To supply sensitive values from a Kubernetes Secret, reference it by name under secretFrom:
components:
- name: http-component
image: ghcr.io/wasmcloud/components/http-hello-world-rust:0.1.0
localResources:
environment:
secretFrom:
- name: db-credentialsSecret values are delivered to the component as plain strings — no decoding is required in your component code. Multiple Secrets may be listed, and the last entry wins on key conflicts.
The secretFrom field only accepts Secret names; values are never embedded in the manifest. Use Kubernetes RBAC to restrict which service accounts and users can read the referenced Secret resources.
Combining sources
All three sources can be combined in a single component definition. When the same key appears in multiple sources, the order of precedence (lowest to highest) is: config → configFrom → secretFrom.
components:
- name: http-component
image: ghcr.io/wasmcloud/components/http-hello-world-rust:0.1.0
localResources:
environment:
config:
LOG_LEVEL: debug
configFrom:
- name: app-config
secretFrom:
- name: db-credentialsAll keys from app-config and db-credentials are merged with the inline values. Note that precedence is determined by source type, not by the order fields appear in the YAML: secretFrom always wins over configFrom, which always wins over config.
Complete example
A WorkloadDeployment using all three configuration sources:
apiVersion: runtime.wasmcloud.dev/v1alpha1
kind: WorkloadDeployment
metadata:
name: my-app
namespace: default
spec:
replicas: 2
template:
spec:
hostSelector:
hostgroup: default
components:
- name: http-component
image: ghcr.io/wasmcloud/components/http-hello-world-rust:0.1.0
localResources:
environment:
config:
LOG_LEVEL: info # inline values (lowest precedence)
configFrom:
- name: app-config # non-sensitive config from a ConfigMap
secretFrom:
- name: db-credentials # sensitive values from a Secret (highest precedence)
hostInterfaces:
- namespace: wasi
package: http
interfaces:
- incoming-handler
config:
address: '0.0.0.0:8080'Related documentation
- Custom Resource Definitions — field reference for
localResources,hostInterfaces(including backend config andallowedHosts), and other CRD fields - Roles and Role Bindings — RBAC configuration for the operator and host pods
- Filesystems and Volumes — mounting volume data into components via
localResources.volumeMounts - Private Registries — managing image pull secrets for private OCI registries