0

I have tried to limit access to a VPC without success. Maybe approaching the issue from the other side is a better idea, but I can't get that to work either.

I have tried:

Limit by tags as shown here:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:Describe*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/client": "<client>"
                }
            }
        }
    ]
}

Limit by VPC as suggested here:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1508450090000",
            "Effect": "Allow",
            "Action": [
                "ec2:Describe*"
            ],
            "Resource": [
                "arn:aws:ec2:<region>:<account>:subnet/*"
            ],
            "Condition": {
                "StringEquals": {
                    "ec2:Vpc": "arn:aws:ec2:<region>:<account>:vpc/<vpc_id>"
                }
            }
        }
    ]
}

Both policies result in not even listing any instances, see screenshot. enter image description here

This seems to be a very obvious and commonly needed policy to me. Any help is appreciated.

kev
  • 8,928
  • 14
  • 61
  • 103
  • See https://aws.amazon.com/premiumsupport/knowledge-center/iam-policy-restrict-vpc/. – jarmod Oct 19 '17 at 23:48
  • @jarmod Do I understand correctly that `ec2:Describe*` actions cannot be limited/restricted in any way as it is non resource based? – kev Oct 19 '17 at 23:58
  • Believe that's correct. For a definitive list of actions that support resource-level permissions, see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-iam-actions-resources.html. AWS is not organized in a way that allows you to do what you want because its separation is really at account level, not at the VPC level. Personally, I'd like to see AWS introduce new hierarchical containers for resources so that IAM credentials could be scoped at vpc, project, folder, account, or organization. – jarmod Oct 20 '17 at 12:59

2 Answers2

0

According to the documentation: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_IAM.html#readonlyvpciam

The following policy grants users permission to list your VPCs and their components. They can't create, update, or delete them.

{
    "Version": "2012-10-17",
    "Statement":[{
    "Effect":"Allow",
    "Action":["ec2:DescribeVpcs",
              "ec2:DescribeSubnets",
              "ec2:DescribeInternetGateways",
              "ec2:DescribeEgressOnlyInternetGateways",
              "ec2:DescribeVpcEndpoints",
              "ec2:DescribeNatGateways",
              "ec2:DescribeCustomerGateways",
              "ec2:DescribeVpnGateways",
              "ec2:DescribeVpnConnections",
              "ec2:DescribeRouteTables",
              "ec2:DescribeAddresses",
              "ec2:DescribeSecurityGroups",
              "ec2:DescribeNetworkAcls",
              "ec2:DescribeDhcpOptions",
              "ec2:DescribeTags",
              "ec2:DescribeInstances"],
    "Resource":"*"
    }
  ]
}

Further, if you have multiple VPCs that you do not want them to even see, perhaps you should consider creating a sub-account with only the portion of your network that they should have visibility across:

  1. Setup Consolidated Billing

As a first step, log into your AWS account and click the "Sign up for Consolidated Billing" button.

  1. Create a new account

From a non-logged in browser, you will then want to sign up again to AWS again like this:

Give this new account the appropriate name for your client. Note the email address you signed up with.

  1. Link the accounts

In your main account, head back to ConsolidatedBilling and click the Send a Request button. Provide the email address for your new sub-account.

You should receive an email to the email address for your new sub-account. Copy the activation link and paste it into your browser logged in to the sub-account.

Your accounts are now linked!

  1. Create your clients VPC and enable the services that the client requires.

Next, you can create the VPC & services the client requires, and restrict their access via the policy above.

shenku
  • 11,969
  • 12
  • 64
  • 118
  • Where is the restriction to a single vpc? – kev Oct 20 '17 at 00:07
  • Can you be a bit more precise about "enable the services that the client requires." I have created a sub-account but I can only allow/deny access to Services (e.g. Amazon EC2) and Actions (e.g. DescribeInstances) but I can't see how I would limit access to a specific vpc. Thanks. – kev Oct 20 '17 at 00:32
  • 1
    This pointed me in the right direction simply creating a different AWS account (as a sub account of my organisation). – kev Oct 26 '17 at 22:59
0

You cannot restrict Describe* calls in the manner you want.

Calls that create resources can be restricted (eg give permission to launch an instance in a particular VPC), but calls that list resources cannot be restricted.

If you require the ability to prevent certain users from listing resources, then you'll either need to build your own front-end that filters the information before presenting it to users, or use multiple AWS accounts since they are fully isolated from each other.

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470