Schedule a chat

Hosted Secrets Management for Kubernetes

Apr 23, 2018

Managing secrets in Kubernetes is currently somewhat of a challenge. Kubernetes users have the Secret resource which works well to define secrets in the cluster, but where should secrets reside before they’re added to the cluster?

One all-too-common pattern is to encrypt secrets and store them in a git repository for versioning and long-term storage. While this works, and one can argue that a git respository is nothing more than versioned abstract storage, the problem with this approach is not with git itself (or any other DVCS) but with the general use-case of DVCS’. Because version control systems like git encourage sharing and collaborating on content, using that same medium for confidential data is a poor practice. Besides, a good many developers expect to not encounter confidential data in DVCS repositories and thus wouldn’t think twice about cloning or sharing repository data with their peers

But we encrypt the data!

Encrypting confidential data inside a git repository can keep that data relatively safe, but current and future cryptographic vulnerabilities might counter that. Having a multitude of cloned repositories containing the complete history of ciphertext for a given chunk of confidential data is worrisome. Proper cryptogrpahic key rotation can fight against this, but in practice this doesn’t always happen.

Meet Environr

Environr is a product that centralizes the management of configuration data and secrets and fits into the Kubernetes workflow very well. A recent addition to Environr’s CLI has made it even easier to work with YAML and create the necessary secrets at deployment time.

Consider the following common scenario with Helm:

Let’s start with a simple secret and deployment.

apiVersion: v1
kind: Secret
metadata:
  name: postgres-secrets
data:
  password: {{ Values.secrets.postgres_password | b64enc }}
type: Opaque
---

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  template:
    metadata:
      labels:
        name: myapp 
    spec:
      containers:
      - name: myapp
        image: app:latest
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secrets
              key: password
---

After logging into Environr and creating a new configuration set with a variable named postgres-password, we invoke Helm with


helm upgrade \
  --install \
  mychart path/to/chart \
  -f values.yaml \
  -f < environr-cli env myConfigSet --env-output yamlhead=secrets

This command fetches the myConfigSet configuration set from Environr and formats the output using the yamlhead formatter. The yamlhead formatter nests the environment output under the key path provided. For example, yamlhead=secret.db would create the structure

secret:
  db:
    ... environment output ...

Alternatively, create secrets.yaml followed by invoking Helm with

$ environr-cli env myConfigSet --env-output yamlhead-secrets > secrets.yaml
$ helm upgrade --install mychart path/to/chart -f values.yaml -f secrets.yaml

Using either of the methods above provides a scriptable way to inject centrally managed secrets into Kubernetes and only requires setting 2 environment variables in a CI/CD system (Jenkins, CircleCI, Shippable, Travis, etc.) or local machine to authenticate requests to Environr.

Head on over to Environr, download the CLI, and check it out!

comments powered by Disqus