iasql
iasql copied to clipboard
alantech
RFC for better UX on top of AWS JSON policies
~https://github.com/iasql/iasql-engine/issues/1137 should help inform how to best move forward here~
Even for developers that are very experienced in AWS, adding a JSON policy still requires looking it up in stack overflow and validating its content manually and then treading cautiously to see if AWS accepts it. It is particularly hard to build a policy as it gets bigger without copy-pasting it. We shouldn't expose raw policies, but instead, expose common fields within it that get autogenerated into the policy based on the inputs.
Even for developers that are very experienced in AWS, adding a JSON policy still requires looking it up in stack overflow and validating its content manually and then treading cautiously to see if AWS accepts it. It is particularly hard to build a policy as it gets bigger without copy-pasting it. We shouldn't expose raw policies, but instead, expose common fields within it that get autogenerated into the policy based on the inputs.
Por que no los dos? ;)
We need the raw JSON, or something as flexible as the raw JSON to be able to represent anything that already exists in a users' account, or to tackle some obtuse (to us) policy requirement that is a must have for the user.
I think we should have the table fields be JSON primitives, but that we should also have some Postgres functions that we can compose to construct these JSON blobs, and optionally some functions that can decide if an existing JSON blob meets certain constraints (like, is it read-only access or read-write, does it have access to RDS entities, how many entities does it have access to, etc).
Ah yes, importing existing policies that might be custom has to continue to work. I lean towards something like what you mention here
optionally some functions that can decide if an existing JSON blob meets certain constraints (like, is it read-only access or read-write, does it have access to RDS entities, how many entities does it have access to, etc).
This is exactly how ecs_simplified works so perhaps it can be implemented as high level tables for modules with policies to keep the IaSQL UX familiar and consistent when we want to offer an alternative to AWS' crappy UX
In the event that we have multiple statements in a single policy, a single record in the entity table wouldn't be able to represent that. Shall we create a Policy entity under aws_iam module, such that each policy statement represents a record there and each record points to an entry in an entity (s3, vpc) table?
