Helm plugin about kubesec HOT 11 OPEN

@philicious no plugin yet I'm afraid (we're not using Helm and so it's hard to justify making it a priority (at least not until Helm 3 is out)). BUT. There is nothing stopping you from using kubesec with Helm:

~/chart$ ls
templates/ .helmignore Chart.yaml values.yaml secret.enc.yaml ...

~/chart$ cat secret.enc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: helloworld
  labels:
    app: helloworld
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
type: Opaque
data:
  KEY: TUFkWD1iuKs=.O....D...=
  ANOTHER_KEY: iOy1nf90+M6FrrEIoymN6cOSUYM=.E...=.q...=
# kubesec:v:3
# ...
# kubesec:mac:G5phaA8VV84refpV.idjQQUHj3LS0NJXFZFaCeQ==

~/chart$ grep secret .helmignore
templates/secret.yaml

~/chart$ kubesec decrypt secret.enc.yaml -o templates/secret.yaml
~/chart$ helm install .

from kubesec.

Does this mean you are wanting helm to be able to run kubesec and decrypt the data before using it in the chart?

from kubesec.

Yep.

from kubesec.

I'm actually using this with kustomize.
Still didn't figure out what's the best way except for manual decryption before k apply

from kubesec.

Cool!

I am also looking for a tool to integrate with helm. One such tool is helm-secrets, I haven't used it though. Would you be aiming for some different functionality?

from kubesec.

futuresimple/helm-secrets looks interesting but not quite what I have in mind.

1. helm-secrets appears to use sops for secret .Values management. Secret templates and values are kept separately. This is different from kubesec, where each Secret is normally "self-sufficient".

   NOTE: Secret's metadata is not included in MAC and so kubesec-encrypted Secret can have template placeholders as shown below:

   apiVersion: v1
   kind: Secret
   metadata:
     name: helloworld
     labels:
       app: helloworld
       chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
       release: "{{ .Release.Name }}"
       heritage: "{{ .Release.Service }}"
   type: Opaque
   data:
     KEY: TUFkWD1iuKs=.O....D...=
     ANOTHER_KEY: iOy1nf90+M6FrrEIoymN6cOSUYM=.E...=.q...=
   # kubesec:v:3
   # ...
   # kubesec:mac:G5phaA8VV84refpV.idjQQUHj3LS0NJXFZFaCeQ==

   You can either "kubesec decrypt, then replace placeholders with values" or "replace placeholders with values, then decrypt". The order doesn't matter.
   For example, kubetpl can freeze kubesec-managed Secrets before or after decryption.

2. helm plugin for kubesec does not need to concern itself with anything but decryption (kubesec cli provides "edit", "encrypt", etc. already)

from kubesec.

OK I just tested out helm-secrets. TBH I think it's too complicated.

It encrypts all the values in the secret file:

apiVersion: ENC[AES256_GCM,data:2EY=...,type:str]
kind: ENC[AES256_GCM,...,type:str]
metadata:
    name: ENC[AES256_GCM...,type:str]

I find the documentation difficult to understand. I still don't understand the file layout.

Please update this issue with any progress!

from kubesec.

I might also have a use-case for kubesec + Helm soon.

Have you guys been doing any work towards a plugin yet that I might check out or contribute to ?

from kubesec.

I persisted with helm-secrets, now I get the kinda rigid file naming and layout. It works pretty well once you understand this and we are now using it extensively.

I'm still keen to see a kubesec helm plugin though.

from kubesec.

@shyiko while I've been using kubesec alot in the past and think its great and feels more lightweight than https://github.com/futuresimple/helm-secrets , I encountered a scenario where its just not an option and I wanted to share my thoughts and findings:

https://github.com/roboll/helmfile is a popular and great way to orchestrate/manage multiple Helm charts and their values. It can also handle secrets and for decryption uses helm-secrets by calling helm secrets dec.
So at first I was like "finally a good opportunity to do a kubesec helm plugin" which would just mimic the same command interface. However, there are two reasons that wouldnt work out:

• unfortunately helmfile treats secrets as plain values and not as Secret manifests. Those values are then referenced in the actual Secret manifest. helm-secrets itself can do both: enc/dec pure json/yaml files aswell as Secret manifests (just like kubesec does)
• kubesec doesnt support encrypting plain value files as it checks for kind: Secret presence afaik. otherwise it would have been easy using kubesec as a dropin replacement for helm-secrets with helmfile

from kubesec.

https://github.com/roboll/helmfile is a popular and great way to orchestrate/manage multiple Helm charts and their values. It can also handle secrets and for decryption uses helm-secrets

I agree. The workflow with secrets and multiple charts when using helmfile, helmdiff and helm-secrets is really nice. Kinda like Terraform.

from kubesec.