Skip to content

Conversation

kessplas
Copy link
Contributor

Issue #, if available: n/a

Description of changes: For many customers, it is not feasible to know the KMS Key ID associated with all of the objects the client instance should decrypt on GetObject. For example, the data may come from an external customer with more than one key encrypting many objects in a single bucket. This change adds a new keyring, KmsDiscoveryKeyring, which does not require the specification of a KMS Key ID during instantiation. The keyring will decrypt materials for whichever KMS key the ciphertext was encrypted with. This has slightly weaker security properties than the ordinary KMS keyring, but may be the only option for certain workloads.

Note that this keyring is very similar to the AWS KMS Discovery Keyring in the AWS Encryption SDK. However, the S3EC version DOES NOT support a DiscoveryFilter, as the KMS key ID is NOT persisted to the object metadata in v2/v3 KMS ciphertexts.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

  • Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.

@kessplas kessplas requested a review from a team as a code owner July 23, 2024 21:57
lucasmcdonald3
lucasmcdonald3 previously approved these changes Jul 24, 2024
Copy link
Contributor

@lucasmcdonald3 lucasmcdonald3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
I don't think I fully understand the "why" of the implementation but it seems reasonable. If you want to explain the "why", I'd suggest adding comments where I nit'ted, but since all the "why" is around internal implementation details, not required for merge.

}
}

// We are validating the encryption context to match S3EC V2 behavior
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Consider linking to said behavior

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the code is in another repo,
i will mention the class in question at least

decryptDataKeyStrategies.put(_kmsContextDiscoveryStrategy.keyProviderInfo(), _kmsContextDiscoveryStrategy);
}

private final DecryptDataKeyStrategy _kmsDiscoveryStrategy = new DecryptDataKeyStrategy() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Consider adding some words explaining each strategy; how are they different? Why is this one legacy?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure,
it maps to kms v1 and kms+context (v2/v3)

@kessplas kessplas merged commit 8d3c06a into main Jul 31, 2024
@kessplas kessplas deleted the kms-discovery branch July 31, 2024 20:23
josecorella pushed a commit that referenced this pull request Aug 20, 2024
## [3.2.0](v3.1.3...v3.2.0) (2024-08-20)

### Features

* add KMS Discovery Keyring ([#324](#324)) ([8d3c06a](8d3c06a))
* allow S3EncryptionClient and S3AsyncEncryption Client to be configured ([#328](#328)) ([11f25f6](11f25f6))

### Maintenance

* **deps-dev:** bump org.bouncycastle:bcprov-jdk18on ([#260](#260)) ([cd58967](cd58967))
* **deps:** bump software.amazon.awssdk.crt:aws-crt ([#303](#303)) ([cfe325e](cfe325e))
* update build scripts ([#341](#341)) ([8fa4266](8fa4266))
* Update Release CFN ([#343](#343)) ([81606b6](81606b6)), closes [#382](#382)
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

Successfully merging this pull request may close these issues.

2 participants