Secrets

Infra supports many secret storage backends, including, but not limited to:

  • Kubernetes
  • Vault
  • AWS Secrets Manager
  • AWS SSM (Systems Manager Parameter Store)
  • Environment variables
  • Files on the file system
  • plaintext secrets (though not recommended)

Usage

These can be referenced in the Infra config file using the scheme <secret-backend>:<secret-key>

Examples follow.

Kubernetes

    clientSecret: kubernetes:infra-okta/clientSecret

This would read the infra-okta/clientSecret key from a Kubernetes secret.

Kubernetes takes configuration, like so:

secrets:
  - name: kubernetes # can optionally provide a custom name
    kind: kubernetes
    config:
      namespace: mynamespace

namespace defaults to whatever is defined in /var/run/secrets/kubernetes.io/serviceaccount/namespace, or the default namespace.

Vault

    clientSecret: vault:infra-okta-clientSecret

This would read the infra-okta-clientSecret secret from Vault

Vault takes configuration, like so:

secrets:
  - name: vault # can optionally provide a custom name
    kind: vault
    config:
      transitMount: /transit
      secretMount: /secret
      token: env:VAULT_TOKEN # secret config can even reference other built-in secret types, like env
      namespace: mynamespace
      address: https://vault

AWS Secrets Manager

    clientSecret: awssm:infra-okta-clientSecret

Secrets Manager takes configuration, like so:

secrets:
  - name: awssm # can optionally provide a custom name
    kind: awssecretsmanager
    config:
      endpoint: https://kms.endpoint
      region: us-west-2
      accessKeyID: env:AWS_ACCESS_KEY_ID # secret config can even reference other built-in secret types, like env
      secretAccessKey: env:AWS_SECRET_ACCESS_KEY

AWS SSM (Systems Manager Parameter Store)

    clientSecret: awsssm:infra-okta-clientSecret

SSM takes configuration, like so:

secrets:
  - name: awsssm # can optionally provide a custom name
    kind: awsssm
    config:
      keyID: 1234abcd-12ab-34cd-56ef-1234567890ab # optional, if set it's the KMS key that should be used for decryption
      endpoint: https://kms.endpoint
      region: us-west-2
      accessKeyID: env:AWS_ACCESS_KEY_ID # secret config can even reference other built-in secret types, like env
      secretAccessKey: env:AWS_SECRET_ACCESS_KEY

Environment variables

    clientSecret: env:OKTA_CLIENT_SECRET

env is built-in and does not need to be declared, but if you do want to declare the configuration for it, you could use this to create a custom env handler which base64 encodes the secret:

secrets:
  - name: base64env
    kind: env
    config:
      base64: true
      base64UrlEncoded: false
      base64Raw: false

which you would then use like this. First define an environment variable in the context where it will be accessed. There are many ways to do this in Kubernetes. Typically the environment variable in Kubernetes will be defined in the deployment. To temporarily define an environment variable you can use kubectl:

$ kubectl set env deployment/infra OKTA_CLIENT_SECRET=c3VwZXIgc2VjcmV0IQ==
# you will need to restart any running pods for this to be applied

Then use the name of the secret back-end and the name of the environment variable in the infra.yaml file:

    clientSecret: base64env:OKTA_CLIENT_SECRET

Files on the file system

It's a common pattern to write secrets to a set of files on disk and then have an app read them. Note that one secret is stored per file in plaintext.

    clientSecret: file:/var/secrets/okta-client-secret.txt

file is built-in and does not need to be declared, but if you do want to declare the configuration for it, you could use this to create a custom handler, like so:

secrets:
  - name: base64file
    kind: file
    config:
      base64: true
      base64UrlEncoded: false
      base64Raw: false
      path: /var/secrets # optional: assume all files mentioned are in this root directory

which you would then use as follows. First base64 encode a string and write it to a file:

$ echo "c3VwZXIgc2VjcmV0IQ==" > /var/secrets/okta-client-secret.txt

Then in the infra.yaml file, use the name of the secrets config declaration and then the name of the file.

    clientSecret: base64file:okta-client-secret.txt

Sometimes it can be handy to support plain text secrets right in the yaml config, especially when the yaml is being generated and the secrets are coming from elsewhere.

    clientSecret: plaintext:mySupErSecrEt

Optionally for plaintext secrets, you can leave off the secret back-end name:

    clientSecret: mySupErSecrEt

plaintext is built-in and does not need to be declared, but if you do want to declare the configuration for it so that you can include base64 encoded strings, you could use this to create a custom handler:

secrets:
  - name: base64text
    kind: plain
    config:
      base64: true
      base64UrlEncoded: false
      base64Raw: false

Which you would then use in the infra.yaml file as shown:

    clientSecret: base64text:bXlTdXBFclNlY3JFdA==

Sign up for product & API updates

You can unsubscribe at any time.