Commit b40b1b2
authored
Simplify lakeformation shares - single shared_db and single resource link table (#1016)
### Feature or Bugfix
- Feature
### Detail
Implements design specified in #746. Multiple share requests share a
single shared Glue database instead of a shared database per share
request. Same for resource link tables, multiple shares in the same
target account get permissions to the same resource link table.
In addition, this PR includes:
- Unified LakeFormation processor for same account and cross account
shares (remove duplicated code)
- Code clean-up of Lake Formation manager and client: remove duplicates,
added more error handling
- Ensure "no-failures" if a resource already exists or is already
deleted or if a permission is already granted or revoked
- Redesigned tests and increased coverage
#### Upgrade LakeFormation version
LakeFormation v3
([docs](https://docs.aws.amazon.com/lake-formation/latest/dg/optimize-ram.html))
simplifies cross-account sharing requests. We want to see if there are
advantages of implementing the capability of LakeFormation to define the
external IAM role directly, instead of using first an AWS account and
then the role. In addition, v4 introduces LF hybrid mode. We are not
using it at the moment, but it can be a great addition in future
features. Because we already distinguish between "old" and "new" shares,
it is relatively easy to upgrade to a new LF version without affecting
"old" shares.
**Does it make sense to upgrade the sharing mechanism?**
- Is it possible technically for all principals? --> No, which is a
blocker
```Could not grant principal arn:aws:quicksight:us-east-1:11111111111:group/default/dataall permissions ['DESCRIBE', 'SELECT'] to {'Table': {'DatabaseName': 'dataall_imported_c3_tvnews81', 'Name': 'children_books_raw', 'CatalogId': '2222222222222'}} due to: An error occurred (InvalidInputException) when calling the GrantPermissions operation: Cross account requests are only allowed for AWS Accounts, Organizations, IAM Principals and All IAMPrincipals```
- What actions are simplified? In this [commit ](f5b9bee) we can see how the final implementation would look like.
**How does the migration look like?**
1. Upgrade LF version: It is possible to change the LF cross account settings programmatically using [put_data_lake_settings](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/lakeformation/client/put_data_lake_settings.html) API. We already use this API in a custom resource of the environment stack. We could introduce the LF version as part of that call and make sure that it is executed on update (not only on create).
2. Modify code in sharing task: for old_shares use the AWS account and for new shares use the IAM roles as principals of the grant. for old_shares execute additional grant for principals in target, for new shares skip. See [commit ](f5b9bee).
3. Backwards compatibility for shares done with V2:
- At the moment the code is meant to work for versions >= v2. v4 is very recent and most AWS accounts use v3
- Grant: If a RAM request is v2 and the LF version is upgraded to v3, new tables added to the RAM invitation can use v3 underlying code (I tested one table shared with old v2 procedure and added one table to the request with new code changes and it succeeds. In source the principals are the target IAM roles not the target account)
- Revoke: not tested
**Conclusion**
- We cannot implement LF v3 direct sharing with principals because it does not support Quicksight groups.
- I think that setting the LF version in the environment stack is a good idea regardless of it being explicitly used It gives us control to set the latest version in the accounts we use. This is a feature that should be part of a separate PR.
- v2 RAM invitations still work with v3 direct-IAM role code. Therefore we could keep using v2 shares without the need to inspect shares and upgrade them. This means that the upgrade is pretty seamless, and we can take it at a later time when the Quicksight blocker is resolved.
Issues resolved:
- [X] Issue: deletion of new "shared" database does not happen when other old shares are still present in environment account.
- [X] ~[Pre-existing issue]: In cross-account shares revoke ALL does not revoke permissions to QS group (by-design)~
- [X] [Pre-existing issue]: in same account requesters have access to original table. It is needed! If we remove access to the original table the resource link access to data does not work.
- [X] ~Issue: when revoking, permissions to the shared db are not revoked for principal~
- [X] ~Issue: shared db is not deleted when all shares are revoked~
- [X] ~Issue: duplication of LF permissions. Pivot role and QS group were granted permissions on the original db and on the shared db with every new share~
- [ ] [Pre-existing issue]: orphan LF resources on failed shares. If a share fails it can be deleted from data.all UI but there are resources that are created in LF that require manual clean-up (ugly operation assuming pivot role)
- [X] ~Changes in UI: data consumption details~
### Next steps and remarks
- Because there are shared resources between shares, it is possible that parallel shares on the same tables have conflicts: e.g. 2 shares trying to create a resource link simultaneously. I have tried testing with shares approved in a matter of seconds and did not run into issues (at the end a look-up is way faster than updating a policy). But we should keep an eye on this.
- Upgrade Lake Formation version. Not possible at this moment, because it would not work for Quicksight groups. To be re-evaluated in the future.
- I think the orphan LF resources on failed shares can be done in a separate PR to limit the scope of this PR.
- I tried to revoke the requester access to the original table in same account sharing, but it is not possible. For the requester to be able to access the underlying data of the resource link, it needs to have access to the table.
- The issue "deletion of new "shared" database does not happen when other old shares are still present in environment account." has not a big impact, but I implemented a solution nevertheless.
### Relates
- #746
### Security
Please answer the questions below briefly where applicable, or write `N/A`. Based on
[OWASP 10](https://owasp.org/Top10/en/).
- Does this PR introduce or modify any input fields or queries - this includes
fetching data from storage outside the application (e.g. a database, an S3 bucket)?
- Is the input sanitized?
- What precautions are you taking before deserializing the data you consume?
- Is injection prevented by parametrizing queries?
- Have you ensured no `eval` or similar functions are used?
- Does this PR introduce any functionality or component that requires authorization?
- How have you ensured it respects the existing AuthN/AuthZ mechanisms?
- Are you logging failed auth attempts?
- Are you using or adding any cryptographic features?
- Do you use a standard proven implementations?
- Are the used keys controlled by the customer? Where are they stored?
- Are you introducing any new policies/roles/users?
- Have you used the least-privilege principle? How?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.1 parent 752e824 commit b40b1b2
File tree
16 files changed
+1285
-1559
lines changed- backend/dataall
- base/utils
- modules
- dataset_sharing
- api
- aws
- db
- services
- datasets/services
- tests
- base/utils
- modules/datasets/tasks
16 files changed
+1285
-1559
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
74 | 74 | | |
75 | 75 | | |
76 | 76 | | |
77 | | - | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
7 | 7 | | |
8 | 8 | | |
9 | 9 | | |
10 | | - | |
| 10 | + | |
11 | 11 | | |
12 | 12 | | |
13 | 13 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
182 | 182 | | |
183 | 183 | | |
184 | 184 | | |
185 | | - | |
186 | | - | |
187 | | - | |
188 | | - | |
189 | | - | |
190 | | - | |
191 | | - | |
192 | | - | |
193 | | - | |
194 | | - | |
195 | | - | |
196 | | - | |
| 185 | + | |
| 186 | + | |
| 187 | + | |
| 188 | + | |
| 189 | + | |
| 190 | + | |
197 | 191 | | |
198 | 192 | | |
199 | 193 | | |
| |||
Lines changed: 95 additions & 33 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
16 | 16 | | |
17 | 17 | | |
18 | 18 | | |
19 | | - | |
| 19 | + | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
20 | 24 | | |
21 | 25 | | |
22 | 26 | | |
23 | 27 | | |
24 | 28 | | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
25 | 33 | | |
26 | 34 | | |
27 | 35 | | |
28 | | - | |
| 36 | + | |
| 37 | + | |
| 38 | + | |
29 | 39 | | |
30 | 40 | | |
31 | 41 | | |
| |||
39 | 49 | | |
40 | 50 | | |
41 | 51 | | |
42 | | - | |
43 | 52 | | |
44 | | - | |
45 | 53 | | |
46 | 54 | | |
47 | | - | |
48 | 55 | | |
49 | 56 | | |
50 | | - | |
| 57 | + | |
| 58 | + | |
| 59 | + | |
| 60 | + | |
| 61 | + | |
| 62 | + | |
| 63 | + | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
51 | 70 | | |
52 | | - | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
53 | 76 | | |
54 | 77 | | |
55 | | - | |
| 78 | + | |
56 | 79 | | |
57 | 80 | | |
58 | 81 | | |
59 | 82 | | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
60 | 88 | | |
61 | 89 | | |
62 | 90 | | |
63 | 91 | | |
64 | 92 | | |
65 | | - | |
| 93 | + | |
66 | 94 | | |
67 | 95 | | |
68 | 96 | | |
69 | 97 | | |
70 | 98 | | |
71 | 99 | | |
72 | 100 | | |
73 | | - | |
74 | | - | |
75 | | - | |
76 | | - | |
77 | | - | |
78 | | - | |
79 | | - | |
80 | | - | |
81 | | - | |
82 | | - | |
83 | | - | |
84 | | - | |
| 101 | + | |
| 102 | + | |
| 103 | + | |
| 104 | + | |
| 105 | + | |
| 106 | + | |
| 107 | + | |
| 108 | + | |
| 109 | + | |
| 110 | + | |
| 111 | + | |
| 112 | + | |
| 113 | + | |
| 114 | + | |
| 115 | + | |
| 116 | + | |
| 117 | + | |
| 118 | + | |
| 119 | + | |
| 120 | + | |
| 121 | + | |
| 122 | + | |
| 123 | + | |
| 124 | + | |
| 125 | + | |
| 126 | + | |
85 | 127 | | |
86 | | - | |
| 128 | + | |
87 | 129 | | |
88 | | - | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
| 136 | + | |
| 137 | + | |
| 138 | + | |
89 | 139 | | |
90 | | - | |
91 | | - | |
92 | | - | |
93 | 140 | | |
| 141 | + | |
| 142 | + | |
| 143 | + | |
| 144 | + | |
94 | 145 | | |
95 | 146 | | |
96 | 147 | | |
97 | | - | |
| 148 | + | |
| 149 | + | |
| 150 | + | |
98 | 151 | | |
99 | 152 | | |
100 | 153 | | |
101 | 154 | | |
102 | | - | |
| 155 | + | |
103 | 156 | | |
104 | 157 | | |
105 | 158 | | |
106 | | - | |
| 159 | + | |
| 160 | + | |
| 161 | + | |
107 | 162 | | |
108 | 163 | | |
109 | 164 | | |
110 | 165 | | |
111 | 166 | | |
112 | | - | |
| 167 | + | |
113 | 168 | | |
114 | 169 | | |
115 | 170 | | |
116 | 171 | | |
117 | 172 | | |
118 | 173 | | |
119 | 174 | | |
120 | | - | |
121 | | - | |
122 | 175 | | |
123 | | - | |
| 176 | + | |
| 177 | + | |
| 178 | + | |
| 179 | + | |
| 180 | + | |
| 181 | + | |
124 | 182 | | |
| 183 | + | |
| 184 | + | |
| 185 | + | |
| 186 | + | |
125 | 187 | | |
126 | 188 | | |
127 | 189 | | |
| |||
0 commit comments