I installed a Hasicorp Vault server via Helm with my custom values.yaml file (used this as a reference: https://developer.hashicorp.com/vault/docs/platform/k8s/helm/configuration)
I know I can enable different secrets engines after I initialize and unseal Vault (via the UI, CLI or API).
However, I am wondering whether it is possible to enable secrets engines via the values.yaml before initializing and unsealing Vault - i.e., when I open the UI after initializing and unsealing Vault I would like to see these engines already enabled and on the list of secrets engines (without enabling them manually).
I searched online for a way to do this but my efforts were in vain. I would really appreciate any answer on this subject.
Thanks in advance!
Related
Hi i'm working on task that is in regards which one we should implement for Kubernets secrets Vault or github secrets.
i'm still very new to kubernets so i need help with this, if anyone can help me with some references that explain how we can store secrets and credentials in guthub secrets and use those github credentials in kubernets as secrets.
We are running
on-prem kubernetes
github enterprise
i have configure secrets through github and trying to use in kubernets but i have no idea how to do that just blank here.
You can use Sealed Secret to manage your k8s secrets in github.
Sealed Secrets is composed of two parts:
A cluster-side controller / operator
A client-side utility: kubeseal
The kubeseal utility uses asymmetric crypto to encrypt secrets that only the controller can decrypt.
To learn more, head over to sealed-secret github repo
I am new to K8s and trying to create a Helm chart to setup my application.
I want a frictionless experience for users setting up the application without much manual intervention.
Creating the helm chart i was pleased with the provided templating functionallity but missing one essential thing: Creating passwords.
I don't want the user to have to create the passwords for my API to talk to redis etc.
Setting up Vault is also one of the more difficult parts as its key has to be initially created it then needs to be unlocked and resources like userpass and other engines and resources have to be created.
For a docker-compose setup of the same app i have a "install container" that generates the passwords, creates resources on Vault with its API etc.
Is there another possibility using kubernetes/helm?
Thanks
You could try Sealed Secrets. It stores secrets encrypted using assimetric keys, so they secrets can be only restored having the proper keys.
We are trying to create an environment using crossplane and argocd. Once Crossplane generates the database and saves the credentials to a secret on the management cluster. After we are deploying the credentials from management cluster to our destination cluster to a secret.
Now we need to pass the credentials from secret a to secret B which the application knows about. The issue starts when argo do not use helm install but template thus lookup function don't work. We thought about using vault as a middle man but we are not sure how to load values from secret to vault.
Anyway if you encounter such an issue or have some sort of a solution we'll be very happy to hear.
Thank you
You need to commit the (encrypted) secrets somewhere for ArgoCD to pick them up. That is the whole point of GitOps.
Alternatively you can try using https://argo-cd.readthedocs.io/en/stable/user-guide/parameters/ but this is considered a temporary workaround
I'm totally new to Vault and what I want is to detect when a secret changes and execute some code in response. I've been googling for resources about how to do that but haven't found anything useful. From what I've read and learnt, I think the only way of achieving what I want is by implementing a custom secrets engine. Am I right? Do you know a better way of achieving what I want?
There is no event option in the vault as of now, so on changes, we get notified it's natively changing the Key/value pairs.
i would recommend using the polling method if you have any such scenario with the vault.
Here is one nice CRD which also does the polling option and syncs the vault secret to Kubernetes secret.
This might useful for reference : https://github.com/DaspawnW/vault-crd
There currently are no triggers that'll tell you when the secret has changed. If you're running kubernetes (sidecar) or using the Vault agent, this is minimized as the agent will auto-pull any new secrets down (configurable).
I have a couple Charts which all need access to the same Kubernetes Secret. My initial plan was to create a Chart just for those Secrets but it seems Helm doesn't like that. I am thinking this must be a common problem and am wondering what folks generally do to solve this problem?
Thanks!
Best practice is, don't save any sensitive secrets in kubernetes clusters. kubernetes secret is encode, not encrypt.
You can reference the secret via aws ssm/secrets manager, hashicorp Vault or other similars.
https://github.com/aws-samples/aws-workshop-for-kubernetes/tree/master/04-path-security-and-networking/401-configmaps-and-secrets
Most charts that follow the common chart development practices allow you to use an existing secret instead of creating one for you. This way, you can create your common secrets normally (without helm), and refer to them from the charts that need them, via a reference like existingSecret config key.
Take minio helm chart for example: it accepts an existingSecret key as an alternative to passing an accessKey and a secretKey.
As you can see in the main charts repo, this is a pretty common practice.