Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elements in encrypted yaml are not ordered alphabetically #1445

Open
Leekao opened this issue Feb 22, 2024 · 8 comments
Open

Elements in encrypted yaml are not ordered alphabetically #1445

Leekao opened this issue Feb 22, 2024 · 8 comments

Comments

@Leekao
Copy link

Leekao commented Feb 22, 2024

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.

@felixfontein
Copy link
Contributor

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.

@Leekao
Copy link
Author

Leekao commented Feb 25, 2024

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.

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.

@felixfontein
Copy link
Contributor

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.

@Leekao
Copy link
Author

Leekao commented Feb 25, 2024

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?

@felixfontein
Copy link
Contributor

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.)

@Leekao
Copy link
Author

Leekao commented Feb 26, 2024

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?

@felixfontein
Copy link
Contributor

I guess you aren't the only one, but don't forget about non-K8S users which do not sort their YAML files alphabetically.

@Leekao
Copy link
Author

Leekao commented Mar 11, 2024

I fail to see how non-K8S users would suffer from this change, all I see is benefit, maybe I'm missing something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants