Inject Secrets from Parameter Store

The ssm dependency engine pulls parameters and secrets from your cloud
provider into a Kubernetes secret in your application's namespace. If you have
not created the secret yet, create it first in Secrets Manager in SVIEW
rather than by hand — it places the value at the right path and can generate
this configuration for you. See Secrets Manager.

Where the parameter has to live

The parameter name in the cloud provider must follow this format, matching your
application's stage, environment, namespace, and instance:

/<stage>/<tenant>/<namespace>/application-secrets-<instance>

For example, a SecureString parameter named
/dev/<your-environment>/payments/application-secrets-gw holding:

{
  "EMAIL_HOST_PASSWORD": "...",
  "SOME_SECRET_KEY": "..."
}

is read by this application configuration:

dependency:
  ssm:
    followKeysFormat: true
    instance: gw
    namespace: payments
    json: "false"
    keys:
      - EMAIL_HOST_PASSWORD
      - SOME_SECRET_KEY

Configuration reference

Key	Default	Description
`keys`	`[]`	Parameters to fetch. With `json: "true"` the keys are looked up inside one JSON secret; with `"false"` each key is a separate parameter
`keys[].name`	—	When an entry is written as an object: the environment variable name your application reads
`keys[].ssmKeys`	—	When an entry is written as an object: the parameter or parameters to fetch for that entry
`followKeysFormat`	`false`	When `false`, every key in the resulting secret is uppercased
`instance`	application name	Read another instance's parameters
`namespace`	application namespace	Read another namespace's parameters
`secretName`	auto-generated	Name of the created Kubernetes secret — rarely needs setting
`sOverride`	—	Set to `secretsmanager` to read from AWS Secrets Manager instead of Parameter Store
`json`	`"false"`	Set to `"true"` when one parameter holds a JSON object and you want to pull individual keys out of it, `"false"` when each key is its own parameter

Each entry under keys can be a plain key name, as in the example above, or an
object with its own ssmKeys and overrides, as in the worked example below.

Worked example — your own secrets plus one shared value

A common case is an application that has its own secrets but also needs a value
that several teams share. Keep the shared value in its own parameter and
override the location for just that key:

dependency:
  ssm:
    keys:
      - EMAIL_HOST_PASSWORD
      - ssmKeys:
          - SHARED_API_KEY
        namespace: "shared"
        instance: "common"
        sOverride: secretsmanager
        json: "true"

The first entry is read from the application's own parameter using the defaults.
The second is read from a JSON secret in AWS Secrets Manager belonging to the
shared namespace and the common instance. Each override applies only to the
entry it sits under, so you do not have to move your own secrets to match.

Application Dependencies — all dependency engines, and how to choose
Dependency Configuration Examples — a minimal starter snippet
Attach a Database to Your Application
Secrets Manager
Secret Not Found or Not Reaching Your Application
IAM Service Accounts
Kafka Access, ACLs and Topics

Where the parameter has to live

Configuration reference

Worked example — your own secrets plus one shared value

Related articles