getsops / sops

Simple and flexible tool for managing secrets
https://getsops.io/
Mozilla Public License 2.0
16.32k stars 858 forks source link

implement a sops --verify #437

Open ChristianWeissCG opened 5 years ago

ChristianWeissCG commented 5 years ago

This ticket here continous the descussion from: https://github.com/mozilla/sops/issues/52 Please see #52 for more background.

... As the MAC is a build-in feature that is maintained on all sops-operations i would prefer to use that MAC instead of adding a further step (sign the complete file with GPG) to the "change" workflow. A MAC is calculated only on encrypted values / encrypted comments. Changes to plain text key/values ("_unencrypted") do not bother the MAC / will not make that MAC invalid, but it would break a GPG full-file signature.

You can also use symetic secrets to sign, but in that case the build server would need your "privates" (in case of AWS KMS your credentials: access key ID and secret access key) - which would enable it to validate signatures but also to encrypt and decrypt. And it would not add a benefit compared to current MAC. When only symetic keys are available (AWS, Azure, GCP) then --verify should use the encrypted MAC from file.yaml/sops/mac. If someone want his buildserver or git hook to verify that a sops-encrypted file is correct he needs to provide credentials to that system - i would never do that, but sops should provide that option.

I personally would use GPG (asymetric) for signing instead, to avoid having "privates" on the buildserver. Sops is not enforcing the use of GPG but it somehow recommends or at least advertises to use GPG for desaster recovery. And it should advertise it for signing, too.

We are using sops with GPG only (no AWS, Google, Microsoft), so it feels natural to use a GPG signature. If you are using more then GPG keys then on a change all available keys (GPG and e.g. AWS KMS) should be used to sign the MAC. Plain MAC should be saved in file.yam/sops/mac_plain and signatures below file.yaml/sops/mac_plain_signatures. If e.g. AWS KMS and GPG are available then create signatures with both, and let the buildserver (or its administrator, based on defined trust) decide which key(s) to use on verification --verify). The --verify option should exit with exit code 0 (no message) if file could be validated with at least one signature.

mitar commented 2 years ago

A MAC is calculated only on encrypted values / encrypted comments. Changes to plain text key/values ("_unencrypted") do not bother the MAC / will not make that MAC invalid, but it would break a GPG full-file signature.

That is not true. Currently MAC is computed over all values, encrypted and unencrypted. It is not computed over comments at all. I made #972 to track making it be computed only over encrypted values.

cesarjorgemartinez commented 1 year ago

Hi,

I find this issue and other that can be related: https://github.com/getsops/sops/pull/545 (add filestatus command)

I am looking for both ways, as a minimal example (at least for check encrypted files):

sops --check filename echo $? 0 -> Sops encripted file and valid 1 -> Not a Sops encrypted file 2 -> Sops encrypted file and no valid

Can be checked also decrypted files, also. 0 -> Sops decripted file and valid 1 -> Not a Sops decrypted file 2 -> Sops decrypted file and no valid

Antik9421 commented 2 months ago

I'm also looking for a way to check an encrypted sops file without a key

boris-smidt-klarrio commented 2 months ago

This would really be a good CI feature it would allow us to detect manual tampering with secrets without re encrypting the file. For example when somebody changes a field in a kubernetes 'secret'.