Is AWS KMS automatic key rotation compatible with SOPS?

[andrewtcymmer]

Hello, I have been searching around the internet for an answer to my question, but have not found a clear answer. So I would like to pose it here, and also ask for an update to your documentation/readme with the answer.

My question is: Can SOPS be used with AWS KMS keys that have automatic rotation turned on? (See AWS docs)

This is the scenario I am concerned about: after the cryptographic material rotates on the AWS side, any files encrypted with SOPS prior to the rotation had different private material, and therefore the decryption will not produce the same results. Despite what AWS says in its documentation about keeping all previous crypto materials on their side, the documentation subtly implies that it works only with other AWS products. My reasoning here (which may be incorrect) is, that the AWS API likely only uses the current crypto material with external callers of the API. Something I am not clear on, is that the CLI spec for kms decrypt indicates that the ciphertext contains some data that specifies the key id used, but it does not mention if the version of cryptographic material is encoded into it also.

Motivating this question is the fact that my team is using AWS SecurityHub and implementing the guidelines. One of which is that every custom KMS key needs to have automatic rotation turned on. While we could manually rotate keys (either via SOPS -r option, or through the AWS console), the point is for us to be compliant according to the SecurityHub rules. For reference: CIS.2.8 and PCI.KMS.1, and CMK backing key rotation rule in AWS Config.

Thanks, and do let me know if I may clarify anything.

[ChenTsungYu]

+1 I have the same concern.

[Rvanmech]

@andrewtcymmer Disclaimer: I am new to SOPS, but if my understanding is correct, there is no way for this to be done automatically for existing files that have been encrypted using SOPS and been committed in source control. The only way that you could rotate a key without a chance of breaking downstream usage of the secret is to decrypt them locally, rotate the key in AWS, then encrypt them with the new key and commit your now encrypted config file back to the repo, and then release downstream code to have the updated config file. That process seems to be quite involved for it to be available as feature of SOPS or AWS. If I am reading the documentation for AWS correctly, then it appears you would have to rotate these managed keys manually every year before they were automatically rotated in AWS KMS, or use customer-managed keys that do not rotate automatically: "Existing AWS managed keys are automatically rotated one year after their most recent rotation, and every year thereafter." https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

[andrewtcymmer]

Thank you @Rvanmech . Your comments confirm what I was thinking. I am prioritizing reliability as part of our response to SecurityHub findings, which means granting suppressions for specific keys dedicated to SOPS use. It would still be good to get an official recommendation printed in the SOPS docs, warning about possible loss of decryptability when automatic rotation is turned on.

[yogeek]

Hello, same question here : security compliance made us enable KMS automatic rotation and we would like to understand the impacts. Is there a maintainer that could confirm the assumptions above please ?

[wgurney]

Hi, same question as Security Hub failed on this check for my SOPS MKS key.

I did however find the following: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

When you enable automatic key rotation for a KMS key, AWS KMS generates new cryptographic material for the KMS key every year. AWS KMS saves all previous versions of the cryptographic material in perpetuity so you can decrypt any data encrypted with that KMS key. AWS KMS does not delete any rotated key material until you delete the KMS key.

I could not confirm this as there is no way to rotate the key now. But as mentioned previous versions are saved for decryption purposes until deletion.

[ghost]

TL;DR: auto-rotating your KMS keys DOES NOT prevent you from decrypting your secrets.

@wgurney You've actually answered this question. Since AWS KMS keeps the old key material available for decryption, it is completely opaque to SOPS.

This behavior has a very practical reason: consider data is encrypted in an S3 bucket with a KMS key that is periodically rotating. As time goes by and more and more data flows into the S3 bucket (e.g. data uploaded by users, other systems, ...), it would be an absolute burden if AWS had to re-encrypt all contents with the new key material after rotation. Apart from the processing overhead, it would also be an actual loophole in the security design, since it would mean that there is some infrastructure not controlled by the customer that is able to decrypt all your data.

While the latter is still not 100% guaranteed in any environment that you don't control yourself (whenever you use server-generated key material), the way it works right now at least allows for much tighter security inside the cloud providers infrastructure (which in turn is required for certifications).

On another side note: auto-rotating the KMS key for configuration data only enhances security if you also rotate the configured secrets more often than the key rotation interval. E.g. rotating the encryption of the exact same 5-years-old DBA password does not help at all.

This is different for (user-)generated data, since upon every modification it will automatically use the new key material and only old data will have a chance of being leaked (for all data that have been last updated within the respective time period, not before and not after). E.g. for things like logs we usually have a retention period as well, further reducing the validity of a leaked old key material.