CategoryAmazon Web Services (AWS)

AWS – Create a New Default VPC using AWS Console or CLI

Amazon Web Services, on July 27th, 2017 released the ability for end users to be able to re-create their default VPC. Previously, if you deleted your default VPC your only option on having one re created for you was to open a support ticket with AWS.

Full details regarding the release can be found here: https://aws.amazon.com/about-aws/whats-new/2017/07/create-a-new-default-vpc-using-aws-console-or-cli/ 

And full VPC documentation, including programmatic examples can be found on this page: https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/default-vpc.html

 

A word of caution…

For customers that utilize policies to restrict the creation of VPC’s, we now have to update those policies to include one more action.

A sample vpc creation deny policy is shown below:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1507368536000",
            "Effect": "Deny",
            "Action": [
                "ec2:CreateVpc"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

While, this was enough to prevent your users from creating VPC’s in the past, we now need to add another action to the deny list “ec2:CreateDefaultVpc”

as of today, the iam policy updater has not yet been updated to include this action, nor was I able to find any details on AWS documentation sites.

I came across this issue coincidentally when a user asked me to delete a VPC because he was receiving an unauthorized message when trying to do so…having created the policy myself, I thought… “well how did you create the VPC in the first place?!!??” After discussing this with the user, following the July 27th, 2017 release the option is simply available when launching an ec2 instance. In the screenshot below, you will notice that you have two areas where one can create a new default VPC under the “Configure Instance Details” screen.

 

Even though the user may be denied when attempting to create a VPC, he/she will not be denied if they were to click on the “create a new default VPC” link and create a default VPC using the wizard. Furthermore, they would not be denied if they attempted this action programmatically, and/or through another service/console wizard.

In order to deny the VPC creation as well as the default VPC re-creation (after confirming with AWS) we must add the following action into our deny policy: “ec2:CreateDefaultVpc”

Thus our policy should now look like this:

 


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1507374912000",
            "Effect": "Deny",
            "Action": [
                "ec2:CreateVpc",
                "ec2:CreateDefaultVpc"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

The above policy will now block all VPC creation actions for any type of VPC.

Let me know if you have any questions. Thanks!

AWS-How do I give end users permissions to create autogenerated AWS policies?

So you have set up a robust set of roles, policies, groups, users (hopefully you are federating access, so you limit these) etc… for your enterprise. As part of this effort, you have limited your cloud users ability to create/update/delete AWS and Customer managed policies. But now, your users are complaining they get the dreaded “Not authorized to perform” error when attempting to use some services.

SQL Server Backup Restore Option Group IAM Permissions

In this scenario we examine the AWS RDS Service, specifically when creating a new SQL Server Backup Restore Option Group. When configuring the option group, you are asked to select or create a new IAM role. Usually, when you are just getting started, the required role will not exist and you will need to go ahead and create one. Conveniently, the option to create a new role is available to you when creating the SQL option group.

However, shortly after you input all your configuration values, and proceed to adding the option group, you get an error similar to: arn:aws:sts::{account#}:assumed-role/{role}/{user} is not authorized to perform: iam:CreatePolicy on resource policy sqlNativeBackup-{timestamp}. You scratch your head, and ponder “What gives!”

These permission issues stem from the fact that the logged in user (You!) assumed a role that does not have IAM policy permissions.

But how do you give users the ability to create sql backup option sets and the ability to create a new role without giving all IAM policy and role creation abilities to the user?

Selectively Allow Automatic Policy Creation for Certain AWS Services

When creating a sql backup option set, specifically the SQLSERVER_BACKUP_RESTORE option, RDS will always create a policy that follows the following naming convention: arn:aws:iam::{account#}:policy/service-role/sqlNativeBackup-{DateTime} for example:

arn:aws:iam::123456789123:policy/service-role/sqlnativeBackup-2017-07-14-15.39.56.317

For a variety of reasons, you may not want to enable your end users with the necessary permissions to create their own policies. However, you also do not want them to be hindered by errors when they are leveraging an AWS service that automatically creates policies on the fly during provisioning.

The recommended approach to take is:

Restrict policy creation by default (which you already have to be doing to an extent, as you would likely not be reading on)  but, allow policy creation with a specific path and naming convention (which is automatically done for you by RDS)

Because users will not be able to update policies nor create news ones through other means (for example through IAM) you can be assured the policy created by RDS will remain the unchanged once created.

To recap:

You restrict IAM permissions by having a policy that denies creation/updates/deletion of policies, a sample policy is given below:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt15328738200",
"Effect": "Deny",
"Action": [
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy",
"iam:AttachUserPolicy",
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:DeleteGroupPolicy",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:DeleteRolePolicy",
"iam:PutGroupPolicy",
"iam:PutRolePolicy",
"iam:PutUserPolicy"
],
"Resource": [
"*"
]
}
]
}

To allow your users to create a SQL server backup option group policy, you can remove the "iam:CreatePolicy" block from the above statement. and add the following to your policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt15328738200",
"Effect": "Allow",
"Action": [
"iam:CreatePolicy"
],
"Resource": [
"arn:aws:iam::*:policy/service-role/sqlNativeBackup*"
]
}
]
}

NOTE: In order for this to work, you need to ensure "iam:CreatePolicy" Is not denied by any other policy

Putting It All Together

What we have done above is removed the block of code that specifically denied the creation of policies and allowed the creation of policies only when the resource matches "arn:aws:iam::*:policy/service-role/sqlNativeBackup*"

It is important to remember that no other policy when attached to a role/user/group can deny the ability to create policies ("iam:CreatePolicy") This has to do with the way that AWS evaluates permissions (For more on AWS IAM evaluation logic see this link ) In general, the absence of an explicit allow, AWS IAM will deny by default, which makes the above possible.  Therefore, this means that if a user attempts to create a policy for a resource other than the one that matches  "arn:aws:iam::*:policy/service-role/sqlNativeBackup*" because IAM does not find an explicit allow anywhere in the aggregate of all policies, it will deny the operation.

Questions, Comments, and Suggestions always welcome!

© 2020 Dawid's Blog

Theme by Anders NorénUp ↑