Open Leekao opened 6 months ago
SOPS generally preserves the YAML key order, appends the sops
key at the bottom of the first YAML document, and uses its internal order when serializing the value of the sops
key. If you prefer keys to be ordered alphabetically, you need to postprocess the SOPS encrypted file with another tool to achieve this.
SOPS generally preserves the YAML key order, appends the
sops
key at the bottom of the first YAML document, and uses its internal order when serializing the value of thesops
key. If you prefer keys to be ordered alphabetically, you need to postprocess the SOPS encrypted file with another tool to achieve this.
But even Inside the "sops:" part the elements are not arranged alphabetically, kms appears before age or azure_kv, can you explain this behaviour? I perosnally think SOPS should provide the option to arrange elements to be the same as they are in K8S, this is a K8S tool and this small ordering change will much improve the developer experience.
I did:
and uses its internal order when serializing the value of the
sops
key
The internal ordering is not alphabetical.
Also: SOPS is not a K8S tool.
I'm sorry for the misunderstanding, I understand that the internal order is not alphabetical what I meant to to ask was "why must it be like this?", is the change I'm requesting harmful to the process somehow? as a user of SOPS I would like it very much and it does not seem like a big hassle, what am I missing?
It doesn't have to be like this for the sops
key. But note that any change will lead to unnecessary git history changes anytime someone updates an already SOPS encrypted file. That's why changing the order is a bad idea, if there isn't an important reason.
I guess we could make it configurable, but that's something that needs to be implemented first. (It's also not that trivial since YAML keys don't have to be strings. So you need a total order that covers all possible key types.)
I would have thought that having a fully symmetrical process would be a good solid reason, am I the only one who finds great value in being able to read the decrypted value straight from the K8S cluster without needing the original encrypted file that was applied?
I guess you aren't the only one, but don't forget about non-K8S users which do not sort their YAML files alphabetically.
I fail to see how non-K8S users would suffer from this change, all I see is benefit, maybe I'm missing something.
When creating encrypted yaml the elements in the yaml created are not ordered alphabetically, so "spec" appears before "sops" and "gcp_kms" appears before "age". When retrieving SopsSecret from K8S as yaml elements always ordered alphabetically. So, if I encrypt a secret, apply the encrypted yaml to cluster, get it back from cluster via "kubectl get -o yaml", sanitise the yaml from from unwanted tags and try to decrypt it I will receive a MAC mismatch.