Venkat, for that thing where you were surprised that the secret got updated in the pod this is how it supposed to work for volume-mounted secret. Perhaps earlier you have tried updating a secret mounted through env variable. Those won't get updated.
Hi Shai, thanks for watching this video and taking time to comment. Yes you are right. The reason I was surprised is that when I was doing a test run of this video, it behaved differently. Thanks, Venkat
Really, it helps a lot to me to understand the secrets concept in Kubernetes, can you please upload for volumes video as well, please ignore if you are already done this.
Hi Jagan, thanks for watching. Here is my full kubernetes playlist ua-cam.com/video/YzaYqxW0wGs/v-deo.html And here is a video about dynamic volume provisioning ua-cam.com/video/DF3v2P8ENEg/v-deo.html
Hi, thanks for watching this video. I have done couple of videos on ingress topic. One based on Nginx ingress and the other on Traefik. Please find them in the below links. ua-cam.com/video/chwofyGr80c/v-deo.html ua-cam.com/video/A_PjjCM1eLA/v-deo.html Thanks
Hi Venkat. Thanks for putting all the videos together. They are great and very helpful!. I was reading through comments from other people and some was asking about using "Vault" for secret source. are u still planning on doing that video?
Hi venkat, thank you for your video, clear and straight to the point. I have a question about the base64 encoding while defining the secret, is it what it is required to get it converted into the pod. I wonder if you could have something a bit stronger than base64 to encoded the secret, because that is really easy to decode for anyone having access to the secret definition file
Hi Laurent, Thanks for watching my video and thanks for bringing this to the table. Very valid point. By default Kubernetes secrets are all base64 encoded. And can be accessed and decoded by anyone having access to the cluster. Well you can fine tune acess control like creating a namespace and creating secrets in that namespace. Then restrict access to those who want it for that namespace. And in that namespace restrict access to properties like "watch", "get", "list" for the secret resource. But those add lot more complexities and still its not the best way. None of the nodes in the cluster will store the secrets in their local filesystem anywhere. When a pod requests a secret, it gets pulled from the etcd datastore and stored in tmpfs (temporary filesystem in memory) and get removed after the lifecycle of the pod. So basically the secrets are stored in plaintext in the etcd datastore. If you are not aware of etcd, its a datastore where Kubernetes cluster data is stored as key value pairs. If you have access to the etcd node, you can retrieve those secrets using etcdctl command I think. If you want to encrypt the secrets in etcd datastore you can follow below link, kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ Or you can use Key Management Service (KMS) for encrypting data in the etcd. AWS has KMS service. Still it doesn't solve the main issue you pointed out. For that I think Hashicorp's Vault service may give some security. But I haven't tried it yet. Basically you run this Vault service either within Kubernetes cluster or externally on a virtual machine or physical server. You can then use the Vault to store secrets. Thanks, Venkat
Thats what Kubernetes uses to store the secrets - base64 encoding and it is not supposed to substitute encryption. In fact, Kubernetes does not encrypt the secrets by default and they are stored unencrypted at rest. There is a separate object starting v1.7 called EncryptionConfig that can be used to encrypt secrets at rest (i.e. in etcd).
Hello Venkat, just curious to know if you are planning to record a video on integrating Hashi Corp Vault with Kubernetes. As you know the limitations of secrets, enterprises are more inclined towards using Vault. Looking forward to your inputs.
@@waterkingdom9839 MongoDB is a separate series. My commitment is to release a video every Monday for Kubernetes and one for MongoDB. I have another 4 for k8s waiting to be released in the coming Mondays. Even if I record now, it will be released after 5 weeks. Thanks.
Hi Bala, thanks for watching this video. Yes in Kubernetes if you secrets, they are not really secrets unless you protect your repository and use it in a namespace where you restrict users. Otherwise you can use Hashicorp's Vault for managing secrets externally. There is a good blog post about it which you can check in the below link. blog.kubernauts.io/managing-secrets-in-kubernetes-with-vault-by-hashicorp-f0db45cc208a Thanks.
Hi Sir, i have created the secret file but the problem is in mine the secret file is stored inside pod as .yaml file and i can not access its contents the way you are accessing, please help, actually i need to use the credentials in another script.
Hi Faisal, thanks for watching. Have you checked what if you skip that line? Basically I want the busybox container to run for some time before exiting as I want to test the secrets mounted. If you skip that line, the pod will error/crashloopbackoff. Just try it and see it for yourself. Cheers.
base64 is not encryption, but encoding. If you store your secret.yaml into the source control and I have access to your files, I can decode your password, since it was never encrypted, but it was encoded. So, never, never store secrets in the source control which contain opaque passwords. Even if you do not store secret.yaml files into the source control but I have access to etcd file storage, I'm able to grab your passwords because opaque secrets can be easily decoded. Once again, base64 is not encryption, but encoding. I just need to tell base64 to decode a string and hack done... I have your password. The problems is: opaque secrets are not secure, does not matter how you create it. Opaque secrets are not secure. Period.
![[ Kube 15 ] Using ConfigMaps in Kubernetes Cluster](http://i.ytimg.com/vi/upmLONFGNBs/mqdefault.jpg)
![[ Kube 15 ] Using ConfigMaps in Kubernetes Cluster](/img/tr.png)
![[ Kube 20 ] NFS Persistent Volume in Kubernetes Cluster](http://i.ytimg.com/vi/to14wmNmRCI/mqdefault.jpg)
![[ Kube 16 ] Using Resource Quotas & Limits in Kubernetes Cluster](/img/n.gif)
I was searching for ways to keep secrets updated without needing to restart my pods and you gave me the answers. Thank you
Hi Damien, no worries. Thanks for watching.
thanks for such a simple presentation. i am practicing these steps after watching this video.
Hi, thanks for watching this video.
Venkat, for that thing where you were surprised that the secret got updated in the pod this is how it supposed to work for volume-mounted secret. Perhaps earlier you have tried updating a secret mounted through env variable. Those won't get updated.
Hi Shai, thanks for watching this video and taking time to comment. Yes you are right. The reason I was surprised is that when I was doing a test run of this video, it behaved differently.
Thanks,
Venkat
yes, env won't get updated, but volume can be updated dynamically
Yeah I realized that later. Thanks.
Whoa.. I am learning k8s.
Hi Thamarai, you are welcome and thanks for your interest in this series.
thanks for such a simple presentation
Hi, Thanks for watching this video.
Really, it helps a lot to me to understand the secrets concept in Kubernetes, can you please upload for volumes video as well, please ignore if you are already done this.
Hi Jagan, thanks for watching.
Here is my full kubernetes playlist
ua-cam.com/video/YzaYqxW0wGs/v-deo.html
And here is a video about dynamic volume provisioning
ua-cam.com/video/DF3v2P8ENEg/v-deo.html
Excellent Kubernetes Videos. Very easy to follow by a novice. One small request if a dedicated video can be created for Ingress Controller.
Hi, thanks for watching this video.
I have done couple of videos on ingress topic. One based on Nginx ingress and the other on Traefik. Please find them in the below links.
ua-cam.com/video/chwofyGr80c/v-deo.html
ua-cam.com/video/A_PjjCM1eLA/v-deo.html
Thanks
Nicely explained...thanks
HI Gaurav, thanks for watching.
thank you very much, your content is very useful..
Hi Joe, thanks for your interest in this channel. Cheers.
Thanks so much for this tutorial.
Hi Roman, thanks for watching.
Hi Venkat. Thanks for putting all the videos together. They are great and very helpful!. I was reading through comments from other people and some was asking about using "Vault" for secret source. are u still planning on doing that video?
Hi Vivek, Thanks for watching. Yes, Vault is in my list. Will cover it at some point. Cheers.
Tks Venkat so much
You are welcome and thanks for watching this video.
very good
Thanks for watching Abhishek.
Hi venkat, thank you for your video, clear and straight to the point. I have a question about the base64 encoding while defining the secret, is it what it is required to get it converted into the pod. I wonder if you could have something a bit stronger than base64 to encoded the secret, because that is really easy to decode for anyone having access to the secret definition file
Hi Laurent,
Thanks for watching my video and thanks for bringing this to the table. Very valid point.
By default Kubernetes secrets are all base64 encoded. And can be accessed and decoded by anyone having access to the cluster. Well you can fine tune acess control like creating a namespace and creating secrets in that namespace. Then restrict access to those who want it for that namespace. And in that namespace restrict access to properties like "watch", "get", "list" for the secret resource.
But those add lot more complexities and still its not the best way.
None of the nodes in the cluster will store the secrets in their local filesystem anywhere. When a pod requests a secret, it gets pulled from the etcd datastore and stored in tmpfs (temporary filesystem in memory) and get removed after the lifecycle of the pod. So basically the secrets are stored in plaintext in the etcd datastore.
If you are not aware of etcd, its a datastore where Kubernetes cluster data is stored as key value pairs. If you have access to the etcd node, you can retrieve those secrets using etcdctl command I think.
If you want to encrypt the secrets in etcd datastore you can follow below link,
kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Or you can use Key Management Service (KMS) for encrypting data in the etcd. AWS has KMS service.
Still it doesn't solve the main issue you pointed out. For that I think Hashicorp's Vault service may give some security. But I haven't tried it yet. Basically you run this Vault service either within Kubernetes cluster or externally on a virtual machine or physical server. You can then use the Vault to store secrets.
Thanks,
Venkat
Thats what Kubernetes uses to store the secrets - base64 encoding and it is not supposed to substitute encryption. In fact, Kubernetes does not encrypt the secrets by default and they are stored unencrypted at rest. There is a separate object starting v1.7 called EncryptionConfig that can be used to encrypt secrets at rest (i.e. in etcd).
Hello Venkat, just curious to know if you are planning to record a video on integrating Hashi Corp Vault with Kubernetes. As you know the limitations of secrets, enterprises are more inclined towards using Vault. Looking forward to your inputs.
Yeah. I was covering the fundamental concepts in K8s. And vault is in my to do list. Thanks for reminding me.
@@justmeandopensource when do you plan to record it? I know now you are focusing on MongoDB tutorials.
@@waterkingdom9839 MongoDB is a separate series. My commitment is to release a video every Monday for Kubernetes and one for MongoDB. I have another 4 for k8s waiting to be released in the coming Mondays. Even if I record now, it will be released after 5 weeks. Thanks.
@@justmeandopensource OK...looking forward to your new videos.
@@waterkingdom9839 Thanks.
Hello Venkat, can you please create or give some idea for how to connect local on a prime MySQL database to the Kubernetes cluster or pod
People who have access to the repo where we pushed our secrets can decode the password. How to overcome this?
Hi Bala, thanks for watching this video. Yes in Kubernetes if you secrets, they are not really secrets unless you protect your repository and use it in a namespace where you restrict users. Otherwise you can use Hashicorp's Vault for managing secrets externally. There is a good blog post about it which you can check in the below link.
blog.kubernauts.io/managing-secrets-in-kubernetes-with-vault-by-hashicorp-f0db45cc208a
Thanks.
@@justmeandopensource Thanks, Venkat. Really appreciate your help.
@@balasekharnelli9218 No worries. You are welcome.
Can we do the same , where it provision the vms on ur laptop or let say if i clone then on google cloud vm then what will be the case
Video Request: hashicorp vault
Thanks. I will add it to my list.
How to connect AWS postgresql to a deployment.environment kops
Hi Sir, i have created the secret file but the problem is in mine the secret file is stored inside pod as .yaml file and i can not access its contents the way you are accessing, please help, actually i need to use the credentials in another script.
Hi Venkat how to create k8s secret from private key json file (which has special characters )
may I know how to use secret to store privatekey etc ?
make a video for using certificates in secrets
Hi Rahul, thanks for watching. I will add it to my list. Cheers.
I am stuck at this.. There is scarce info about it..
There is only tls.crt and tls.key
What if I have only signed ca.crt from the CA directly?
What if I skip this line:
args: ["-c", "sleep 600"]
Hi Faisal, thanks for watching. Have you checked what if you skip that line? Basically I want the busybox container to run for some time before exiting as I want to test the secrets mounted. If you skip that line, the pod will error/crashloopbackoff. Just try it and see it for yourself. Cheers.
base64 is not encryption, but encoding.
If you store your secret.yaml into the source control and I have access to your files, I can decode your password, since it was never encrypted, but it was encoded.
So, never, never store secrets in the source control which contain opaque passwords.
Even if you do not store secret.yaml files into the source control but I have access to etcd file storage, I'm able to grab your passwords because opaque secrets can be easily decoded. Once again, base64 is not encryption, but encoding. I just need to tell base64 to decode a string and hack done... I have your password.
The problems is: opaque secrets are not secure, does not matter how you create it. Opaque secrets are not secure. Period.
Thanks for the clarification. I understand its not encryption but encoding.
Hi
Hello
@@justmeandopensource I need some help for how to pass kubernets secret value into deployment yaml, can you please help me out please
With ENV i habe access to $ENV_VARIABLE, how about VOLUME SECRETS, how i use them?