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!

Microsoft Ignite 2017 – Session bonanza!

Microsoft Ignite has wrapped up and it was a blast! For those that are not familiar, Microsoft Ignite is a five day conference for IT professionals that focuses on a variety of Microsoft products like Azure and Office 365, this year it was hosted in beautiful and sunny Orlando, Florida. This year’s conference was jam-packed with a variety of sessions hosted by Microsoft experts. (Seriously, if you did not find a session that interested you on any of the days, then IT may not be for you) While I do not consider myself biased towards Microsoft, I was impressed by this years outcome.

My primary purpose for attending the conference was to learn more about Azure and it’s offerings, therefore, I catered my session selection to that. Below you can find a selection of sessions that I found particularly interesting.  All the sessions at Ignite, including the keynote can be viewed here.  

 

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!

The C.H.I.P is here!

Hi All!

As a kickstarter backer of Next Thing Co.’s C.H.I.P, I was able to receive the miniature $9 computer this past week. While I have not yet had any time to go and play around with it, I figured I would write a post for those of you wanting to know more about the device. Below is a picture of what the C.H.I.P looks like.

Chip

What is it?

As mentioned previously, the CHIP is a tiny computer offered by a California startup named Next Thing Co. (http://www.nextthing.co/)The CHIP comes equipped with a 1 GHz processor, 512MB of RAM, composite port, 1 USB slot and micro-USB port. While the 1 USB port may not be enough to connect a USB mouse and keyboard, you can however, connect 1 of these peripheral devices via USB and the other (as long as it is supported) using bluetooth. The CHIP comes with both built in WiFi and Bluetooth. The neat thing about the CHIP is that it comes with 4GB of storage, you can increase the amount of storage by plugging in flash storage into the USB port. The CHIP runs on the Linux operating system.

How does it compare to the Raspberry Pi?

You have seen my previous posts about the Raspberry Pi , so how does the CHIP stack up against the Raspberry Pi? Well… lets cover the obvious first: Price, the CHIP comes in at $9. The Raspberry Pi  is approximately $30, depending on the model. The Pi Zero is $5, however keep in mind, at the time of this post, all models of Raspberry Pi’s will require you to purchase additional storage to use. Power adapters will need to be purchased for both products. The CHIP comes with a composite cable you can use to hook up to a monitor/TV. The Raspberry Pi’s will need an additional video cable should you decide to use it with a monitor/TV.

Next up connections: The CHIP only comes with one USB and one micro-USB slot, where the Raspberry Pi’s range from 1 to 4 slots (depending on the model), Unlike the Raspberry Pi, the CHIP does not have a Ethernet connection however, it does come with Bluetooth and Wi-Fi built in. The Raspberry Pi falls short on these offerings, and you will need to purchase additional dongles should you want to use Wi-Fi or Bluetooth.

As for Storage: The CHIP comes standard with 4GB of on-board flash memory, which again, you can expand this by plugging in additional flash storage. The Raspberry Pi’s do not come with on-board storage but rather, rely on SD or microSD cards.

And lastly Power: Depending on the model, the Raspberry Pi will operate at 700 MHz – 1 GHz ARM based processors and anywhere between 256MB to 1GB of memory. The CHIP on the other hand, comes with a 1 GHz ARM based processor with 512MB of memory.

And the Verdict… For now, its up to you, both products are remarkable tiny computers packing a serious punch for a variety of fun and educational products. Try them both (or more) and let me know where you stand.

The newest member of the Pi family – Raspberry Pi 2 Model B Initial Setup

So today (actually it has been a while since I received my RPI, however, I neglected to write this post) I have received the newest version of the Raspberry Pi, the RPI 2 Model B. This is a significantly upgraded model from its predecessor the Raspberry Pi Model B+, mainly featuring an upgrade CPU and more memory. For more information on the RPI 2 Model B you can check out the stats here: http://www.raspberrypi.org/products/raspberry-pi-2-model-b/, Wikipedia also has a very nice comparison chart on https://en.wikipedia.org/wiki/Raspberry_Pi.

Prerequisites 

In order to start using it, I will need to run through some basic setup that I do with all my raspberry pi’s. This mainly consists of the initial setup, setting up a static IP (all my raspberry PI’s are hard wired), and lastly, setting up some security features.

I will skip over the initial setup that includes expanding the filesystem, changing the default pi password, enabling SSH, changing the hostname, and running all the updates. If you are looking for documentation on doing that, please refer to http://www.raspberrypi.org/documentation/configuration/raspi-config.md and for any raspberry pi updates see this page http://www.raspberrypi.org/documentation/raspbian/updating.md for more information.

Setting up Static IP

Now, with your initial setup done. Let’s set up a static IP for our Raspberry Pi. To do this you will either need to SSH into your raspberry PI, (you can obtain the current IP via tools like angry IP scanner) or you can proceed to do this locally as well (most-likely how you did your initial setup).

To set up Static IP please follow the steps outlined on my WIKI page. When the time comes to pick a static IP, either use the one that was assigned by DHCP, or make sure to pick one that is not already used. (you can verify the used IP’s via angry IP scanner as well)

We are almost done…

Setting up UFW (Uncomplicated Firewall)

Lastly, we will want to enable some basic firewall features. For this we will be using UFW, which is an easy to use firewall for linux. Essentially, you can think of it as a front for Iptables that reduces the complexities of setting them up.

Setting up UFW is simple, you will need to download, install, and perform a couple (depending on what you want to block/allow) of configurations.

Please refer to my WIKI on setting up UFW. Because I do not know your network layout, and what type of traffic you want to allow/deny it is very likely you will need additional commands.

For additional information, syntax, and examples on UFW refer to the documentation available on here]

Thank you all!

Hello World!

Hello everyone!

I am very excited to be posting my very first post on my very own blog! In the upcoming weeks I will be setting this site up so please be patient!

Additionally, I will be setting up a wiki (MediaWiki) that I will reference in subsequent posts. The wiki will be used to store documentation that should be external to the posts and documentation that I would like to frequently reference.

If you have any questions or suggestions please feel free to reach out to me directly via email dawid@dawidnowak.com

Thanks!

© 2020 Dawid's Blog

Theme by Anders NorénUp ↑