info

Our support for AWS permission features is constantly growing. If you miss a specific feature or have a question, Please let us know!

General

CodeShield's policy evaluation engine is a core feature of the Cloud Model generation. It is responsible for deciding which resources can access each other and which IAM actions are allowed to be executed between the evaluated resources.

To decide accessibility between resources, the engine collects all roles and policies reachable by the resource, evaluates (including the expansion of wildcards) the actions and resource blocks of all statements contained in the reachable policies, and creates a AccessRef edge between the source resource and the target resource. The generated AccessRef contains all possible actions between source and target in its relevantActions property.

info

You can assess policy reachability manually by going to the resource inventory and looking for an AttachedPolicy edge in either the Outgoing-edges section of a policy holding resource (e.g., Role, User, Group), or the Incoming-edges section of the Policy of interest.

For example, this can be very neat if you want to know which resources have the AWS managed AdministratorAccess policy attached.

Our engine strictly follows the AWS policy evaluation logic as described here . We also carefully handle the different evaluation mechanisms for intra-and inter-account communication, like the evaluation prevalence of resource-based policies in the same account.

info

This is an often misunderstood concept that can easily lead to unexpectedly open cloud environments. In the same account, if a resource-based policy of resource X allows other resources access to X, these other resources do not require an additional identity-based policy to grant access to X. Only an explicit deny in the identities policy, would prevent access in the same account.

E.g., the trust policy of a role is a resource-based policy. If this policy allows * to assume the role, every principal in the same account can assume this role, even if the principal has no attached policy that allows sts:AssumRole. With the exception that if the principal is the account principal ("Principal": { "AWS": "arn:aws:iam::123456789012:root" }) , policy evaluation behaves as if the access would happen cross-account -> an identity-based allow is also necessary to allow the principal to assume the role.

Features of CodeShield's policy evaluation engine

Supported policy types

• Customer and AWS managed policies
• Inline policies
• Trust policies in Roles to determine who can assume a role
• Identity-based policies, defining the access rights of an identity
• Resource-based policies, defining the access rights of principals on a corresponding resource
• Permission boundaries
• Service control policies (Requires access to the AWS management account as it maintains the SCPs.)

Supported Policy Statement concepts

• Action and NotAction blocks including wildcard expansion
• Resource and NotResource blocks including wildcard expansion
• Explicit and implicit denies
• Principal blocks including wildcard expansion
• Conditions
  • aws:PrincipleArn
  • iam:PassedToService
  • iam:PolicyARN
  • iam:PermissionsBoundary
  • aws:ResourceTag
  • (Please let us know if you miss conditions!)
• TBD NotPrincipal (Please let us know if you miss this feature!)