Excellent demo! Can KubeSeal be installed on a local machine and pass the public key (cert) to it (if yes, how?), or should it be installed inside the cluster?
@@nlflint The kubeseal cli can reach the cluster to get the secret sealed. The point I was trying to make is how his dev container was able to communicate with the cluster in the first place. It's quite easy to miss the net flag and you'd be left wondering why it isn't working.
I love how clearly you articulate yourself. Soaking up these tutorials like a sponge. Defo some of the best DevOps tutorials I've seen on YT yet. Ultimately saving one precious time. Thanks bud.
Thank you for the well explained video! How to manage encryption keys? do admins need to worry about them and establish a process for them? specially if you have thousands of applications deployed
Great video. What we did is encrypt our secrets with mozilla sops and store this in git. The keys for encryption came out of azure vault only accessible by the devops engineers. We decrypted it in our pipeline when deploying to kubernetes.
I love learning about k8s, and this is one of those channels that always makes difficult concepts easy to understand. And now I'm going to be that guy that makes a suggestion for a video that you've already done because he didn't take time to search before asking: The machine has recently fed me videos about sealed secrets and videos about the external secrets thing. I haven't quite groked the relationship between the two.
Most orgs don’t want any kind of dev to know production keys/passwords. It’s just good OPSEC, so gotta keep plain text keys outta source control. This affects finance company especially, ala Sarbanes-Oxley controls (SOX).
@@nlflint Deploying via SSH, for devs who need to be stupid about real secrets, is no less secure than your proposal. Also, there are simple programmatic techniques one could use for "secrets" where nobody has access to the "secrets" other than the code itself.
No, it's a real encryption and not a coding (base64). It uses a master key inside cluster that unseals (decrypt) the sealed secret and creates a normal kubernetes secret. All done via an operator running in the cluster. So, looking at the git you cannot see the clean secret.
The SealedSecret is properly encrypted. However, once it’s converted to a secret, immediately after deployment, the newly created Secret is still just Base64. I always wonder why k8s calls it a Secret when’s it not encrypted. They’re unencrypted at rest, not usually a good thing.
@@nlflint implementation wise there is not a huge difference. The big difference is when using RBAC properly to limit access to Secrets but allow access to ConfigMaps. You would probably need to prevent shell access to pods as well. This is critical if you are using SOPS, Sealed Secrets, cert-manager, 1Password Operator or other service that adds secrets to the cluster for pods to consume.
Dude, here's a tip, raise your camera a bit. Your back will thank you.
Excellent demo!
Can KubeSeal be installed on a local machine and pass the public key (cert) to it (if yes, how?), or should it be installed inside the cluster?
For anyone wondering, the net flag is how you get you docker container to communicate with your cluster
I was puzzled how kubeseal got the encryption key... So you’re saying when I run the CLI it reaches out to the cluster for the latest key?
@@nlflint The kubeseal cli can reach the cluster to get the secret sealed. The point I was trying to make is how his dev container was able to communicate with the cluster in the first place. It's quite easy to miss the net flag and you'd be left wondering why it isn't working.
Thank you! I’ll soon give this a go on my dev fluxcd cluster.
Awesome video thanks Marcel :)
better solution imo:
helm secrets
I love how clearly you articulate yourself. Soaking up these tutorials like a sponge. Defo some of the best DevOps tutorials I've seen on YT yet. Ultimately saving one precious time. Thanks bud.
The best explanation of the sealed-secrets I have ever met. Thank you!
woooooow Thank you for your excellent explanation
Thank you so much
Great video. When are you making video about pulumi ?. Please make video about pulumi.
Its on my list 💪🏽
As always great stuff! I wanted a way to use git with my secrets instead of a vault to have options.
Great material! Many thanks for your work!
Great guy full of great stuff. 🤩
Thank you for the well explained video! How to manage encryption keys? do admins need to worry about them and establish a process for them? specially if you have thousands of applications deployed
What about storing secrets as GitHub secrets and using GitHub Actions pipelines for DevOps? Is that possible?
Unfortunately besides K8s there are underlying infrastructure who uses secrets heavily. I mean, i was looking for something more generic and unified.
Thanks a lot boss.
What another greate video from Mr Dempers, a highly skilled Solution Architect acts as a DevOps propagandist.
Great video. What we did is encrypt our secrets with mozilla sops and store this in git. The keys for encryption came out of azure vault only accessible by the devops engineers. We decrypted it in our pipeline when deploying to kubernetes.
I love learning about k8s, and this is one of those channels that always makes difficult concepts easy to understand.
And now I'm going to be that guy that makes a suggestion for a video that you've already done because he didn't take time to search before asking: The machine has recently fed me videos about sealed secrets and videos about the external secrets thing. I haven't quite groked the relationship between the two.
Great content, explanation is very nice. Thanks !!
Awesome explanation 👏👏
Why don’t you just store the secret as a secret yaml to the cluster?
With GitOps, manifests go in GIT.
Why not simply deploy manifests via ssh? From private git repos. Secure delivery. No need to store secrets.
Most orgs don’t want any kind of dev to know production keys/passwords. It’s just good OPSEC, so gotta keep plain text keys outta source control. This affects finance company especially, ala Sarbanes-Oxley controls (SOX).
@@nlflint Deploying via SSH, for devs who need to be stupid about real secrets, is no less secure than your proposal. Also, there are simple programmatic techniques one could use for "secrets" where nobody has access to the "secrets" other than the code itself.
Is it a base64 of the original secret ?
No, it's a real encryption and not a coding (base64).
It uses a master key inside cluster that unseals (decrypt) the sealed secret and creates a normal kubernetes secret. All done via an operator running in the cluster. So, looking at the git you cannot see the clean secret.
@@SightsToKeepInSight awesome
The SealedSecret is properly encrypted. However, once it’s converted to a secret, immediately after deployment, the newly created Secret is still just Base64.
I always wonder why k8s calls it a Secret when’s it not encrypted. They’re unencrypted at rest, not usually a good thing.
@@nlflint implementation wise there is not a huge difference. The big difference is when using RBAC properly to limit access to Secrets but allow access to ConfigMaps. You would probably need to prevent shell access to pods as well. This is critical if you are using SOPS, Sealed Secrets, cert-manager, 1Password Operator or other service that adds secrets to the cluster for pods to consume.