Hi Anton, As usual really great content. Kudos to you for putting such high quality content everytime. May be you can do playlist on central Logging solutions for k8s pods. Just a suggestion for future videos. Thanks again. Appreciate the effort you put behind these vidoes. 🎉
Awsome! Btw, i’m using Vault hosting on an EC2 for storing secrets recently. What ur opinion abt its downsides when compare to managed services? Beside having to manage it urself lol
Due to recent aws provider changes we can get rid of passwords for rds using manage_master_user_password attribute :) Databases for me was the last thing that required creating passwords. Everything else can be managed with iam roles without passwords/keys at all
great video especially the second part, Thanks in advance, Would you please explain after securing the secrets with the latest method, are we still have them as plain text on the state file or not? you didn't demo that part and the end of your video
Thank you! Yes, unfortunately, in the Terraform state, you'll find those secrets in plain text. It's a well-known issue that HashiCorp didn't want to resolve. They want everybody to migrate to Terraform Cloud. Now, after the fork "OpenTF," they immediately implemented encryption of those secrets. We may need to wait a few more weeks until they officially release it.
A very k8s-centric (i.e. the private key stays inside the cluster) method to encrypting secrets and being able to save them external to the cluster is via Bitnami's sealed secrets.
@@scottamolinari Sure, I've been using Sealed Secrets in production for the last 5 years and have never had any issues. The only exception was with GKE, where you need to open an additional port between the master and nodes to pull the public cert for encrypting your secrets, because it uses kubectl proxy.
What about the usage of random_password resource? Would you recommend to remove it? Or is there anyway to leverage random_password resource securely? I am in DigitalOcean so I do not have KMS or something alike at the moment.
It's not the most convenient option. Instead of managed SMs from public cloud providers you can use the vault as self hosted solution and get sensitive data to terraform using the same approach.
Definitely just for testing 😛 I did deployed Vault but I have a cyclical dependency since I use terraform to deploy Vault so at some point in the infra I don’t have Vault available 🥲
Great video. I would like to know why pass doesn't pops up again to enter the passphrase (to retrieve the password ) once we have got the password. So, every time we need the password, it should ask for the passphrase everytime
is there a way to extract credentials from azure vault and run terraform and pass these values to azure pipeline solutions..I m looking for similar solution in azure around service principle
Am I understanding correctly that the combination of sops+kms is not the best choice because the password is stored in the state? So, from the perspective of GIT + CI/CD, it's beautiful and protected, but the state itself contains passwords and tokens.
Whatever option you choose, secrets will also be stored in plain text in the Terraform state. In my opinion, cloud-managed services (secrets managers) are more convenient in the long run than SOPs, etc.
Well, 90% of the software engineers in the Bay Area use MacOS, mostly because companies provide it. Some startups use Linux, but to be compliant, I guess they force us to use Mac.
