v0.1.6 · Interface

secret-source

Optionally exported by a host component plugin that holds secrets the operator wants to feed into plugins' bindings, including the wasmcloud:secrets bindings workloads read their own secrets through. The host calls it, never a workload, so it is separate from any workload-facing secrets interface the plugin also serves.

An operator names a plugin-backed entry in the host's secrets: catalog, grants it to the workloads that may use it, and lists it under a host.plugins entry's or binding's secretFrom. Each time a granted workload binds a binding that names the entry, the host calls resolve once with the entry's keys and hands the values to the consuming plugin as config. A rotated value reaches the next bind.

Every request names the workload whose bind needs the values, so one entry serves each workload its own secret: the source chooses the backend path from request.workload, and a value reaches only the workload it was resolved for. This is how a workload's own secrets reach it, through the wasmcloud-secrets entry, with nothing per workload in the host's config:

secrets:
  workload-secrets:
    plugin: vault-secrets
    keys:
      db-password: db-password   # config key: key passed to `resolve`
    workloads: all               # the source scopes each answer by workload
host:
  plugins:
    - id: wasmcloud-secrets
      secretFrom: [workload-secrets]

The same shape on a named binding of a native plugin gives each workload its own credential to that plugin's backend, such as its own postgres role. A credential every user of a binding shares is instead granted to the workloads that may use it:

secrets:
  reports-db:
    plugin: vault-secrets
    keys:
      url: platform/postgres/reports-url
    workloads:
      - namespace: billing
        name: reports            # a WorkloadDeployment's name under the operator

For a workload outside the grant, resolve is not called and the bind fails, with one exception: an entry named by the host.plugins entry itself, on a plugin whose keys each stand alone (wasmcloud-secrets), is withheld. A withheld key is left out of the workload's config and still counts as set, so no default the host would otherwise supply takes its place. A source sees only requests the operator granted, and may refuse more.

A grant trusts the namespace and name the host was given with the workload. The Kubernetes operator takes them from the Workload and its owners, so a replica cannot claim another deployment's name; whoever may create a Workload in a namespace may still give it any name, so the namespace is the boundary and a name narrows a grant within it. On a standalone host, whoever can send it a start request chooses both.

A plain import routes to whichever registered plugin serves it, and a grant is checked only on the plugin whose entry declares the secret. So while an entry-level secret feeds a plugin, the host refuses to start if another plugin serves the same interface: a source on such a host exports secret-source, not wasmcloud:secrets itself.

The request says whom the values are for: the consuming binding and the workload whose bind needs them. Both come from the host's own records, never from anything a workload sends.

Theme