Protect Your Kubernetes Secrets: Securing with Azure Key Vault

[@SomeInfoSecDude]

Finally the problem is clearly explained. This is what the others videos just skip through, expecting everyone to be a developer with experience on al this. Great video.

[@GodisGreater01]

So I worked on this for a very long time and figured out if you just check the section under advanced - Enable secret store CSI driver. You can do this when creating the Kubernetes service or after under the cluster configuration tab. I do not get an error when trying to connect to the secret when mounting the volume.

[@helshabini]

Thank you Chris, at the time of recording the video this was not available I think. Thank you so much for sharing your finding.

[@mgpollachi1]

Thank you... you saved me from 2 days of frustration on this exact same problem..

[@cartierin]

Great video!! I would love to see another video with Nginx ingress and tls with key vault

[@VCSekharParepalli]

Awesome wording, scripts, content and pace.

[@ZoomSpeaksTech]

Much appreciated!

[@faisalabdi6350]

جزاك الله خيرا يا اخي الكريم. لا توقف علشان نستفيد من خبرتك.

[@nikhilsinghal1315]

Nice video! This video actually explains why and what we are doing instead of just random instructions like other videos. BTW, We are still saving the service principle client id and password in Kubernetes secret which defeats the purpose of this complete video. Can we do this with managed identities?

[@ZoomSpeaksTech]

Hi Nikhil, yes for sure Managed Identities is the best alternative. This guide goes through the process for using User Assigned Managed Identities, which I think is a better way than using the System Assigned one: docs.microsoft.com/en-us/azure/key-vault/general/key-vault-integrate-kubernetes#create-your-own-secretproviderclass-object

[@number-27]

Exactly the crash course I was looking for!

[@karthikvijay4824]

Very well made video, thanks.

[@ZoomSpeaksTech]

Glad you liked it. More coming up soon.

[@krishnadaskp21]

Excellent video. Cleared the concept for me

[@mehmetcolgecen9533]

it is a good one, really enjoyed the explanations, keep going!!!

[@HelpingHands3838]

Simply greate ... Good job

[@rin22john]

Very nice video. Thank you for sharing it with us.

[@ahmedtheba3808]

In all of the various options we still end up with a credential on disk/mount in clear or Base 64 encoded form. There is no protection of the secret if the container is breached. All that we have done is cleaned up the code and pipelines from being littered with secrets.

[@ZoomSpeaksTech]

That’s true. And there is no way around it except if you take the time/effort to write code in your application to try and grab its own secrets from Key Vault using its managed identity.

[@kadabaraghu]

i am using the serviceproviderclass as per the directions , its creating the secertproviderclass but its not creating the secret , when i query for kubectl get secrets i dont dind them there , could you please let me know what could be wrong or is there any additional step i need to follow , int his example you create the secrets in prior should we do the same ???

[@ZoomSpeaksTech]

No, the secret should be created for you. If it is not then there is probably a permission issue somewhere. Check the logs of the secrets provider containers and it might point you somewhere.

[@kalirajannatarajan1114]

Good Video. Thanks

[@ZoomSpeaksTech]

Glad it helped

[@rengaprakashsoundararajan9001]

thanks a lot

[@sharatbhaskar527]

when i run this command export SERVICE_PRINCIPAL_CLIENT_ID="$(az ad sp show --id secrets-store-test --query 'appId' -otsv)" it says service principal does not exist. please suggest

[@ZoomSpeaksTech]

Hi Sharat, this is probably because of a typo in your command. There should be a space between -o and tsv param. Make sure that if you run the az ad sp command that it does produce the proper expected output.

[@alisyed9240]

If the secret volumes are still mounted inside the container. Does it mean that password would still be in clear text and we can simply read the password file?

[@ZoomSpeaksTech]

Yes indeed, if you want an additional layer of security then you can encrypt it and decrypt it using your app.

[@alisyed9240]

@@ZoomSpeaksTech would other solutions like hashicorp vault do the same thing like mount secret volumes with password in plain text or they will at least automatically encrypt it?

[@ZoomSpeaksTech]

They work exactly the same. If this bothers you, the other option is to write code to extract secrets from a secure vault like Azure Key Vault in your app.

[@skannan74]

Thanks for the video. When i run the yaml, i can see the mnt created but fails to create secret. Here is the error i get "Warning Failed 8s (x3 over 20s) kubelet Error: secret "nginx-secret" not found".

[@ZoomSpeaksTech]

That just means the secret was not created by driver. Make sure you’ve specified the correct settings/permissions in the driver YAML.

[@skannan74]

@@ZoomSpeaksTech i followed the examples provided in this video and did exactly same. Can you please throw some light on what are the things i need to check for "correct settings/permissions"..? And thanks for your very fast response.

[@ZoomSpeaksTech]

@@skannan74 i would look at the SecretProviderClass configuration and make sure that the key vault secret I am trying to read actually exists and that the csi driver has the necessary account to do so: docs.microsoft.com/en-us/azure/aks/csi-secrets-store-driver#sync-mounted-content-with-a-kubernetes-secret I would also double check that entire document I sent. My video is now a little dated, and it might be useful to use this doc as an updated reference.

[@ramallways6321]

Then its created an secrets in k8s cluster, then it's mean there is no encrypt here, because k8s secret just encode and decode using base64. Now there is no point to use this one, I'm guess.

[@yasirm]

Can you share your repo?

[@ZoomSpeaksTech]

Sure, here you go: github.com/helshabini/kubernetes-akv

[@yasirm]

@@ZoomSpeaksTech Thank you

[@mkeii]

gosh kubernetes can be so verbose sometimes. this is neat, but everytime i have a new secret, i have to update: 1. the deployment, 2. the secretproviderclass parameters.objects, 3. the secretproviderclass secretobjects 😓

[@ZoomSpeaksTech]

I agree. You can automate everything, but at some point it would be overkill to build something that serves no specific function other than to overcome verbosity. Which is why sometimes I prefer my apps to grab their own secrets whenever possible and absolve kubernetes of having to manage that. Keyvault integration can be easily done on most languages from the app code itself. The app merely needs a managed identity to be able to grab it.