Great video... it's like the External Secret Operator (ESO). in VSO we use the VaultAuth and VaultStaticSecrets CRDs instead of SecretStore and ExternalSecrets CRDs in ESO. The only limitation I know on the ESO is that it support only the KV secret Engine in Vault.
Thats correct. If you already have vault, i'd use VSO since its a hashicorp solution. But before VSO, ESO was another generic approach. Let me know if you'd like to see a similar video for VaultDynamicSecrets with databases and other dynamic engines in vault.
Awesome video! Can you help me understand something? If we have a deployment named dep1 with three replicas, will updating the credentials happen on all pods simultaneously or one by one when the deployment is updated as per your video sync 10.40, in my understanding as per your video suppose we are setting for 10s to refresh as you said but need to understand will this refreshment will be done in all pods together or 1:1?
Vso will update the kubernetes secrets resource and then it does a rollout restart on the deployment. The way rollout restart works (default) is it will bring up new 1 pod at a time, wait for it to be ready and then delete the old pod. So it will do it 3 times for 3 replicas
@@cookncode thanks. I gone through it and successfully implemented. Now I am trying to use the credential to query the database. I have a micro service which interaction with postgres db. Another thing, is this setup hold good for enterprise vault ( saas )?
@@shishirroy1516 yeah it will work with vault enterprise too. Enterprise version has additional features like performance replication, auto snapshots etc but the common functionality works the same way
Thanks for the video, if we have multiples micro services then we have to use single operator vso or should deploy seperate for all micro services separately?
You only need to deploy 1 vso per cluster. It will manage secrets for any number of applications deployed to you cluster through the custom resources that you configure.
@@Kk-rl7nv VSO is specifically for kubernetes workloads. You can have vault deployed anywhere but if you have applications deployed to kubernetes then you can use vso to deliver the secrets
Thank you for the video, but I have a question. In my case, I have a Kubernetes cluster. If I use Vault server in dev mode, the storage is in-memory, so when restarting the VM, the data created will be lost. Can I use Vault server and Vault Secrets Operator (VSO) in this scenario?
Not sure i follow! In the video i am enabling the kvv2 and adding secrets manually! Are you asking how you’d automate that process in a production setup?
@@cookncode Yeah, I was just wondering how you go about enabling kvv2 and secrets automatically. Im using a bash script currently. But theres probably better ways to do it :)
Gotcha! Yeah so for kvv2 which are static secrets there is always the secret 0 problem of how you populate the secrets. You’ll have to either manually add them in ui or from cli or can use scripts or awx playbooks etc.
why are vso and the application and vault sts in different namespaces? vault in vault, vso in vault-secrets-operator-system, and the vaultAuth and the application deployment in the fakeapp namespace?? Is there any special reason for this?
I appreciate your clear and understandable explanations, until now I haven't seen anything like it.
Great video... it's like the External Secret Operator (ESO).
in VSO we use the VaultAuth and VaultStaticSecrets CRDs instead of SecretStore and ExternalSecrets CRDs in ESO.
The only limitation I know on the ESO is that it support only the KV secret Engine in Vault.
@@shabbirsaifee7497 yes please. good stuff , keep up the good work sir
Thats correct. If you already have vault, i'd use VSO since its a hashicorp solution. But before VSO, ESO was another generic approach.
Let me know if you'd like to see a similar video for VaultDynamicSecrets with databases and other dynamic engines in vault.
Checkout the dynamic credentials for databases video as well on the channel!
very nice. Can you do OIDC vault auth
Didn't watch till the end but it's definitely valuable content ! Subscribed for next topics !
Is quite good actually. Thank you!
Great video! Hello from Brazil. Thanks
@@renatosouza1k glad you found it useful!
Great video, very informative..
can you do a tutorial for kubernetes + vault hosted outside of kubernetes . or guide on the configuration
Greate video! Very clear. Would you suggest to use Vault Secrets Operator other than the Vault CSI Provider ?
Awesome video! Can you help me understand something? If we have a deployment named
dep1 with three replicas, will updating the credentials happen on all pods simultaneously or one by one when the deployment is updated as per your video sync 10.40, in my understanding as per your video suppose we are setting for 10s to refresh as you said but need to understand will this refreshment will be done in all pods together or 1:1?
Vso will update the kubernetes secrets resource and then it does a rollout restart on the deployment.
The way rollout restart works (default) is it will bring up new 1 pod at a time, wait for it to be ready and then delete the old pod.
So it will do it 3 times for 3 replicas
its a great video. how can i implement dynamic cred for postgres with given ttl
@@shishirroy1516 ruclips.net/video/tski0aNbXk4/видео.htmlsi=fhqRu2MY6GWjnPC3
Its covered in the next video
@@cookncode thanks. I gone through it and successfully implemented. Now I am trying to use the credential to query the database. I have a micro service which interaction with postgres db.
Another thing, is this setup hold good for enterprise vault ( saas )?
@@shishirroy1516 yeah it will work with vault enterprise too. Enterprise version has additional features like performance replication, auto snapshots etc but the common functionality works the same way
Thanks for the video, if we have multiples micro services then we have to use single operator vso or should deploy seperate for all micro services separately?
You only need to deploy 1 vso per cluster. It will manage secrets for any number of applications deployed to you cluster through the custom resources that you configure.
Can you suggest here if we Hashicorp vault running in vm in cloud seperate from k8s then in this scenario can we use vso?
@@Kk-rl7nv VSO is specifically for kubernetes workloads. You can have vault deployed anywhere but if you have applications deployed to kubernetes then you can use vso to deliver the secrets
Thank you for the video, but I have a question. In my case, I have a Kubernetes cluster. If I use Vault server in dev mode, the storage is in-memory, so when restarting the VM, the data created will be lost. Can I use Vault server and Vault Secrets Operator (VSO) in this scenario?
Yes! Remember that dev mode is only when you are testing! In production you’ll setup vault in high availability mode! Yes you can use vso as well
How are you automating things like enabling kv2 and popping in secrets?
Not sure i follow! In the video i am enabling the kvv2 and adding secrets manually!
Are you asking how you’d automate that process in a production setup?
@@cookncode Yeah, I was just wondering how you go about enabling kvv2 and secrets automatically. Im using a bash script currently. But theres probably better ways to do it :)
Gotcha! Yeah so for kvv2 which are static secrets there is always the secret 0 problem of how you populate the secrets.
You’ll have to either manually add them in ui or from cli or can use scripts or awx playbooks etc.
@@cookncode Came to that conclusion as well. Thx!
why are vso and the application and vault sts in different namespaces?
vault in vault, vso in vault-secrets-operator-system, and the vaultAuth and the application deployment in the fakeapp namespace??
Is there any special reason for this?
@@savagesamurai9196 its just for segregation!
@@cookncode K thanks.