 Hello, hello. Yeah. So yeah, let's introduce ourselves. I'm Nikita Kuzilev. I'm a solution architect from Arcadia. And I'm Daniel Hong. I'm a developer advocate at Arcadia. Okay. Initially it's supposed to be a 40 minutes talk with a demo Q&A and detailed explanation of each talk but we only have 10 minutes. We only have 10 minutes? So okay, now at the water we just squish all the 15 slides into one. Yeah. Here it is. We did, we strategically had Nikita talking too because he talks faster than me. So let's hop into it. So the conclusion of our talk is use external secrets operator and don't forget about password authentication. It is important. This solution covers like most of the use cases. It's reliable, fancy, secure. So this is our talk. Thank you very much. Yeah, like, subscribe, and follow Daniel off his Twitter. Wait, wait, Nikita, it feels kind of wrong to just hop to a conclusion without, you know, talking about all the potential solutions that we can use for secrets managers. And we still have quite a few, a lot of time left. So let's, I think we should explain it a little bit. Okay, I mean, let's go fast, fast space. So first solution, seal secrets, two parts. First part, keep seal common tool. You encrypt your secrets with common tool. And second part is seal secret controller. Your decrypt stuff is a seal secret controller. That's basically it. That's not rocket science. You encrypt there, decrypt here. So it uses custom resources. So you need to install CRG in your cluster. And yeah, if we had time, we could talk about the chicken egg problem and why you need a password to access your other passwords and where to keep the password. We also could talk about decryption key league. So if you key, somehow it's compromised basically. All your secrets compromised too. And you wouldn't even know about this. So. Yeah, but we don't have that much time. So I think a good conclusion for seal secrets is that it's a great tool for quick starts or POCs. However, if you're considering it for like enterprise and production use cases, it might not scale as well. Okay, let's go next tool. Next tool is Argus Yabong plugin is different. Instead of encrypting your secrets, it requires some external secret storage. And initially it was HashiCorp vault, but later they added support for other cloud providers. So everything happens in Argus CG name space. When Argus CG renders your manifest, this plugin replaces some placeholders in your files with a secret one list. And like arguably it's not real GitOps because what you have in Git and what you have in the environment is not the same. And also it works only with Argus CG. If you try QCT, it wouldn't work the same way. Yeah, what's a flaw with this? Oh yeah, I forgot. Like it's not, maybe it's not a bug, it's a feature. Your application one can easily get application two secrets. So yeah, if you trust on your developers, you can use it. But I don't know, if... Yeah, so I think a good conclusion is that, you know, it supports a lot of secret managers. However, it has that flaw. You can't really scope that down to specific pieces. So it's in our opinion, not a great choice for enterprise use cases unless you can trust all of your developers, which do we do that? Okay, let's go on next. So solves secret operations. It's kind of a combination of two previous stones. You encrypt secrets with a common line tool and you decrypt secrets with Argus CG plugin. So it has weaknesses from both previous stones. It's kind of solve the chicken egg problem with key store. And key stores are different from secrets managers, so let's not confuse them with each other. Yeah, key store is not the same as secret manager, unless it's Azure, in Azure it's the same, but in other products it's not the same. Whatever. So it has so many issues actually. We don't have time to discuss everything. Same issue with application one, accession application two secrets. Issue with leaked keys. So all your secrets are compromised. Yeah, I mean, what's the concept? Yeah, yeah, we can move past that. We don't have time for that. But the gist here is that it's still quite popular tool because for legacy reasons typically, like a lot of people are just stuck using key stores. Secrets managers are a lot more flexible and it's more the path towards the future. So that's, you know, it's also a lot of use cases where it's just hard to justify like moving to a new tool. Let's go next. So next is a vault agent injector. So it doesn't use any of the Kubernetes fancy stuff, it just good old vault agent process injected in each of your port. And if you're familiar with vault agent, you know that it connects to vault server and updates your files in the local file system. So does that mean if you have a thousand pods, you would need a thousand additional processes running and making connections? Yeah, I mean, yeah, if you have a thousand pods and a thousand connections, your server actually might not like it. And if your server is down, basically all your pods cannot start. So it's one of the... If we had time, we could talk about that particular, very specific use case where it actually makes sense to use this solution. But yeah, I think the conclusion here is, you know, you might run into a lot of scalability issues based on how this method works. And typically, if you're considering using this, you're probably already using vaults. And if you're not, you're probably already considering other solutions to begin with. Okay, secret source CSI. I forgot what CSI stands for. Contain your storage interface, right? That's right. Okay. So it's a special type of a driver. It mounts, it runs on the port creation. So when your port is created, this driver mounts files into your port. And optionally can create a secret, Kubernetes is a secret, but it's a storage driver. So it only works with storage. So it doesn't seem to have that problem when application one can access application two secrets because it uses secret provider class and you can specify different secret provider classes. If we had time, we could talk about why it's a demo set and unlike all other solutions, but I mean, we don't have time, right? Yeah, I think it's a valid solution if you don't want to use Kubernetes secrets and you just want to mount files directly to your file system. Oh, okay. And last, but not least, external secrets operator. Okay, what do we have about external secrets? It doesn't seem to have all of these issues from other tools that we didn't have time to talk about. It uses custom resources, just like sealed secrets, but in this custom resources, you keep coordinates of your secrets and it can use different secret stores. So it doesn't have this application one accession application two secrets. You can create different account for every application and different roles. If we had time, we can talk about templating your secrets. We could talk about updating your secrets and why sometimes you need to restart your port and sometimes it's not required. It's very easy to set the tools. Yeah, and it's really comprehensible and easy to set up. I set up literally in seconds. Yeah, I think in conclusion, this is, based on our research, it's an easy way to get started. It's easy to get up and started. And then it also scales very well. So it's very great for enterprise use cases. So the conclusion stays the same. Yeah, thank you so much. Check out our booth, like our YouTube booth, down on the first floor, right? Yeah, that's right. You can check out our booth. We're gonna be at KubeCon on the main conference days as well. And you can bother Nikita for any specific secrets questions. All right, yeah, I think that's it. All right, thank you.