Product

Solutions

Resources

Pricing

Consuming Secrets Anywhere

SecretsIntegrationsKubernetes

Because a Planton-managed secret lives provider-native in your own store under a stable, readable name, anything that can read your store can consume it — with or without Planton in the path. The platform makes this concrete: every secret offers a catalog of ready-to-paste integration snippets, computed on the server from the secret's real remote identity and its backend's actual coordinates, so every surface hands you the same correct text.

Find them on the secret's detail page (Use This Secret), on the creation success screen, from the CLI, or through agent tools:

# The full catalog, grouped
planton secret snippet db-password

# One target, pipe-safe
planton secret snippet db-password --target eso -o plain > external-secret.yaml

Through Planton

  • Planton manifest reference — the $secret/... reference for service and infrastructure manifests, resolved just-in-time on the Runner at deployment.
  • Connection field reference — the typed reference for connection credential fields (organization-scoped secrets).
  • CLI one-linerplanton secret get <slug> -o plain for scripts and local shells.

Straight From Your Store

These read your store directly — no Planton dependency at runtime:

  • External Secrets Operator — a SecretStore + ExternalSecret pair for your provider. Key-value secrets extract every key automatically (the payoff of canonical JSON storage); text secrets map the single value.
  • Kubernetes CSI Secrets Store — the provider class and object definition for mounting the secret into pods.
  • Cloud Run — the --update-secrets binding for the secret's real GCP name.
  • ECS — the task-definition valueFrom entry (with an honest note about cross-account ARN forms).
  • Provider CLI — the exact gcloud / aws / az / vault read command for the secret's real name.

Snippets are honest by construction: provider-native targets appear only for stores your own tools can reach (never for a local instance's built-in store), and <key> placeholders appear exactly where a key name cannot be known without reading the value — which snippet rendering never does. Snippets render even when the backend's credentials are broken, because rendering never contacts the provider.

Next article

Variables

Variables in Planton store non-sensitive configuration — database hostnames, API endpoints, feature flags, region names, port numbers, or any value that services and infrastructure deployments need at runtime but that does not require encryption. For sensitive values, use Secrets. If you have used GitHub Repository Variables, GitLab CI/CD Variables (unprotected), or Kubernetes ConfigMaps, the model is familiar. Planton adds organization-wide and environment-specific scoping, dynamic references...
Read next article