README.md

Config file with embedded secrets

Kubernetes Secrets are very flexible and can be consumed in many ways. Secret values can be passed to containers as environment variables or appear as regular files when mouting secret volumes.

Often users end up using the latter method just to wrap full configuration files into k8s secrets, just because one or more fields in the config file happen to be secrets (e.g. a database password, or a session cookie encryption key).

Ideally you should avoid configuring your software that way and instead splitting your configuration from your secrets somehow. Also make sure you know about 12 Factor.

That said, there are circumstances where you just have to provide such a file to your application (perhaps because it's a legacy app) and encrypting the whole configuration file in a single SealedSecrets item is problematic:

• You cannot easily update individual secret values (e.g. rotate your DB password), without first decrypting the whole configuration file.
• Since the whole configuration file is encrypted, it's hard to view, change (and review) non-secret parts of the config.

This example shows a possible approach to split the non-secret part of the config into a ConfigMap, and rely on a simple "Init Container" to merge the actual secret values back into it.

The example here includes an example Secret resource, which since you're reading this as part of the sealed-secrets documentation, you'd probably pass through kubeseal before checking it in; that said this approach is not limited to sealed-secrets.

configmap.yaml

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: example
data:
  myconfig.json.tmpl: |
    {
           "Server": [{
                           "host": "foobar",
                           "ip": "10.10.10.12",
                           "port": "22",
                           "env": "SOME_ENV",
                           "user": "myuser",
                           "password": "{{ (ds "secrets").server1 }}",
                           "role": "foo"
                   },{
                           "host": "barfoo",
                           "ip": "10.10.10.11",
                           "port": "22",
                           "env": "SOME_OTHER_STUFF",
                           "user": "otheruser",
                           "password": "{{ (ds "secrets").server2 }}",
                           "role": "foo"
                   }
           ],
           "Database": [{
                           "host": "somedb",
                           "ip": "10.10.10.10",
                           "port": "1521",
                           "sid": "FOO",
                           "env": "BAZ",
                           "user": "abcdefg123",
                           "password": "{{ (ds "secrets").database1 }}",
                           "role": "foo"
                   }
           ]
    }

deployment.yaml

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example
spec:
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      initContainers:
      - name: inject-secrets
        image: hairyhenderson/gomplate:alpine
        volumeMounts:
        # The /secrets directory will contain one file per sercret item.
        # The secret item's key will become the file name, while its value goes in the file contents.
        - name: config-secrets-volume
          mountPath: /secrets
        # The config map containing the config file template will be available here.
        - name: config-template-volume
          mountPath: /input
        # While the expanded template will be put in a volume shared with the application which will run
        # in the main container when this init container is done.
        - name: config-volume
          mountPath: /output
        # Now we can actually run the template expander and inject secrets into the template.
        command: ["sh", "-c"]
        args:
        - gomplate -d secrets=/secrets/ </input/myconfig.json.tmpl >/output/myconfig.json
      containers:
      # This is an example application that assumes a complex configuration file in /config/myconfig.json.
      # The JSON format here is just an example; any textual file format would work.
      - name: app
        image: bitnami/minideb:buster
        volumeMounts:
        - name: config-volume
          mountPath: /config
        command: ["sh", "-c"]
        args:
        - |
         echo Your app will get this config file:
         cat /config/myconfig.json
         # dummy application
         sleep 100000h
      volumes:
      - name: config-volume
        emptyDir: {}
      - name: config-template-volume
        configMap:
          name: example
      - name: config-secrets-volume
        secret:
          secretName: example

secret.yaml

---
apiVersion: v1
kind: Secret
metadata:
  name: example
stringData:
  server1: foo
  server2: bar
  database1: baz