I'm actually not sure. I haven't used ArgoCD that much and definitely not with SOPS. I know FluxCD has native support for it though, as that's what I'm using.
You can decrypt all secrets with the old key, generate a new key to replace the old one and then re-encrypt everything. You can use the batch encrypt/decrypt scripts I show here to handle that more easily Though at that point I'd just rotate all secrets just to be safe.
I have a question, how should I be working with the encryption/decryption with more people involved? should I just give them the secret key? is it even recommended to use sops in a teamwork environment?
As always, it depends! You can use SOPS with other encryption backends, such as AWS KMS, GCP KMS or Azure Key Vault, which may or may not fit in with the tooling your team is already using. However, assuming you want to keep using AGE for the encryption backend, then one option would be to set up multiple recipients for encryption: github.com/FiloSottile/age/?tab=readme-ov-file#multiple-recipients > Every recipient will be able to decrypt the file. This means that everyone on the team can have their own encryption key, capable of decrypting the files. github.com/getsops/sops?tab=readme-ov-file#encrypting-using-age > You can encrypt a file for one or more age recipients (comma separated) using the --age option or the SOPS_AGE_RECIPIENTS environment variable. Furthermore, to increase security, you could set up a combination of the two, using key groups, such that more than one key is required to decrypt everything. Maybe everyone has an age key on their local machine and they also need KMS configured, or something like that.
Yeah, sops is rather picky about YAML formatting. I'm pretty sure it uses 4 spaces for indentation and does not support blank lines or comments. What you can do to check is to encrypt a file and then decrypt it to a new file to see the format. I handle this in my repo by using those 2 bash scripts and doing a sops encrypt followed by a force decrypt (overwrites the unencrypted file so that I have the right formatting)
Great video, I loved the progression from the foundations to the final setup with really good explanations of the how and why of each step! Thank you!
Glad it was helpful!
Good one. Also we can use git commit hooks to avoid accidental git commit and push. Thanks
Great explanation, but how can we integrate the existing set up with argocd so that it will look for secret.yaml in the helm manifest?
I'm actually not sure. I haven't used ArgoCD that much and definitely not with SOPS.
I know FluxCD has native support for it though, as that's what I'm using.
Very good video!
Thank you! I'm glad you found it useful
what if in the future my age key is leaked and i need to gen new key, how it is possible to update all secret?
You can decrypt all secrets with the old key, generate a new key to replace the old one and then re-encrypt everything.
You can use the batch encrypt/decrypt scripts I show here to handle that more easily
Though at that point I'd just rotate all secrets just to be safe.
I have a question, how should I be working with the encryption/decryption with more people involved? should I just give them the secret key? is it even recommended to use sops in a teamwork environment?
As always, it depends!
You can use SOPS with other encryption backends, such as AWS KMS, GCP KMS or Azure Key Vault, which may or may not fit in with the tooling your team is already using.
However, assuming you want to keep using AGE for the encryption backend, then one option would be to set up multiple recipients for encryption:
github.com/FiloSottile/age/?tab=readme-ov-file#multiple-recipients
> Every recipient will be able to decrypt the file.
This means that everyone on the team can have their own encryption key, capable of decrypting the files.
github.com/getsops/sops?tab=readme-ov-file#encrypting-using-age
> You can encrypt a file for one or more age recipients (comma separated) using the --age option or the SOPS_AGE_RECIPIENTS environment variable.
Furthermore, to increase security, you could set up a combination of the two, using key groups, such that more than one key is required to decrypt everything. Maybe everyone has an age key on their local machine and they also need KMS configured, or something like that.
@@mirceanton thanks a lot! i'll be giving it a try
how is formatted your secret.yaml?
seems that sops is a bit picky about its yaml
Yeah, sops is rather picky about YAML formatting. I'm pretty sure it uses 4 spaces for indentation and does not support blank lines or comments.
What you can do to check is to encrypt a file and then decrypt it to a new file to see the format.
I handle this in my repo by using those 2 bash scripts and doing a sops encrypt followed by a force decrypt (overwrites the unencrypted file so that I have the right formatting)