This tutorial was great. I set this up with Terraform and put a rotation on the key creation every 45 days, I never need to know this key and the namespace where it is stored is only accessible for cluster administrators. For anyone that wants to do a rotation with terraform use the time_rotating resource and rotation_days. use lifecycle for the key to create before destroy (AWS allows for 2 keys). Set up a null_resource to trigger on the UNIX time updating in the time_rotating. Then finally to retrigger use replace_triggered_by and set the reference to the null resource. this should make key replacement part of the plan/apply, you can test with rotation_minutes to make sure everything works and you get the correct key. Figured I share this since it took me a day to figure out.
Nicely explained! Only rec would be to actually define what encoding is and why K8s does that by default (helps remove special characters and what not) vs. encrypting (uses a key to mathematically manipulate the secret value in such a way to make it impossible to read in plaintext without the key).
pro tip: never use echo to encode or decode with base64, because the sensitive date is now in your shell history. Instead used cat and ctrl+d to finish input, like this: cat | base64 -d
hey man great video but I was hoping to get some help on the external secrets operator, I have a full setup with infisical's provider(infisical is basically an open source and self hosted alternative to aws ss) but the problem is for some reason the external secrets operator does not create the managed secret, this is all running on eks cluster and I see no error logs both the secret store and external secrets crds tell me everything is synced and ready yet I see no managed secret being created, this same setup works on my local kind cluster no issues but not on eks
Good demo of c the flow of this new middleman process. It solves the problem of defining credentials in YAML files that might become accidentally checked in to a source code repository. But it doesn't solve the other problem with using the internal secrets mechanism of Kubernetes. As of about 2022, there was still an inherent flaw with secrets within a K cluster in that the underlying data was physically persisted on disk on the main nodes in a way that allowed access and decoding as root. I think demos of Hashicorp Vault at various conferences demonstrated this flaw. Since this flow fetches the external "truth" of a secret then persists it as an internal secret, is the secret any safer? It is safe from being compromised by source code management mixups but it is still not safe at run time. Or has Kubernetes fixed that flaw?
@kodecloud, this approach still fallbacks on creation of k8s secret where the sensitive data can be decoded. Is there any encryption that can be applied to be password and can be decrypted when used by the application ?
Hey, thank you for watching our video. We will definitely look into your suggestions. Do subscribe and stay tuned for updates on our channel. Cheers :)
🚀Explore Our Top Courses & Special Offers: kode.wiki/40SkWyU
This is best so far on ESO :) , stright to point , no drama :) loved it
Hello, thank you for watching our video. We are glad that you liked our video. Do subscribe and stay connected with us. Cheers :)
This tutorial was great. I set this up with Terraform and put a rotation on the key creation every 45 days, I never need to know this key and the namespace where it is stored is only accessible for cluster administrators. For anyone that wants to do a rotation with terraform use the time_rotating resource and rotation_days. use lifecycle for the key to create before destroy (AWS allows for 2 keys). Set up a null_resource to trigger on the UNIX time updating in the time_rotating. Then finally to retrigger use replace_triggered_by and set the reference to the null resource. this should make key replacement part of the plan/apply, you can test with rotation_minutes to make sure everything works and you get the correct key. Figured I share this since it took me a day to figure out.
Straight to the point. Thank you. No BS.
Glad you appreciated the direct approach! We believe in cutting through the noise to deliver value. Stay tuned for more straightforward content! 🚀
Nicely explained! Only rec would be to actually define what encoding is and why K8s does that by default (helps remove special characters and what not) vs. encrypting (uses a key to mathematically manipulate the secret value in such a way to make it impossible to read in plaintext without the key).
We can utilise EKS service accounts linked to AWS IAM roles to improve on security.
you save my job, the best one
Thanks for the detailed demo
Our pleasure!
Just in time when I need it. Nice snowboards 😊
Glad you like them!
Great video - thanks so much :)
Glad it was helpful!
Great stuff.. thanks KodeCloud
You're welcome!
pro tip: never use echo to encode or decode with base64, because the sensitive date is now in your shell history. Instead used cat and ctrl+d to finish input, like this: cat | base64 -d
Great content Sanjeev. One question, how do you manage AWS secrets manager rotation in that case?
This is best so far. Awesome tool, but how do we encrypt those secrets?
Great stuff! 🎉
Keep learning with us .Stay connected with our channel and team :) . Do subscribe the channel for more updates : )
Thank you so much.
good explanation! Thx
Glad it was helpful!
will this also work for cluster having fargate nodes as compute?
hey man great video but I was hoping to get some help on the external secrets operator, I have a full setup with infisical's provider(infisical is basically an open source and self hosted alternative to aws ss) but the problem is for some reason the external secrets operator does not create the managed secret, this is all running on eks cluster and I see no error logs both the secret store and external secrets crds tell me everything is synced and ready yet I see no managed secret being created, this same setup works on my local kind cluster no issues but not on eks
can be use identity provider odic with external secret operator ?
can be use IRSA serviceaccount with secretstore rather than adding qccess and sec key ?
Can we do this ? Because we cannot use accesskey and secret key
And also storing accesskey and secret key in that secret is also risky right
How does pushsecret works, can you please elaborate
Good demo of c the flow of this new middleman process. It solves the problem of defining credentials in YAML files that might become accidentally checked in to a source code repository. But it doesn't solve the other problem with using the internal secrets mechanism of Kubernetes. As of about 2022, there was still an inherent flaw with secrets within a K cluster in that the underlying data was physically persisted on disk on the main nodes in a way that allowed access and decoding as root. I think demos of Hashicorp Vault at various conferences demonstrated this flaw. Since this flow fetches the external "truth" of a secret then persists it as an internal secret, is the secret any safer? It is safe from being compromised by source code management mixups but it is still not safe at run time. Or has Kubernetes fixed that flaw?
I personally prefer the flow or akv2k8s on the azure side that also comes with an injector
@kodecloud, this approach
still fallbacks on creation of k8s secret where the sensitive data can be decoded. Is there any encryption that can be applied to be password and can be decrypted when used by the application ?
Can you prepare a full video with terraform IAC. I needed this very badly
Hey, thank you for watching our video. We will definitely look into your suggestions. Do subscribe and stay tuned for updates on our channel. Cheers :)
Kubeseal also good tool to overcome the describe challenges
Thank you so much : ) We are glad to be a part of your learning journey
Nice 👍
Keep learning with us .Stay connected with our channel and team :) . Do subscribe the channel for more updates : )