Helm and secret control

A good and recommended tool for setting up services in OpenShift is Helm. It is a template engine that understands Kubernetes, and it can be used to parameterize a YAML fed to OpenShift and to change it intelligently from a terminal to components in your own projects.

This article introduces a way to keep encrypted secrets in a Helm charts Git repository.

Necessary tools

Install the following tools by following the instructions found in the links and/or using your operating systems package manager.

1. OpenShift commandline client oc
   1. Download the package openshift-client-...for your own client from https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/
2. Helm
   1. https://helm.sh/docs/intro/install/
3. Helm secrets plugin
   1. https://github.com/jkroepke/helm-secrets
4. GnuPG
   1. For example apt install gnupg
   2. Not the only option. SOPS supports alternative encyption backends. This article will however be focused on GPG.
5. SOPS
   1. https://github.com/mozilla/sops

Settings file

Create a .sops.yaml file to your repository with the following contents:

creation_rules:  - pgp: >-      comma,      separated,      list,      of,      pgp-fingerprints

A fingerprint is an identifier for a personal PGP-key which looks something like this: 78F7F1856BB695563D5BBA877F9D8156A3CF7EE3.

List the PGP key for everyone who should be able to install your project in OpenShift. The secrets will be encypted against these keys, so everyone listed here can also decrypt the secrets.

.gitignore

Add the following lines to your .gitignore file so you do not accidentally commit secrets in plaintext:

*.yaml.dec*.yml.dec

USAGE

Secret-yamls and referencing in a templateAn example would be to create the files secrets.test.yaml and secrets.prod.yaml. List all your test and production environment secrets:

tls_cert: |-  -----BEGIN CERTIFICATE-----  ...  -----END CERTIFICATE-----tls_chain: |-  -----BEGIN CERTIFICATE-----  ...  -----END CERTIFICATE-----tls_privkey: |-  -----BEGIN PRIVATE KEY-----  ..  -----END PRIVATE KEY-----

Then you can reference your secrets in a template like this:

route.openshift.io/v1

# chart/templates/route.yamlkind: RouteapiVersion: metadata: name: my_app namespace: my_projectlabels: app: my_app type: externalspec: host: {{ .Values.route_hostname }} # set this value in the file values.environment.yaml (no need for encyption) to: kind: Service name: my_app tls: termination: edge insecureEdgeTerminationPolicy: Redirect key: | {{- .Values.tls_privkey | nindent 6 }} certificate: | {{- .Values.tls_cert | nindent 6 }} caCertificate: | {{- .Values.tls_chain | nindent 6 }}

Commands

Encrypting a secretFirst make sure that you have imported the public keys for every key listed in the .sops.yaml settings file to your GPG keyring. You may need to give them an appropriate confidence level so that GPG will allow encryptions for them. The essential commands for this are gpg --import (import from file) and gpg --recv-keys (receive from a key server) – find more in GnuPG documentation.

Encrypt your secret.yaml with:

helm secrets enc secrets.environment.yaml

The file is now replaced with an encrypted version.

Editing an encrypted secret

helm secrets edit secrets.environment.yaml

Viewing an encrypted secret

helm secrets view secrets.environment.yaml

Decrypting a secret

helm secrets dec secrets.environment.yaml

A plaintext file secrets.environment.yaml.dec should be added to the same folder as your encrypted secret

Wrapper for other Helm commands

The Helm secrets plugin knows how to use encrypted secrets transparently without decryption as a middle step, by wrapping other Helm commands conveniently. The following command lets you create a release for your project using encrypted secrets:

helm secrets upgrade --install -f secrets.environment.yaml -f values.environment.yaml release-name .