Write up a list of missing IAM features

[dnmfarrell]

Compare iamsim to the
IAM SimulateCustomPolicy API features.

[dnmfarrell]

SimulateCustomPolicy supports:

• []ActionNames - eval permissions for these actions, no wildcards
• CallerArn - used by ResourcePolicy Principal, must be IAM user, not role etc.
• []ContextEntries - optional request context vars can be used by policy conditions
• []PermissionsBoundaryPolicyInputList - sets the permissions boundary for the simulation (is a list but only accepts one policy?).
• []PolicyInputList - list of identity policies
• []ResourceArns - list of resources to include in the simulation, defaults to *.
• ResourceHandlingOption - ec2 permission scenarios to run, e.g. EC2-VPC-EBS requires instance, image, security group, network interface and subnet resources to be specified.
• ResourceOwner - ARN of AWS account ID that owns all resources that do not identity their owner in their resource ARN. Defaults to CallerArn. Used for resource policy eval.
• ResourcePolicy - resource policy to include in the simulation.

Returns a list of evaluation results which mention SCP, even though that is not a parameter - perhaps if the CallerARN is a real IAM user and it's organization has an SCP, it will be automatically applied?

In any case:

• Context Entries is a neat way to provide additional info that can be used by the simulation.
• Context keys can be included in policy strings, need to be able to parse these to eval context entries. IAM context keys.
• Conditions enable run-time logic.
• Resource policies are limited by SCP, but not boundary policies. So we need resource and SCP types to apply the different logic.
• A list of action names can be tested for set intersection with the response from all/2.
• Caller ARN (and ARN syntax checking) would be useful.
• Resource ARNs is kind of weird, since they all have to have the same resource policy. Probably more useful to reduce round trips on network requests? Unless:
• Resource Handling Option - the scenario determines the required resources (do the resources have to be in resource arns?). This seems useful. Wonder if other scenarios could be added.
• ResourceOwner - needed to evaluate policies (if the resource owner <> caller arn ...)
• NotPrincipal, NotAction, NotResource are kind of head-spinning and therefore useful to support to catch unintended changes.

[dnmfarrell]

Need tickets for the following features:

• Use parsed ARNs instead of strings. Add ARN parsing/matching #3
• Allow creation of resource policies via policy_add (will need Caller ARN, ResourceOwner and resource policy type). Support resource policies #8
• Allow creation of Service Control Policies (SCP) via policy_add. Support Service Control Policies #9
• Support NotPrincipal (resource policies only) and NotAction and NotResource. Support NotAction and NotResource #10
• Support policy conditions and request context keys. Support conditions #11