Disassociate of Resource Share fails when trying to revoke permission on Glue Tables for Cross Account Sharing

[degoldner]

Describe the bug

When we revoke the permissions on already approved Glue tables for cross cccount sharing the revoke processor executes succesfully but in the AWS console the RAM Resource Share shows that the disassociation of the Glue table failed.

How to Reproduce

• Create cross account share request for Glue table
• Approve share request
• Revoke share request
• Check AWS console of data producer for RAM Resource Shares to find disassociation error

Expected behavior

The revoke processor of data.all should correctly handle the API calls for revokation of the permissions and reflect if there is an error.

The revoke step should not lead to an error regarding dissociation of the resource share.

Your project

No response

Screenshots

No response

OS

AWS deployment

Python version

3.7

AWS data.all version

v1.2.0

Additional context

I also checked our permission set and we had already the ram:DisassociateResourceShare included.

Upon looking into the documentation for Lakeformation cross account sharing https://docs.aws.amazon.com/lake-formation/latest/dg/cross-account-prereqs.html I found that the managed policy AWSLakeFormationCrossAccountManager should give all required permissions.

I added that policy and now the issue is resolved.

[dlpzx]

Hi @degoldner, thank you for raising this issue :) To summarize the TODOs from this issue, we need to:

• cross check the pivotRole permissions against the AWSLakeFormationCrossAccountManager and add any missing permission.
• review the error handling to reflect this error to understand why it treated it as a success

[degoldner]

@dlpzx, and optionally we could discuss whether we should switch for using managed AWS policies where possible?

[dlpzx]

One question, @degoldner are you using the latest version of sharing? or are you using v1.2?

[chamcca]

In response to switching to AWS Managed Policies: this is something we generally avoid. Where possible we try to enforce least privilege policies, but many AWS managed policies do not restrict resource scope. This can result in Roles with access permissions they do not require. In addition, managed policies can be update over time. This doesn't occur often, but the drift can cause unexpected problems when the permissions change. For consistency, auditing, and fine grained access control we should continue to define least privilege policies and avoid managed policies.

[degoldner]

@dlpzx, I would say we are using v1.4.0 regarding the share manager implementation, though we are a bit behind regarding the revokeItems implementation, we are still using revokeAll but that should not affect this issue.

As described you can reproduce this error on your data.all version by approving a cross account share request with tables included, then revoking it and then requesting and approving it again.

[dlpzx]

I can confirm the error. This is what we get in RAM when revoking:

It is strange because from CloudTrail the RAM API calls look successful. But looking a little bit more into the IAM policies of the AWSLakeFormationCrossAccountManager and comparing them with the ones of the pivotRole, we can see that the glue:DeleteResourcePolicy action is missing.

In CloudTrail I can now find the logs of the failed API call: