Kubernetes Secrets Management with ESO | Kubernetes Tutorial

Kubernetes Secrets Management with ESO | Kubernetes Tutorial | KodeKloud

Рет қаралды 13,191

KodeKloud

Күн бұрын

Пікірлер: 42

@KodeKloud Ай бұрын

🚀Explore Our Top Courses & Special Offers: kode.wiki/40SkWyU

@hyderabadperlmongers3654 10 ай бұрын

This is best so far on ESO :) , stright to point , no drama :) loved it

@KodeKloud 8 ай бұрын

Hello, thank you for watching our video. We are glad that you liked our video. Do subscribe and stay connected with us. Cheers :)

@AnteMijaljevic 8 ай бұрын

Straight to the point. Thank you. No BS.

@KodeKloud 8 ай бұрын

Glad you appreciated the direct approach! We believe in cutting through the noise to deliver value. Stay tuned for more straightforward content! 🚀

@Oxxygen_io Ай бұрын

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.

@ganges6661 5 ай бұрын

We can utilise EKS service accounts linked to AWS IAM roles to improve on security.

@GrahamSchuckman 2 ай бұрын

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

@Pyrusmalus 10 ай бұрын

Thanks for the detailed demo

@KodeKloud 10 ай бұрын

Our pleasure!

@achala1100 5 ай бұрын

you save my job, the best one

@mohammedbanabila8515 11 ай бұрын

can be use identity provider odic with external secret operator ?

@mohammedbanabila8515 11 ай бұрын

can be use IRSA serviceaccount with secretstore rather than adding qccess and sec key ?

@yogithakakarla1716 9 ай бұрын

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

@rajenderprasad1193 11 ай бұрын

Great stuff.. thanks KodeCloud

@KodeKloud 10 ай бұрын

You're welcome!

@thiagoscodeler5152 5 ай бұрын

Great content Sanjeev. One question, how do you manage AWS secrets manager rotation in that case?

@peterjakubik 11 ай бұрын

Just in time when I need it. Nice snowboards 😊

@KodeKloud 10 ай бұрын

Glad you like them!

@prashanthrebel4875 4 ай бұрын

Thank you so much.

@MadhvendraDixit 3 ай бұрын

will this also work for cluster having fargate nodes as compute?

@salborough2 9 ай бұрын

Great video - thanks so much :)

@KodeKloud 8 ай бұрын

Glad it was helpful!

@sriramramesh8203 4 ай бұрын

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

@stratfanstl 11 ай бұрын

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?

@donalddev-fp3ym 10 ай бұрын

I personally prefer the flow or akv2k8s on the azure side that also comes with an injector

@vikas5221 6 ай бұрын

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

@rajrehan2710 9 ай бұрын

This is best so far. Awesome tool, but how do we encrypt those secrets?

@iga3725 9 ай бұрын

good explanation! Thx

@KodeKloud 8 ай бұрын

Glad it was helpful!

@premierde 2 ай бұрын

How does pushsecret works, can you please elaborate

@francoisscala417 4 ай бұрын

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

@vpatanjali 10 ай бұрын

Can you prepare a full video with terraform IAC. I needed this very badly

@KodeKloud 10 ай бұрын

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 :)