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.

Excellent video. Cleared the concept for me

Exactly the crash course I was looking for!

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

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

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

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

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

Very well made video, thanks.

@ZoomSpeaksTech

3 жыл бұрын

Glad you liked it. More coming up soon.

Simply greate ... Good job

Awesome wording, scripts, content and pace.

@ZoomSpeaksTech

10 ай бұрын

Much appreciated!

Good Video. Thanks

@ZoomSpeaksTech

2 жыл бұрын

Glad it helped

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

3 жыл бұрын

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

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

2 жыл бұрын

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

thanks a lot

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.

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.

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

2 жыл бұрын

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

@skannan74

2 жыл бұрын

@@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

2 жыл бұрын

@@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.

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

2 жыл бұрын

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

@alisyed9240

2 жыл бұрын

@@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

2 жыл бұрын

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.

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

2 жыл бұрын

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.

Can you share your repo?

@ZoomSpeaksTech

2 жыл бұрын

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

@yasirm

2 жыл бұрын

@@ZoomSpeaksTech Thank you

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.

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.