Skip to content

Restricting Access to AWS Identity Center to Specific IP Range

1

I’m using AWS identity center, but I need to block the users outside the office ip range. Is there any options to configure it in IAM identity center? Are there any specific settings or policies I need to implement to achieve this ?

3 Answers
1

Hi,

Yes, you can do that by adding conditions in the IAM policies around IAM Identity Center (formerly SSO)

So, you probably have policies like the ones on this page: https://docs.aws.amazon.com/singlesignon/latest/userguide/iam-auth-access-using-id-policies.html

Then, you need to extend such policies with IAM conditions on IP address as explained here https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html

This example shows how you might create an identity-based policy that denies access to <sso:* or your specific IIC actions> in the account when the request comes from principals outside the specified IP range.

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "<sso:* or your specific IIC actions>",
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": [
                    "192.0.2.0/24",
                    "203.0.113.0/24"
                ]
            }
        }
    }
}

All details about IAM Conditions here if you need: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html

Best,

Didier

EXPERT
answered a year ago
EXPERT
reviewed a year ago
0
Accepted Answer

There is no direct option in IAM identity center to block the users outside the specific IP range.

This can be achieved by using SCP. (Service Control Policies) where you can centrally manage the IP based restrictions.

This is an example where it deny all actions outside specific regions. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideOffice",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "192.0.2.0/24",
                        "203.0.113.0/24"
                    ]
                },
                "ArnNotLike": {
                    "aws:PrincipalARN": [
                        "arn:aws:iam::*:role/Role1AllowedToBypassThisSCP",
                        "arn:aws:iam::*:role/Role2AllowedToBypassThisSCP"
                    ]
                }
            }
        }
    ]
}

In this above example, Roles Role1AllowedToBypassThisSCP or Role2AllowedToBypassThisSCP can bypass this SCP.

If you are not using SCP, you can add the deny policy to all the roles / IAM Policy.

For example:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": [
                    "192.0.2.0/24",
                    "203.0.113.0/24"
                ]
            }
        }
    }
}
Replace "aws:SourceIp" values, update with the office IP range. 
AWS
answered a year ago
EXPERT
reviewed a year ago
  • This policy has some missing points. For instance, when applying this SCP, I am unable to publishing a Lambda Layer Version(which needs GetObjectVersion permission from S3 Object), even though my computer's public IP is explicitly included in the SourceIP condition.

  • Light, this may be related to actions done by a service, and not by your user directly. The service has a different source IP, and is falling under this policy. You can exclude them. You can also use FAS. read more here https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html

0

@etay we've experimented with creating exceptions in SCPs for actions done by AWS services (Lambda, ECR, etc) without success to date. Do you have generic examples that would allow, for example, a lambda service to carry out operations in a situation where an IP range restricted SCP exists??

The FAS possibility also looks interesting, but appears very complex and might not scale if it required configuration for each potentially useful service in each account. Have you seen it work out in practice, or have examples?

answered 5 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.