This repository has been archived by the owner on Jun 25, 2024. It is now read-only.
INT-1561 - Add isPublic and isOpenToTheInternet to IAM bindings #296
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added
New properties added to resources:
google_iam_bindings
isReadOnly
google_iam_bindings
isOpenToTheInternet
Notes
Why Put Access Info on the Binding instead of the Resource?
Per @ndowmon's suggestion in the previous INT-1561 PR, instead of allowing users to find the access level of various resources via querying that resource directly. Example:
We can instead put the access information on the IAM binding and have users do a traversal query. Example:
From the users perspective, this is slightly worse as they are expected to know the data structure of Role Bindings to Resources in order to form the query. However, from the ingestion perspective, this is far easier because we do not need to enhance entities with information, which our sdk does not support yet (See sdk issue #532).
If we needed to support the first query today, we would need to restructure the graph project in such a way where all access information is available at the time of creating entities, which I did in these 2 PRs (INT-1142, INT-1561). Unfortunately, doing so makes this project significantly more difficult to work with in the future. Take a look for yourself, it's a bit hard to follow.
Why use
isReadOnly
andisOpenToTheInternet
instead of anaccessLevel
of 'private', 'publicRead 'and 'publicWrite' values?It felt to me that it would more clear to users making queries to put things into booleans instead of needing to have the user guess what the possible enum values of an entity property could be. How would a user know that the available accessLevels are
private
|publicRead
|publicWrite
? From what I can tell, the only ways would be we tell them or they look at the code. This problem goes away when you use boolean properties because each property is returned in J1QL queries. My guess is that people can guess the available values ofisReadOnly
andisOpenToTheInternet
quite easily. Of course another way to solve this problem would be to provide type docs for each entity, but we do not have those yet.