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
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 :)
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 ?
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
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 :)
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! 🚀
We can utilise EKS service accounts linked to AWS IAM roles to improve on security.
Thank you so much.
Great content Sanjeev. One question, how do you manage AWS secrets manager rotation in that case?
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 stuff.. thanks KodeCloud
You're welcome!
Great video - thanks so much :)
Glad it was helpful!
This is best so far. Awesome tool, but how do we encrypt those secrets?
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 explanation! Thx
Glad it was helpful!
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
Great stuff! 🎉
Keep learning with us .Stay connected with our channel and team :) . Do subscribe the channel for more updates : )
can be use identity provider odic with external secret operator ?
Kubeseal also good tool to overcome the describe challenges
Thank you so much : ) We are glad to be a part of your learning journey
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 :)
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 ?
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
Nice 👍
Keep learning with us .Stay connected with our channel and team :) . Do subscribe the channel for more updates : )