adnanhemani commented on PR #1424: URL: https://github.com/apache/polaris/pull/1424#issuecomment-2837090450
> The threat here is that the vended credentials are used outside of the scope of accessing the data in this table. There's nothing preventing a malicious user from using these credentials to call KMS to decrypt any key defined for any file elsewhere in S3. Or non-S3 resources entirely. I'm not sure I agree here, @collado-mike. What does prevent a malicious user from doing these things is the fact that the STS credentials are already pre-scoped to the set of S3 prefixes that Polaris sets when generating the credentials. Malicious users are unable to cross over permission sets from different STS sessions to do actions spanning different actions, at least with regards to SSE. And to make sure we are on the same page, AWS does not allow combining IAM permissions from multiple sessions. If you are implying that Polaris is unable to scope S3 resources to a granular-enough scale (say, it is unable to scope S3 permissions to a table-level) - then I'd say that's a massive issue that needs to be addressed outside of KMS support, but my quick reading of the code does not support this implication. ---- To make this concrete, let me state an example: * A malicious user has access to credentials for an IAM session that has the following policies: [allow on "s3://a/b/c/d/" with actions "s3:GetObject", allow on "*" with actions "kms:Decrypt"]. * This malicious user also has access to a different set of credentials for an IAM session that has the policy: [allow on "s3://*"]. Say that all objects in S3 are encrypted with SSE-KMS with KMS key `k1`. It would not be possible for this malicious user to access any S3 file outside of prefix "s3://a/b/c/d/" with just these two sets of credentials - S3 would not allow them to download any object (even in an encrypted form) using the second set of credentials due to the way that SSE-KMS and SSE-S3 work (which will require the same session to have the `kms:Decrypt` action; S3 will not let a request succeed for an object that is encrypted with SSE-KMS/S3 but KMS permissions do not exist within this IAM session). If you disagree, please do share a concrete example that shows an active vulnerability. --- If my above statements are true, then I think we have landed on something similar earlier to what you are now recommending: is there a security use case for different KMS keys being used to encrypt files within the same table/S3 prefix and customers today? How does a user make Polaris aware of the different KMS keys in such a use case? > The way I propose to model this is to explicitly assign a KMS master key to each table Is this something that is already supported in Iceberg? I did not find this - or is the intention for Polaris to manage this KMS master key on behalf of the customer? If so, what is Polaris' story regarding tables that are being imported into Polaris after being created? -- 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]
