datasets fail when Glue catalog is encrypted with KMS CMK

[zsaltys]

If glue metadata is encrypted with a KMS CMK then data.all pivot role will not have access to glue and import or share creation will fail (if encryption is enabled after glue catalog import). data.all could probably detect that glue is encrypted with a KMS CMK and provide a link how to update the KMS CMK with the pivotRole so that failing imports or failing shares could be fixed. We could also just advise that KMS CMK is not supported and managed keys should be used. I personally don't see a reason why glue metadata should be encrypted with KMS CMK but it's supported nonetheless and some users ended up doing it in our organization.

[zsaltys]

I noticed that this gets even more confusing when importing a glue db which is encrypted with KMS CMK - this causes the CF custom resource to throw an exception on GetDatabase and then it assumes that the database does not exist and attempts to create it which also fails because the database already exists.

[dlpzx]

Hi @zsaltys thanks for opening an issue. Independently from supporting the use-case or not, we need to clarify users what is allowed and what are current limitations. In this case encrypting the Glue Catalog with CMK keys is not supported and users should be aware. That is step number 1, then, the other question is, should we support CMK-encrypted Glue Catalogs? We need to understand the reasons that the users have to go for this pattern and the implications and value-added of implementing the feature.

Here is a quick assessment of what would be needed:

• Modify pivot role permissions and grant permissions to the CMK key
  - Add IAM permissions to CDK roles to getGlueCatalog settings
  - Modify Pivot Role CDK stack to add IAM permissions to CMK stack
• Modify any role that accesses or writes to an encrypted catalog—that is, any role, crawler, job—needs the following permissions. (as they explain in the docs) ---> this part is a bit more difficult
  - Modify IAM roles created by data.all (dataset roles, environment team roles)
  - Add extra permissions to consumption roles?

It would be great to have the feedback of the affected users, so that we implement what they really need.