szlta commented on code in PR #13225:
URL: https://github.com/apache/iceberg/pull/13225#discussion_r2478043016
##########
core/src/main/java/org/apache/iceberg/rest/RESTTableOperations.java:
##########
@@ -166,7 +208,67 @@ public void commit(TableMetadata base, TableMetadata
metadata) {
@Override
public FileIO io() {
- return io;
+ if (encryptionKeyId == null) {
+ return io;
+ }
+
+ if (encryptingFileIO == null) {
+ encryptingFileIO = EncryptingFileIO.combine(io, encryption());
+ }
+
+ return encryptingFileIO;
+ }
+
+ @Override
+ public EncryptionManager encryption() {
+ if (encryptionManager != null) {
+ return encryptionManager;
+ }
+
+ if (encryptionKeyId != null) {
+ if (kmsClient == null) {
+ throw new RuntimeException(
+ "Cant create encryption manager, because key management client is
not set");
+ }
+
+ Map<String, String> tableProperties = Maps.newHashMap();
+ tableProperties.put(TableProperties.ENCRYPTION_TABLE_KEY,
encryptionKeyId);
+ tableProperties.put(
+ TableProperties.ENCRYPTION_DEK_LENGTH,
String.valueOf(encryptionDekLength));
+ encryptionManager =
+ EncryptionUtil.createEncryptionManager(
+ encryptedKeysFromMetadata, tableProperties, kmsClient);
+ } else {
+ return PlaintextEncryptionManager.instance();
+ }
+
+ return encryptionManager;
+ }
+
+ private void encryptionPropsFromMetadata(TableMetadata metadata) {
Review Comment:
I guess there could be a way to replace it, but it's not what I meant.
What I mean is, on the client, `RESTTableOperations` can only work with
things coming from the remote catalog side, right? And currently all that is
just the result of the `loadTable()` call, aka `LoadTableResponse`. So it's the
server side that has to make sure that in its answer it injects encryption
properties that were not tampered with.
How can a client trust that the server was not just reading a
`metadata.json` (which may have been modified by a bad actor) but rather
populated the encryption properties from its backend DB or any other way it
tracks table metadata internally? I guess it can't.
Perhaps if there was a separate endpoint in the REST API spec just for
encryption properties, it could serve as singal for server implementors to
handle these properties differently, but it's still no a guarantee for the
properties to be populated from a `metadata.json`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
