Open endgame opened 1 year ago
https://reasonablypolymorphic.com/blog/abusing-constraints/ seems relevant here.
Note that there are some more nuances to this. API calls usually have one-to-many relationship with IAM permissions. And this information is hidden all over the place in documentation and is not available in a machine-consumable format.
For example autoscaling:CreateAutoScalingGroup
requires:
autoscaling:CreateAutoScalingGroup
ec2:RunInstances
to actually spawn instancesec2:CreateTags
iam:PassRole
Yes, that's an excellent point. Trying to trace all of those implications won't be practical. Another wrinkle: I hope to extend Amazonka to make it reasonably ergonomic to call API Gateway APIs which need IAM authentication, and it would be silly to call all of those execute-api:Invoke
.
I currently think the contract we want to offer is that the Symbol
provided denotes the name of the API operation, and for AWS API calls that's ${abbrev}:${OperationName}
, and see if anyone builds anything cool on top of it, but I'm open to other ideas.
OTOH Haskell would be one of those languages that could excel at this. I can see the coolness potential here.
I'd imagine some kind of Free Arrow / Free Selective
DSL for defining cloud resources and then you can do a static analysis to get the greatest fixpoint of IAM policy (Most-restrictive policy that allows all branches in the code)
I think that's the sort of thing which could be provided by some other layer, once we expose the base API names.
Too complex for 2.1, unless we can find a good mapping between API name (e.g., ListBuckets
) and IAM action name (s3:ListAllMyBuckets
).
It could be neat to have a type family that maps things like
Amazonka.DynamoDB.GetItem
to"dynamodb:GetItem" :: Symbol
. Might be a way to answer "which calls might this block of code make?" when combined with the right effect system library?