I agree... IAM policies are too complicated. For services I write I've been using simple permission strings. Call them scopes on the form: 'service:action:re

I agree... IAM policies are too complicated. For services I write I've been using simple permission strings. Call them scopes on the form: 'service:action:resource/sub-resource...' Each client is then associated a set of scopes, if a scope ends with '' it matches all suffixes. And then you just ask if a client has a set of scopes. By only allowing at the end, and otherwise just having permission as a set of strings you can most interesting operations: - intersection - union - empty-set - sub-set between any two sets of scopes. Hence, you can do do automated reasoning about permissions assigned. For example you check automatically verify an assumption that no role grants a scope A to a user who also has scope B. Lack of support for doing combining IAM policies makes it hard to verify your policies with high-level assertions.