StackStorm / stackstorm-k8s

K8s Helm Chart that codifies StackStorm (aka "IFTTT for Ops" https://stackstorm.com/) Highly Availability fleet as a simple to use reproducible infrastructure-as-code app
https://helm.stackstorm.com/
Apache License 2.0
105 stars 106 forks source link

Vault support for stackstorm #252

Open sarthak1996 opened 3 years ago

sarthak1996 commented 3 years ago

I was wondering if there is a vault support for stackstorm. If not then how can we manage secrets? Having secrets stored in some other file than values.yaml might also not be a good option as it will still be plain text.

Does stackstorm support pulling secrets from vault? If yes then can you point me to a documentation for the same. If there is no support for vault can someone help me with a way to store secrets safely.

chris3081 commented 3 years ago

As far as I know hashivault (assuming you mean hashivault) isn't supported, only the st2 key vault built in is supported. That said I would like to see a plugin style interface as we have a few different key vaults we draw from and it would be good to implement multiple plugin engines to support our packs.

cognifloyd commented 3 years ago

There are two different issues here:

  1. secrets needed during installation with helm + our stackstorm-ha chart (this repo)
  2. using secrets in actions or workflows within stackstorm itself

On the first point, you need something that either interfaces with helm or that post-processes the resources created by helm. Both approaches are out of scope for helm charts in general, as the charts do not have that level of control around how helm runs. I do, however, use vault-provided secrets with this chart. I use helm-secrets to inject those secrets: https://github.com/jkroepke/helm-secrets Use this example to see how to use vault with helm-secrets (the docs focus on sops, not on vault): https://github.com/jkroepke/helm-secrets/blob/main/examples/vault/secrets.yaml

On the second point, you can use the vault pack to query hashicorp vault from within your workflows: https://github.com/StackStorm-Exchange/stackstorm-vault Not a perfect integration, but I hope we can improve the situation over time.

chris3081 commented 3 years ago

agreed, I use ansible to drive our helm installations, but have in the past used azure KV in Azure Devops to do the same thing, I think point 1 is easier handled either in helm secrets or via your deployment pipeline. Point 2 I think is better handled in Stackstorm itself.

cydergoth commented 3 years ago

https://github.com/StackStorm/st2/issues/5401

cflanny commented 2 years ago

We are using Terraform to deploy the helm chart, and Terraform has a vault provider which can inject secrets into the values. In particular, we generate the secrets during the apply and store them in Vault at the same time.

The other option if you are using the Kubernetes auth backend for Vault is to use the Vault Injector (https://www.vaultproject.io/docs/platform/k8s/injector) to create the secrets in the filesystem under /vault which can then be referenced.

cydergoth commented 2 years ago

This is a good observation but doesn't resolve the issue of being able to download arbitrary packs using st2kv and redirecting them all to an auditor friendly backend

On Fri, May 27, 2022, 2:24 PM Chris Flanagan @.***> wrote:

We are using Terraform to deploy the helm chart, and Terraform has a vault provider which can inject secrets into the values. In particular, we generate the secrets during the apply and store them in Vault at the same time.

The other option if you are using the Kubernetes auth backend for Vault is to use the Vault Injector ( https://www.vaultproject.io/docs/platform/k8s/injector) to create the secrets in the filesystem under /vault which can then be referenced.

— Reply to this email directly, view it on GitHub https://github.com/StackStorm/stackstorm-k8s/issues/252#issuecomment-1139963854, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPWAWRTB3SNJVXRTVZM5NLVMEOPDANCNFSM5EWUAZHA . You are receiving this because you commented.Message ID: @.***>

cwilson21 commented 1 year ago

Just to chime in here, we use GKE to run our cluster(s) , and with taht we use Cloudbuild to build the cluster(s). WIth this we are able to at build pull secrets from Google Secret Manager , which for us are all of our sensitive bits, and you format the secret like it was part of the chart for stackstorm so when you include that extra file it effectively populates it in the base chart to add them to the KV store without ever storing them in a place that has them in plain-text. There are ways of getting around not being able to pull from hashivault on build you just have to find them and be creative.

docbyte86 commented 1 year ago

agreed, I use ansible to drive our helm installations, but have in the past used azure KV in Azure Devops to do the same thing, I think point 1 is easier handled either in helm secrets or via your deployment pipeline. Point 2 I think is better handled in Stackstorm itself.

We have an ansible role retrieving secrets from vault and store them as ansible variables. So we can use it in further ansible tasks, like installing helm charts.