How to configure IP restriction's for IAM users?

Hi,

You have here an interesting article around identity-based vs resource-based IAM policies: https://sonraisecurity.com/blog/aws-identity-based-policy-vs-resource-based-policy/

They both have advantages and benefits that you have to evaluate in your use cases: see details in the artcile.

Note: when you have both in place in your account, the final Allow or Deny by IAM is the result of a conjunction of both detailled in the article. That is probably what's happening in your situation.

The complete algorithm is detailled in the official IAM documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html

Best,

Didier

Details here https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html

In general, the most successful way to configure IP address and/or source VPC restrictions for IAM users or roles is to attach an IAM policy to the user/role containing an explicit "deny" statement for requests from unexpected origins.

It's technically possible to apply similar restrictions in resource-based policies, such as S3 bucket policies, but a resource-based policy applies to all users/principals, whereas the origin of requests for a given user or role is inherently a property of the user/role and not that of the resource. If we know that a given user/role is used legitimately only from certain IP addresses or a specific VPC, for example, we'd want to block access to all resources for that user/role when the request has an unexpected origin.

It would be much more involved and error-prone to manage the same IP/VPC restrictions for the same user/role in the resource-based policies of many different resources. Furthermore, if some resources in our account or a different account allow access to all principals in our account or some other applicable wildcard (like our entire AWS Organization), that could easily happen without our knowledge or consent. An explicit Deny statement attached to a principal applies to all actions taken by the principal, regardless of the configuration of the target resource.

As an example, if an IAM role or user is used on an EC2 instance inside a VPC with connectivity to the internet through a NAT gateway, the policy to attach to the user to block it from being used from any other origin could look like this. Replace the VPC ID and IP address placeholders with the relevant values for your case:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllAccessIfNotFromExpectedNetworkOrigins",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:SourceVpc": ["vpc-00000000000000000"]
        },
        "NotIpAddressIfExists": {
          "aws:SourceIp": ["192.0.2.0/24"]
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

If an IAM user is only used from on premises or a non-AWS cloud environment, for example, the clause for aws:SourceVpc can be removed and the rest of the example left unchanged:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllAccessIfNotFromExpectedNetworkOrigins",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddressIfExists": {
          "aws:SourceIp": ["192.0.2.0/24"]
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

There's a comprehensive discussion along with examples and an in-depth explanation of the reasoning behind this approach in this AWS blog post series: https://aws.amazon.com/identity/data-perimeters-blog-post-series/. There are also videos and whitepapers available here: https://aws.amazon.com/identity/data-perimeters-on-aws/