Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task Role Permissions check fails if policies use aws:RequestedRegion key #44

Open
abatkin opened this issue Sep 1, 2021 · 0 comments

Comments

@abatkin
Copy link

abatkin commented Sep 1, 2021

There are probably lots of other keys that this applies to, but this key in particular is probably very common in Permissions Boundaries, and unlike lots of other keys, we always know what value it will be set to.

To reproduce:

  • Create a, ECS Task Role that allows the 4 required ssmmessages: permissions
  • Create a Permissions Boundary Policy (attached to that ECS Task Role) that includes something like the block below (i.e. requiring the aws:RequestedRegion key to match a given region, and allow anything else, or at least the above 4 permissions)
  • Run the checker script
{
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": [
        "us-east-1"
      ]
    }
  },
  "Resource": "*",
  "Effect": "Allow",
  "Action": "*"
}

It will say that it the permissions failed due to "implicitDeny".

You can validate this using the CLI's simulate-principal-policy directly:

# This will fail
aws iam simulate-principal-policy --policy-source-arn <policy-arn> --action-names "ssmmessages:CreateControlChannel"
{
  "EvaluationResults": [
    ...
    "EvalDecision": "implicitDeny",
    ...
    "PermissionsBoundaryDecisionDetail": {
      "AllowedByPermissionsBoundary": false
    }
  ]
}

# This will succeed:
aws iam simulate-principal-policy --policy-source-arn <policy-arn> --action-names "ssmmessages:CreateControlChannel" --context-entries ContextKeyName=aws:RequestedRegion,ContextKeyValues=us-east-1,ContextKeyType=string

Could you set other context keys and/or allow a user-specified way of specifying other context keys? Sure. But this one is "easy" and common enough, that I think this script should always set it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant